When using Neo2 keyboard layout it's not possible to switch to Mod4 (Layer 4, Navigation and Numbers), b/c [<>]-key or [ALT-GR]-Key is obviously dead. Using Gnome 3.2.2.1 on Debian Wheezy.
(In reply to comment #0) > When using Neo2 keyboard layout it's not possible to switch to Mod4 (Layer 4, > Navigation and Numbers), b/c [<>]-key or [ALT-GR]-Key is obviously dead. What does xev report when you press Neo's Mod4 (=ISO_Level5_Shift) keys? Can you enter normal symbols on "Layer 4" (=Level5), for example, can you enter "¿" ?
Could you please attach the result of "xkbcomp :0 -xkb out.xkb"?
Created attachment 69942 [details] log of xev
> What does xev report when you > press Neo's Mod4 (=ISO_Level5_Shift) keys? See attached file. >Can you enter normal symbols on "Layer 4" (=Level5), > for example, can you enter "¿" ? No. When "Layer 4" is pressed always "normal" chars appear ("s" but not "¿" f.i.). By the way: It turns out that things depend on the order of keyboard layouts in gnomes "Region and Language Settings" dialog (See attached file again). For both: only the first in the list works fine: When Neo is the first I can use "Level 4" when Neo is selected. But I can't type "<" f.i. when German (eliminate dead keys) is selected. With switched order I have the originally described problem.
Created attachment 69943 [details] xkbcomp :0 -xkb out.xkb
Comment on attachment 69943 [details] xkbcomp :0 -xkb out.xkb My guess is that the reason for the problems is the useModMapMods=level1 in: interpret ISO_Level5_Shift+AnyOf(all) { virtualModifier= LevelFive; useModMapMods=level1; action= SetMods(modifiers=LevelFive,clearLocks); }; We would know for sure if we had the output of "xkbcomp -a :0 out.xkb". The pain is to get virtual modifiers associated to real modifiers. If I remember correctly, if one would remove the line in question, one would get problems with setups that support Neo's Layer 4 lock, or maybe with the right Alt key when another layout besides Neo is used. If Stephan is subscribed to xkb, he might have a comment. For the usual modifiers, in symbols/pc: // Fake keys for virtual<->real modifiers mapping key <LVL3> { [ ISO_Level3_Shift ] }; key <MDSW> { [ Mode_switch ] }; modifier_map Mod5 { <LVL3>, <MDSW> }; key <ALT> { [ NoSymbol, Alt_L ] }; include "altwin(meta_alt)" key <META> { [ NoSymbol, Meta_L ] }; modifier_map Mod1 { <META> }; key <SUPR> { [ NoSymbol, Super_L ] }; modifier_map Mod4 { <SUPR> }; key <HYPR> { [ NoSymbol, Hyper_L ] }; modifier_map Mod4 { <HYPR> }; Apparently, we use six fake keycodes to bind at most four virtual modifiers to real modifiers. If we would use the keycodes more economically, we could free two of these valuable fake keycodes to bind Level5 to Mod3 and NumLock to Mod2. Sergey, do you think this is possible? If so, one would not have to add real keys to the modifier_map, which would save some trouble.
Andreas, I am nor sure how to do that "more economically". What do you mean?
Created attachment 69984 [details] xkbcomp -a :0 out.xkb
(In reply to comment #7) > Andreas, I am nor sure how to do that "more economically". What do you mean? Basically, this: key <LVL3> { [ ISO_Level5_Shift ] }; modifier_map Mod3 { <LVL3> }; key <MDSW> { [ Mode_Switch, ISO_Level3_Switch ] }; modifier_map Mod5 { <MDSW> }; key <ALT> { [ NoSymbol, Alt_L ] }; include "altwin(meta_alt)" key <META> { [ NoSymbol, Meta_L ] }; modifier_map Mod1 { <META> }; key <SUPR> { [ NoSymbol, Super_L, Hyper_L ] }; modifier_map Mod4 { <SUPR> }; key <HYPR> { [ NoSymbol, Num_Lock ] }; modifier_map Mod2 { <HYPR> }; For this to work, useModMapMods=level1 for ISO_Level3_Shift in compat/iso9995 should be removed, and the modfier_map settings in symbols should be scanned to remove unnecessary modifier_map settings for Mod2, Mod3 and Mod5. The latter is a somewhat dangerous operation, I am afraid... Regarding Guido's xkbcomp -a output, it confirms that LevelFive is not connected to a real modifier, thus ISO_Level5_Shift has no effect.
It appears the easiest solution for the problem at hand is to use the option lv5:lsgt_switch_lock. On the command line: setxkbmap de,de ,neo -option -option lv5:lsgt_switch_lock In a GUI layout chooser, look for an option similar to "Less/Greater chooses 5th level, locks when pressed together with another 5th-level-chooser" and select it. Basically, it does something similar to what I proposed previously, it uses some of the fake keysyms to make sure LevelFive (and NumLock) are bound to real modifiers. lv5:lsgt_switch_lock also offers a Level5 lock. It is coincidential that lv5:lsgt_switch_lock works here; it uses a remenant of the full Neo Level 5 lock that was temporarily disabled in xkeyboard-config due to a bug that is not directly related. The other issue reported (< does not work in de as second layout when Neo is first layout) is due to the fact that LSGT is mapped in symbols/pc, and overwritten by de(neo), but not by de. It appears that only the primary layout includes the stuff set in symbols/pc, so de does not set LSGT back. I wonder whether this is intentional. The ch layout does not have this problem.
> For this to work, useModMapMods=level1 for ISO_Level3_Shift in > compat/iso9995 should be removed, and the modfier_map settings in symbols > should be scanned to remove unnecessary modifier_map settings for Mod2, Mod3 > and Mod5. The latter is a somewhat dangerous operation, I am afraid... Yes, I suspect we may break a lot of things with that... Let's just stick to the xkb option lsgt_switch_lock We can try adding LSGT mapping to de - that does not look like a big breakage.
> Yes, I suspect we may break a lot of things with that... Let's just stick to > the xkb option lsgt_switch_lock Unfortunately, I noticed that it does not solve the proble. Neo then works in the second group allright, but the "<" for de in the first group gets broken. Options go to the first layout... > We can try adding LSGT mapping to de - that does not look like a big > breakage. That would be the smallest change, and sufficient, provided Guido is willing to make Neo the primary layout. By the way, the Neo web page contains the old versions with full Level 5 lock. It "include"s the Level-5 keys rather than using options, so with that, Neo should also work as second layout without mutilating de as primary layout.
> That would be the smallest change, > and sufficient, provided Guido is > willing to make Neo the primary layout. I believe that many users want to test Neo first and therefore will use Neo as a second layout. And if they have to choose Neo as primary layout they might have trouble with passwords and so on (especially login password). On the other hand it's up to the login manager to let the user choose the keyboard layout for login.
Created attachment 70390 [details] [review] Allow de and Neo, no matter which is primary. The patch does slightly more than the minimal of repeating LSGT mapping in de. It also makes sure that LevelFive is bound to Mod3 when Neo is secondary layout. The approach is the same as for level5(lock).
I have also noticed this here: http://cgit.freedesktop.org/libxkbcommon/commit/?id=b9c87eb710ba4a86455601ca8c5a516b25e20366 But haven't looked at it since. I can help with testing the proposed solutions, later. Andreas, Sergey, I have a question though. Why does xkeyboard-config need the fake keycodes thing anyway? Is it purely for core X11 compatibility? I mean, why not just do virtual_modifiers Super = Mod4; virtual_modifiers LevelThree = Mod5; etc, instead of the that awful indirection? Doing the above just sets the vmod-to-real-mod mapping directly, see here: http://cgit.freedesktop.org/xorg/app/xkbcomp/tree/xkbparse.y?id=a68c5b7b29eb1433b1be73b50c4248e10eab8e64#n361 http://cgit.freedesktop.org/xorg/app/xkbcomp/tree/vmod.c?id=a68c5b7b29eb1433b1be73b50c4248e10eab8e64#n147 I don't see it used in xkeyboard-config anywhere.
(> Andreas, Sergey, I have a question though. Why does xkeyboard-config need > the fake keycodes thing anyway? Is it purely for core X11 compatibility? I suppose it is for compatibility for people using xmodmap. They can clear the real modifiers map and then add them as they desire, so they can change the virtual to real modifier relation. As far as I can tell, applications also look at the keysyms mapped to the keys that have a real modifier in their modifier map to find out how to interpret that real modifier. For example, if they see a real modifier Mod4 in the modifier map of a key that has keysym Super_L on it, they conclude that Mod4 means "Super". Whether this is true for all applications, or whether some applications also look at the name of virtual modifiers associated with real modifiers, I do not know. Anyway, the "awful redirection" as you rightly call also establishes a link between real modifiers and keysyms, and is certainly important for compatibility. For Mode_switch, the core protocol even specifies that the real modifier associated to this keysym is the one that indicates the second group. > I mean, why not just do > virtual_modifiers Super = Mod4; > virtual_modifiers LevelThree = Mod5; > etc, instead of the that awful indirection? I did not know about this feature, it looks useful. In which section of the xkb file does this appear? Another possibility to simplify matters would be to drop virtual modifiers like LevelThree, LevelFive, AltGr and NumLock entirely and to work directly with real modifiers. I use a highly customised layout where I do just this, and I did not see problems with applications in the 3.5 years since I am using this approach. I must say I never understood the benefits of virtual modifiers. They just conceal that the real modifiers are a very limited resource that needs to be carefully managed, and that introducing virtual modifiers like LControl does not buy anything over using Control unless a real modifier is sacrificed for it.
(In reply to comment #16) > (> Andreas, Sergey, I have a question though. Why does xkeyboard-config need > > the fake keycodes thing anyway? Is it purely for core X11 compatibility? > > I suppose it is for compatibility for people using xmodmap. They can clear > the real modifiers map and then add them as they desire, so they can change > the virtual to real modifier relation. > > As far as I can tell, applications also look at the keysyms mapped to the > keys that have a real modifier in their modifier map to find out how to > interpret that real modifier. For example, if they see a real modifier Mod4 > in the modifier map of a key that has keysym Super_L on it, they conclude > that Mod4 means "Super". Whether this is true for all applications, or > whether some applications also look at the name of virtual modifiers > associated with real modifiers, I do not know. > > Anyway, the "awful redirection" as you rightly call also establishes a link > between real modifiers and keysyms, and is certainly important for > compatibility. For Mode_switch, the core protocol even specifies that the > real modifier associated to this keysym is the one that indicates the second > group. OK, so it's basically compatibility... I see. The way modifiers work is really the most complicated part of XKB, in my opinion. The approach of looking at keysyms to find the modifiers is truly broken, if one has the option to use XKB rather than just plain X11 (though doing this with XKB is not particularly easy). I always cringe when I see code which goes over the keycodes like this: http://cgit.freedesktop.org/xorg/app/xkbcomp/tree/symbols.c?id=bd1103ef3cfef9cfed645566f944a69e7ca568b4#n1698 http://cgit.freedesktop.org/xcb/util-keysyms/tree/keysyms/keysyms.c?id=5a3906f700a975653da7f64a2d66ebdbea8b8b34#n240 http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkkeys-x11.c?id=fbdb81bbdf5d366ddd60255eefd29a00da65e2dc#n772 We recently discussed this in relation to XCB, and I wrote some code to do it with xcb-xkb. See here (starting from comment 7): https://bugs.freedesktop.org/show_bug.cgi?id=56866#c7 I think GTK already does this, and Qt hopefully will too. > > I mean, why not just do > > virtual_modifiers Super = Mod4; > > virtual_modifiers LevelThree = Mod5; > > etc, instead of the that awful indirection? > > I did not know about this feature, it looks useful. In which section of the > xkb file does this appear? Anywhere 'virtual_modifiers' can appear, i.e. types, compat and symbols (generally wherever a virtual modifier is used in a file, it should also be declared there. Pretty silly if you ask me. It is only enforced in the 'virtualMod' field in interprets, though). > Another possibility to simplify matters would be to drop virtual modifiers > like LevelThree, LevelFive, AltGr and NumLock entirely and to work directly > with real modifiers. I use a highly customised layout where I do just this, > and I did not see problems with applications in the 3.5 years since I am > using this approach. > > I must say I never understood the benefits of virtual modifiers. They just > conceal that the real modifiers are a very limited resource that needs to be > carefully managed, and that introducing virtual modifiers like LControl does > not buy anything over using Control unless a real modifier is sacrificed for > it. As I said, virtual modifiers are messy. But we're planning on using them to good effect in libxkbcommon; mostly to be able to query the keyboard state for specific virtual modifiers, rather than just the core ones. So if you bind both Alt and Meta to Mod1, and someone else binds Meta to Mod5, when querying for "Meta" only the first one will return true. It also renders all of the code in the aforementioned bug unnecessary. I'm still experimenting: https://github.com/bluetech/libxkbcommon/commit/5badcc222b73aa5ee82cd34d10265f9c6ded50de So, I would actually like to see RControl, LControl etc. being set by default in all keymaps, rather than removed. In this specific case it actually makes sense: if the application is interested in some general "Control" modifier, it uses "Control", and both Left and Right set it as expected. However, if the application wants to test specifically for the left Control for some reason, it can do so as well. XKB doesn't really expose virtual modifiers this way, but we can :) Though I agree that some specific vmods like LevelThree and LevelFive serve no purpose for the end user, they are only for the xkb_types AFAICT.
> The approach of looking at keysyms to find the modifiers is truly broken, if > one has the option to use XKB rather than just plain X11 (though doing this > with XKB is not particularly easy). I agree, using the names of virtual modifiers seems more logical. At least, the decision what to do if a key has multiple groups or levels with different modifier keysyms is not left to the application. > Anywhere 'virtual_modifiers' can appear, i.e. types, compat and symbols > (generally wherever a virtual modifier is used in a file, it should also be > declared there. Pretty silly if you ask me. It is only enforced in the > 'virtualMod' field in interprets, though). I played a bit with it, using a "fully resolved" xkb file. xkbcomp warns if a modifier is set in compat, but not in types. But it seems to work nicely. Still, for emacs (build with xaw), real modifiers have to be assigned to a keysym, or else emacs will not know what to do with them. If the direct assignment of real modifiers to virtual modifiers also works when the keymap is build from bits and pieces as it is for xkeyboard-config, this would be very valuable. > So, I would actually like to see RControl, LControl etc. being set by default > in all keymaps, rather than removed. In this specific case it actually makes > sense: if the application is interested in some general "Control" modifier, it > uses "Control", and both Left and Right set it as expected. However, if the > application wants to test specifically for the left Control for some reason, it > can do so as well. XKB doesn't really expose virtual modifiers this way, but we > can :) And if the application is interested particularly in a right control key, it will be unusable with keyboards (or layouts) that only have a left control key. If the application is particularly interested in a right Alt key, it will be unusable with the many layouts that have an AltGr (level 3 shift) key instead of a right alt key. Of course, that problem exists with other modifiers such as Hyper as well. But I believe if you inflate the number of modifiers applications can distinguish, the problem becomes more severe. And it is not about applications only, it is also about the server. For example, xkeyboard-config has three types, PC_CONTROL_LEVEL2, PC_LCONTROL_LEVEL2, and PC_RCONTROL_LEVEL2. The latter two will either not work at all (in case LControl and RControl are not bound to a real modifier) or do the same as the first one (in case LControl and RControl are bound to Control). This is not only confusing, it also brings us back to this ticket: Neo2 in xkeyboard-config misbehaves due to changes that had to be made to reduce the number of types...
> Still, for emacs (build with xaw), real modifiers have to be assigned to a keysym, or else emacs will not know what to do with them. I suspect that may be the issue for some other legacy apps/libraries. The practice to have real modifier mapped to keysym is old enough. Can we afford breaking it?
First, I am afraid that we get carried away discussing issues that are relevant for longer term maintenance of xkeyboard-config, and forget about the actual bug report. I believe my patch is an adequate remedy that fits current practice in xkeyboard-config. Stephan, would you please review it? My personal opinion regarding the longer term issues: > I suspect that may be the issue for some other legacy apps/libraries. The > practice to have real modifier mapped to keysym is old enough. Can we afford > breaking it? For LevelThree and LevelFive, I do not see problems. For NumLock and AltGr, one has to pay attention that the real modifiers these virtual modifiers are mapped to are still associated to keysym Num_Lock and Mode_switch, for compatibility with the core protocol. For Num_Lock, this is only relevant if the actual layout supports a NumLock, while for Mode_switch, even for layouts that do not contain the keysym Mode_switch, the association is required for ISO_Group_Lock et al to work with non-XKB clients. I do not think one can afford to remove the relation to keysysms for modifiers Alt, Meta, Super, and Hyper. While it is undeniable that using virtual modifiers to find out the meaning of real modifiers has advantages, there are disadvantages, too: - Non-XKB aware clients will not use virtual modifiers. It is hard to tell how many such clients are in use, but even some current software falls into this class. To name examples, the awesome and stumpwm window managers. - There is no standard what virtual modifiers exist, while keysyms are standardised in the X Window System Protocol, Appendix A. This is no big deal from the practical point of view, it just means that xkeyboard-config should specify which virtual modifiers applications can rely on, and commit to never remove those. - If clients want to work with non XKB-aware servers, they have to support the keysym way to find the meaning of real modifiers. One might think that non XKB-aware servers are not relevant anymore, but in the company I where work, many people actually use such a beast as part of a remote X desktop solution. Furtermore, X servers will pretend not to be XKB-aware to clients connected over an 'untrusted' X connection. Compatibly with non-XKB servers might be a reason even for modern clients to stick with the 'legacy' approach exclusively.
(In reply to comment #20) > I believe my patch is an adequate remedy that fits current > practice in xkeyboard-config. Stephan, would you please review > it? I agree to the first part regarding LSGT. Another note for allowing de(neo) to be the first and de the second one: CapsLock has have to be redefined as well in symbols/de (the same issue as with LSGT, being defined only once in symbols/pc) But I've always wondered why symbols/pc isn't applied to any but the first group. Regarding the other part: When using de as first and de(neo) as second layout RALT seems to be bound to Mod3 but because on the first group RALT has the ISO_LEVEL3_SHIFT keysym and this keysym is bound to Mod5 by level3(ralt_switch) the LevelThree virtual modifier gets bound to both Mod3 and Mod5 through the RALT keycode. I'd like to propose something similar to your solution but for both level5 and level3 (see attached patch). With this patch the real modifiers get bound to a virtual modifier only through fake keycodes, which accounts for both the case where a key gets bound to a different modifier by the first layout (and thus the second layout loses its modifier behaviour as in this bugreport) and the above case where two virtual modifiers would get bound to the same keycode. Not sure if my patch is the way to go, but it gets the modifier mapping done in a way that is safe for multiple layouts. Essentially it is enforcing the following fake keycode mappings for every use of level3 and level5: LevelThree -> <LVL3> -> Mod5 LevelFive -> <MDSW> -> Mod3 I may have missed something, please tell me what you think.
Created attachment 70934 [details] [review] Always use fake keycode bindings for level3 and level5
> Another note for allowing de(neo) to be the first and de the second one: > CapsLock has have to be redefined as well in symbols/de (the same issue as > with LSGT, being defined only once in symbols/pc) Good catch. > But I've always wondered why symbols/pc isn't applied to any but the first > group. Maybe the assumption was that variations in keyboard hardware and keyboard layouts are independent. Which is not the case, at least not if common keys such as LSGT and CAPS are considered keyboard hardware specific. Can this be addressed by extending the rules? > When using de as first and de(neo) as second layout RALT seems > to be bound to Mod3 but because on the first group RALT has the > ISO_LEVEL3_SHIFT keysym and this keysym is bound to Mod5 by > level3(ralt_switch) the LevelThree virtual modifier gets bound > to both Mod3 and Mod5 through the RALT keycode. I do not observe this. My guess is that you overlooked that I removed one 'modifier_map Mod3 { ISO_Level5_Shift };' line. > LevelThree -> <LVL3> -> Mod5 > LevelFive -> <MDSW> -> Mod3 > > I may have missed something, please tell me what you think. You could remove level3(modifier_mapping), as this is already achieved in symbols/pc. Otherwise, removing the modifier binding via keysyms ISO_Level3_Shift and ISO_Level5_Shift as your patch does is a step in the right direction. Your patch is also more complete, as it addresses all the Level5 options. The difference between the patches comes down to minimal vs. complete. I am fine with whatever Sergey prefers.
Thanks for the patch, I gave it quick test - it seems ok. Personally, I do not use levels >=3, so can just hope it is ok for all scenarios. Let's push and see what people say.
(In reply to comment #23) > Can this be addressed by extending the rules? I don't know about that but I can look into it. > I do not observe this. My guess is that you overlooked that I removed one > 'modifier_map Mod3 { ISO_Level5_Shift };' line. You can try it out for yourself by setting de as the first one and de(neo) as the second one. Everytime a level3-key is pressed (RALT with de and CAPS or BKSL with de(neo)) both the Mod3 and the Mod5 real modifier are in use (I use xkbwatch to observe the modifier states). The layouts themselves behave correctly (probably because only one of them is recognized) When removing the keysym to modifier bindings modifier_map Mod5 { ISO_Level3_Shift }; and instead using the fake keycode binding (as in the patch) the problem disappears. > You could remove level3(modifier_mapping), as this is already achieved in > symbols/pc. Thats right (again assuming everyone using level3/level5 uses symbols/pc as a base), we could in that case as well remove any modifier_map statements in symbols/level3 as they are done by the fake keycode in symbols/pc. That would clean things up a bit, but I'm not sure we can rely on everyone using symbols/pc.
(In reply to comment #23) > > But I've always wondered why symbols/pc isn't applied to any but the first > > group. > > Maybe the assumption was that variations in keyboard hardware and keyboard > layouts are independent. Which is not the case, at least not if common keys > such as LSGT and CAPS are considered keyboard hardware specific. > > Can this be addressed by extending the rules? I'd leave it as it is for now and redefine LSGT and CAPS in de if necessary. All the options go to the first group. Layout switching options would be overridden on any but the first group.
> You can try it out for yourself by setting de as the first one and de(neo) as > the second one. > Everytime a level3-key is pressed (RALT with de and CAPS or BKSL with de(neo)) > both the Mod3 and the Mod5 real modifier are in use (I use xkbwatch to observe > the modifier states). I do not see this, not even in xbkwatch. > The layouts themselves behave correctly (probably because only one of them is > recognized) But under Neo, with Mod3 and Mod 5 set, you should get Level7 (Ebene 6) instead of Level3. Strange. > That would clean things up a bit, but I'm not sure we can rely on everyone > using symbols/pc. You are right, but unfortunately, we overlooked that we already introduced a similar issue: Not all keyboard models define a LVL3 keycode. For them, Level3 switching is currently broken. Same thing for MDSW and Level5, but here the user base is small. I do not know what is best. Adding keycodes for LVL3 and MDSW to all models, or revert the changes to symbols/level3, or something else? > All the options go to the first group. With similar consequences as for symbols/pc. For example, using an option that involves RALT, while using de as secondary layout will not work under de. But I agree that fixing LSGT and CAPS for de will be sufficient for this bug report.
(In reply to comment #27) > I do not see this, not even in xbkwatch. I'm using Arch-Linux with current updates (xorg-server 1.13) but I saw this also on an Ubuntu 12.04 machine. > But under Neo, with Mod3 and Mod 5 set, you should get Level7 (Ebene 6) > instead > of Level3. Strange. This is explainable: the xkb-types use the virtual modifier to determine the level, not the real one. > I do not know what is best. Adding keycodes for LVL3 and MDSW to all models, > or revert the changes to symbols/level3, or something else? I'm not sure about this either.
FYI if someone complains about this: Because the patch uses explicit virtual modifiers, i.e.: + vmods = LevelThree, It triggers this old bug: https://bugs.freedesktop.org/show_bug.cgi?id=4927 So if you do this: setxkbmap -layout de (or another 3-level layout) xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY The LevelThree virtual modifier is no longer bound, so the key type entry becomes inactive, and you can't use AltGr to switch to Level3. (This is not really severe, however we do actually have a use case for doing something like this. So if anyone can come up with a fix that would be appreciated).
> xkbcomp $DISPLAY out.xkb > xkbcomp out.xkb $DISPLAY > (This is not really severe, however we do actually have a use case for doing something like this. Thank you for this hint. I believe I already have been affected by this, when I tried to explain someone to make a customisation for his personal layout, and doing the above "destroyed" his layout (however, in this case, it was for Level5 rather than Level3, and the problem existed before the recent change). > So if anyone can come up with a fix that would be appreciated). It should be possible to remove the explicit virtual modifier specifications and the explicit actions, and rely on the virtual modifier specifications through compat, right? On the other hand, I wonder whether using virtual modifiers for level selection is still maintainable. In my local repository, I eliminated LevelThree, LevelFive, NumLock, and AltGr, and use the real modifiers directly. If there is willingness to consider such a radical step, I can collect the related changes and provide a patch.
> setxkbmap -layout de (or another 3-level layout) > xkbcomp $DISPLAY out.xkb > xkbcomp out.xkb $DISPLAY > > The LevelThree virtual modifier is no longer bound, so the key type entry > becomes inactive, and you can't use AltGr to switch to Level3. I see this even after reverting the patch (05dcc6db). On the other hand this seems to work both with and without the patch: setxkbmap -print de | xkbcomp - $DISPLAY xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY I don't really get it, but this: setxkbmap -print de | xkbcomp - out.xkb xkbcomp out.xkb $DISPLAY xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY is indeed currently broken but works with the patch reverted. > It should be possible to remove the explicit virtual modifier specifications > and the explicit actions, and rely on the virtual modifier specifications > through compat, right? Yes, that should be fine (fixes the last testcase for me but not the original one). > On the other hand, I wonder whether using virtual modifiers for level > selection is still maintainable. In my local repository, I eliminated > LevelThree, LevelFive, NumLock, and AltGr, and use the real modifiers > directly. If there is willingness to consider such a radical step, I can > collect the related changes and provide a patch. I don't like to do this just to circumvent the inability of xkm/xkbcomp to handle virtual modifiers.
I would prefer to keep virtual modifiers, if possible. They provide some small abstraction layer.
Created attachment 75042 [details] [review] removes the explicit virtual modifier specifications > > It should be possible to remove the explicit virtual modifier specifications > > and the explicit actions, and rely on the virtual modifier specifications > > through compat, right? > > Yes, that should be fine (fixes the last testcase for me but not the > original one). Created a patch for this.
(In reply to comment #33) > Created attachment 75042 [details] [review] [review] > removes the explicit virtual modifier specifications > > > > It should be possible to remove the explicit virtual modifier specifications > > > and the explicit actions, and rely on the virtual modifier specifications > > > through compat, right? > > > > Yes, that should be fine (fixes the last testcase for me but not the > > original one). > > Created a patch for this. Yes, as Andreas said, with this patch our tests (in libxkbcommon) show that switching to Level5 no longer works with de(neo) when it's not the first layout. I can also reproduce it with X.
> > Created a patch for this. > > Yes, as Andreas said, with this patch our tests (in libxkbcommon) show that > switching to Level5 no longer works with de(neo) when it's not the first > layout. I can also reproduce it with X. setxkbmap de,de ,neo then switching to the second group and using level5 works just like before the patch for me. Still broken is setxkbmap de neo xkbcomp $DISPLAY out.xkb xkbcomp out.xkb $DISPLAY and then using level3/level5. but as far as I can see, this was broken even before 05dcc6db.
Thanks, it looks clean for now. Committed. Let's see what people say. If they are unhappy - it is easy to revert. > Created a patch for this.
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.