Bug 12775 - xkeyboard-config-1.1 breaks VT switching if more than one layout used
Summary: xkeyboard-config-1.1 breaks VT switching if more than one layout used
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: xkb
QA Contact:
Depends on:
Reported: 2007-10-10 11:58 UTC by Honza Macháček
Modified: 2008-01-12 09:03 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

xkeyboard-config-1.1-VTswitch.patch (421 bytes, patch)
2007-10-10 12:01 UTC, Honza Macháček
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Honza Macháček 2007-10-10 11:58:37 UTC
Bug from 0.9 comes back. Then solved in Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392911 , discussed and solved again in Gentoo https://bugs.gentoo.org/show_bug.cgi?id=157837

When more than one keyboard layout is used, Ctrl-Alt-Fn switching of virtual terminals fails to function.

The debian patch changed in symbols/level3 file several line of the form
modifier_map Mod5   { <RALT> };
modifier_map Mod5   { ISO_Level3_Shift };
References of other keys than RALT were concerned too. Now, xkeyboard-config-1.1 has in the same file one suspicious line
modifier_map Mod5   { <LALT> };
Changing it to
modifier_map Mod5   { ISO_Level3_Shift };
seems to help.
Comment 1 Honza Macháček 2007-10-10 12:01:12 UTC
Created attachment 11981 [details] [review]

This simple patch seems to repair VT switching for xkeyboard-config-1.1. Since handling of left alt is affected, other problems with left alt might be solved too.
Comment 2 Sergey V. Udaltsov 2007-10-10 15:39:31 UTC
I do not quite understand the problem. Could you please give me an example of the configuration with broken VT switch? I use two layouts: us, ru(winkeys) and it works ok for me.
Comment 3 Honza Macháček 2007-10-10 20:45:38 UTC
(In reply to comment #2)
> I do not quite understand the problem. Could you please give me an example of
> the configuration with broken VT switch? I use two layouts: us, ru(winkeys) and
> it works ok for me.

I use layouts us,cz  with options grp:lwin_toggle,grp_led:scroll. When I had found that both us and cz layouts worked well when used alone, but broke VT switching when combined, no matter the options, I tried us,us(intl) combination and found the same problem.

BTW, were you aware of the problem in 0.9, or was the us,ru(winkeys) combination immune to it even then?
Comment 4 Honza Macháček 2007-10-13 06:27:58 UTC
Can't wait for Sergey V. Udaltsov to confirm that I've provided the information needed; may be I actually should have changed the status immediately to signal my attempt on filling the information missing. Still learning bugzilla rules and habits.

In the meantime I found one box with xkeyboard-config unpatched and verified that the us,ru combination really works -- with or without the winkeys variant -- while my us,cz combination breaks Ctrl-Alt-Fn VT switching, and so does the us,us(intl) combination. This hopefully excludes irregularities in my distribution, installation, hardware or whatever.

Unfortunately I was unable to elucidate the origin of the bug or why it affects only layout combinations, not single layouts, and only some of them, though including the simple us,us(intl) one.

Well, having what looks like a working patch I am on the safe side for now, at least until next upgrade.
Comment 5 Sergey V. Udaltsov 2007-10-13 09:10:34 UTC
Patience, lads:)

I just did not have time to reply - but I seen your info.

Yes, the combination us,ru(winkeys)) really works. What's worse - your configuration works for me as well:

svu@linnie-the-pooh:~$ setxkbmap -model pc105 -layout us,cz -option -option grp:lwin_toggle,grp_led:scroll
svu@linnie-the-pooh:~$ xprop -root | grep XKB_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us,cz", "", "grp:lwin_toggle,grp_led:scroll"

So it is not reproducable :(

Could you please create "bad" (non-working) configuration and do "xkbcomp :0 -xkb out.xkb" - and attach resulting out.xkb
Comment 6 Benjamin Close 2008-01-11 02:39:07 UTC
Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler
Comment 7 Honza Macháček 2008-01-12 08:55:37 UTC
(In reply to comment #5)
  Sorry for responding so late. I had somehow missed the email notification of your reply (victim to some spam-filter on its way?), and looked at the bug just after the information of its recent change to reopen due to Bugzilla bugs classification changes.

  Looks like the keyboard behaviour depends not only on the xkeyboard-config package, but on some other parts of xorg too. Now, after the last upgrade, the unpatched xkeyboard-config-1.1 seems to work for me as well as for you. No trace of the former bug anawhere I've looked so far. So if you know why there should be

modifier_map Mod5   { <LALT> };

and not

modifier_map Mod5   { ISO_Level3_Shift };

you probably no longer have any reason to worry it brakes someone's installation.

  Unfortunately I can't even guess which upgrade solved the bug, since the most relevant package of the last upgrade seems to be fluxbox, and I have not checked for the bug for quite a long time, so too many other upgrades have passed.

  By the way
> setxkbmap -layout "us,cz" -option "grp:lwin_toggle,grp_led:scroll"
followed by
> xprop -root | grep XKB
gives me just one line:
_XKB_RULES_NAMES(STRING) = "xorg", "evdev", "us,cz", "", "grp:lwin_toggle,grp_led:scroll,grp:lwin_toggle,grp_led:scroll"

  Since I don't understand the nature of the bug, why it was there and is not (hopefully) anymore, I'm leaving the status unchanged, for you to decide. Moreover fluxbox might be the cause of the change after all, because its new Gentoo ebuild creates a new Xsession script that seems to do something with my keyboard. Solving a small problem with that (I suddenly have just the "us" layout after the start of X) I may possibly find some configuration options that I haven't used before and that repaired VT switching for me now.

  What about the following errors reported apparently after the setxkbmap invocation? Are they relevant to anything?

The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Multiple names for keycode 211
>                   Using <I211>, ignoring <AB11>
expected keysym, got XF86KbdLightOnOff: line 70 of pc
expected keysym, got XF86KbdBrightnessDown: line 71 of pc
expected keysym, got XF86KbdBrightnessUp: line 72 of pc
expected keysym, got XF86MonBrightnessDown: line 136 of inet
expected keysym, got XF86MonBrightnessUp: line 137 of inet
expected keysym, got XF86KbdLightOnOff: line 140 of inet
expected keysym, got XF86KbdBrightnessDown: line 141 of inet
expected keysym, got XF86KbdBrightnessUp: line 142 of inet
Errors from xkbcomp are not fatal to the X server
Comment 8 Jakub Moc 2008-01-12 09:00:16 UTC
+1, I can't reproduce this either after some unknown upgrade... (And no, this wasn't fluxbox related, same thing in Xfce and E17).
Comment 9 Sergey V. Udaltsov 2008-01-12 09:03:49 UTC
Ok, I think I'll close this one till someone manages to reproduce it with clean install of xkeyboard-config. Thank you lads for letting me know it is ok for you now.

PS Multiple names are ok. The missing keysyms are related to outdated version of xorg - they were added quite recently

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.