Created attachment 11981 [details] [review]
xkeyboard-config-1.1-VTswitch.patch

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.

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.

(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?

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.

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

Bugzilla Upgrade Mass Bug Change

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

  - benjsc
    fd.o Wrangler

(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

+1, I can't reproduce this either after some unknown upgrade... (And no, this wasn't fluxbox related, same thing in Xfce and E17).

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