When an XF86 symbol (not all of them, just some of them) is added to a shift level, the first shift level of the key will no longer function correctly. Moreover, even if the symbol is removed, the first shift level will remain non-functional until x is restarted (e.g. by logging out and back in). Example: Replace "key <AD01> { [ q, Q ] };" with "key <AD01> { [ q, Q ], [ XF86WWW ] };" and then back to "key <AD01> { [ q, Q ], [ XF86WWW ] };". Lowercase q will no longer appear while typing and http://en.key-test.ru/ does not detect the keypress. Interestingly, capital Q still works fine and XFCE is able to detect the keypress even for lowercase q when setting application shortcuts (though after being set, the shortcut will not work).
Socialdarwinist suggested before, using two group in the same layout could be not to work correctly. I am look at the one line example, it seems the groups are assimetrics. I think, it would be better using four layout instead of two groups. But it possible, that caps lock switches between 3rd and 4th level would not to work.
(In reply to Kovács Viktor from comment #1) The issue doesn't seem to depend on the position of the XF86 key--"key <AD01> { [ q, Q, XF86WWW ] };" and "key <AD01> { [ XF86WWW, q, Q ] };" produce the same result. Unfortunately, macintosh_vndr/apple(alukbd) uses XF86AudioMute in <FK10>, hence rendering the F10 key unusable (though F10 seems to be the only key affected).
Draw wrote:"...even if the symbol is removed, the first shift level will remain non-functional until x is restarded" That is normal, xkb needs reconfiguration. I suggest, q and Q must to be in the 1st and 2nd positions. The keys type setted as four level semialphabetic? Included third level switch combination?
After some fiddling I have acquired a lot more details: -The problematic symbols are those that have been assigned to keyboard shortcuts in XFCE. -In xev on press and release, good keys produce a KeyPress event followed by a KeyRelease event while bad keys produce a FocusOut event followed by a FocusIn and subsequently a KeymapNotify event. -The focus events apply to the shift level of the symbol that is being used for the shortcut. So if I define a keyboard shortcut for Q I will not be able to use the second level of any key containing Q even if it isn't actually on the second level for subsequent keys. I tested this by creating a second key with q and Q switched and defining a shortcut on Q and for the second key q opened the shortcut while Q printed a capital Q. So I think I found the issue: XFCE defines keyboard shortcuts based on the shift level of the key used to define the shortcut rather than on the shift level that actually contains the shortcut symbol which causes problems if you have a symbol on multiple keys and at a different shift level on each key. I guess that would make this an XFCE issue?
Could you attach the file working with? Please add comment in the file, where and what would you want to do! Not as patch!
(In reply to Drew from comment #4) > So I think I found the issue: XFCE defines keyboard shortcuts based on the > shift level of the key used to define the shortcut rather than on the shift > level that actually contains the shortcut symbol which causes problems if > you have a symbol on multiple keys and at a different shift level on each > key. I guess that would make this an XFCE issue? Yep, you're exactly right. The FocusIn/FocusOut events (with detail FocusGrabbed) means that XFCE has grabbed the key and is stealing it away from clients.
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.