Created attachment 16824 [details] [review] Repair grp:*_toggle Here is a Debian bug report. Ever since 1.1 grp:alts_toggle and grp:ctrls_toggle do not work any more, as in: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us(intl),il" Option "XkbOptions" "grp:alts_toggle" EndSection Thanks for considering.
I do not feel confident about your patch. Look, in "alts_toggle" the LAlt key is setting virtualMods LAlt, right? At the same time, you set the type for RAlt as PC_ALT_LEVEL2 - which means it is shifted to level 2 by vmods Alt (not LAlt). How could it work? Would you please attach full output of "xkbcomp :0 -xkb out.xkb" with that alts_toggle enabled?
I can confirm that the patch as it is does NOT work correctly on Fedora 9 with xkeyboard-config-1.2-3.fc9.noarch.rpm The bug is known in fedora-land as https://bugzilla.redhat.com/show_bug.cgi?id=443763 Can the developers comment on the intention of the changes made to ctrl/alts_toggle between 1.1 and 1.2?
Created attachment 16901 [details] [review] slightly more obtrusive patch The attached patch works for me (adding Danish keyboard as alternative to Fedora 9s default "us+inet"); it allows me to toggle layouts with lalt+ralt. The patch essentially undoes changes made between 1.1 and 1.2. To me this step backwards is an improvement. What is lost by this? (I also notice that symbols/level3 refers to "AlGr" in both 1.1, 1.2 and git. I assume this typo might have consequences in this area.)
A couple of comments I forgot: PC_RALT_LEVEL2 (which is unused after my patch) is only defined with Level1 and Level2, but as far as I understand it was used in symbols/level3 in a way that required Level3 to be defined too? With the patch it LAlt+RAlt in that order toggles keyboard. But from the danish layout RAlt+LAlt in that order doesn't work. IMHO that's ok; I can live with that. But a better fix would be great. I assume that it requires a ralt_switch_for_alts_toggle definition with an action for ISO_Level3_Shift. That is perhaps the intention of (the IMHO strange) Level3 in PC_RALT_LEVEL2?
I confirm this bug. Is there documentation about this stuff? I would like to fix it properly and forever. Also, are the combinations meant to work regardless of the order? In GNOME it's displayed as "Both alt keys together", but when I ready this xkb stuff it seems LALT+RALT is not the same as RALT+LALT.
Felipe, have you tried my patch? Does it work for you? RALT+LALT works from US keyboard layout, but not from keyboards which use RALT as AltGr (at least not for Danish). AFAICS symbols/level3 contains a workaround which doesn't work fully. In the docs/ you will find plenty of documentation and references to other documentation. It is a quite complex system. ps: I'm not a xkeyboard-config developer
> The patch essentially undoes changes made between 1.1 and 1.2. To me this step > backwards is an improvement. What is lost by this? First change was done just by renaming types: http://webcvs.freedesktop.org/xkeyboard-config/xkeyboard-config/symbols/group?r1=1.10&r2=1.11 It was not functional change - about names only. The second patch was really more dramatic: http://webcvs.freedesktop.org/xkeyboard-config/xkeyboard-config/symbols/group?r1=1.11&r2=1.12 (and the commit message was unfortunately irrelevant) The actual bug was #7430
Sergey, you were right at http://bugs.freedesktop.org/show_bug.cgi?id=7430#c7 : "this can raise a hell" ;-) I agree that the patch I proposed will reopen bug 7430. I think that I was hit by that bug when I was using 1.1 too. But I do find the current bug more annoying than 7430. An obvious workaround is to deprecate ctrl/alts_toggle and let me and Gnome get used to another shortcut. But why isn't the current code working? Did it work correctly when it was checked in? I haven't yet figured out when and why virtualMods and virtual_modifiers has to be specified. It seems like they isn't used consistently.
> Sergey, you were right at http://bugs.freedesktop.org/show_bug.cgi?id=7430#c7 : > "this can raise a hell" ;-) You know, I spent some time in that project. Any non-trivial change is a hellraiser. Typical:) > I agree that the patch I proposed will reopen bug 7430. I think that I was hit > by that bug when I was using 1.1 too. But I do find the current bug more > annoying than 7430. I want the root cause to be fixed. The current code is _correct_. The problem is with xkb in general (see below). > But why isn't the current code working? Did it work correctly when it was > checked in? I thought it did, when I tried. But I was testing it incorrectly - not the way GNOME works. > I haven't yet figured out when and why virtualMods and virtual_modifiers has to > be specified. It seems like they isn't used consistently. So, (drums rolling) .... here is where REAL problem is: #4927
Ok, so this bug is actually a duplicate of http://bugs.freedesktop.org/show_bug.cgi?id=4927#c4 ? The problem is with the format that the compiler feeds into the X server - xkm? Could Gnome (or I) load the keyboard layout differently so that the xkm format is avoided? Do I understand you correctly that the current code is theoretically correct, but doesn't work until the catch-all bug 15540 is fixed? Shouldn't http://webcvs.freedesktop.org/xkeyboard-config/xkeyboard-config/symbols/group?r1=1.11&r2=1.12 wait / be backed out until that had happened? Can a temporary workaround be made within the limits of xkm?
> Ok, so this bug is actually a duplicate of > http://bugs.freedesktop.org/show_bug.cgi?id=4927#c4 ? Yes. > The problem is with the format that the compiler feeds into the X server - xkm? > Could Gnome (or I) load the keyboard layout differently so that the xkm format > is avoided? Yes. GNOME could pass not xkm but component names into xorg server. But that would trigger another problem (network transparency would suffer) > Do I understand you correctly that the current code is theoretically correct, > but doesn't work until the catch-all bug 15540 is fixed? Yes you do. > Shouldn't > http://webcvs.freedesktop.org/xkeyboard-config/xkeyboard-config/symbols/group?r1=1.11&r2=1.12 > wait / be backed out until that had happened? Can a temporary workaround be > made within the limits of xkm? Just reversing that patch. Which would reopen #7430 :) If you have better idea - pray tell me!
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/43.
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.