| Summary: | Third level chooser dysfunct in untrusted clients | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Lasse Kliemann <lasse-freedesktop-2008> | ||||
| Component: | App/xkbcomp | Assignee: | Xorg Project Team <xorg-team> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | low | ||||||
| Version: | unspecified | ||||||
| Hardware: | x86 (IA32) | ||||||
| OS: | Linux (All) | ||||||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=50611 | ||||||
| Whiteboard: | 2011BRB_Reviewed | ||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
Additional observations: When the solution with two groups is used (the xmodmap approach), the third symbol is reachable from untrusted clients when pressing a key bound to ISO_Level3_Shift, but not when pressing a key bound to Mode_switch. For trusted clients (with XKB support), it is the other way round. When I dump the current map to an xkb-file: xkbcomp :0 test.xkb then add a second group for keys with more then two symbols, map a key to Mode_switch, and, most importantly add group 2 = AltGr; to xkb_compatibility, and load up the modified file: xkbcomp test.xkb :0 then Mode_switch acts as desired, for both trusted and untrusted clients. The effect of Mode_switch as reported by xev: client ! Without group 2 = AltGr ! With group 2 = AltGr ! ------------------------------------------------------------ trusted ! Sets second group ! Sets second group ! untrusted ! no effect ! Sets Mod5 ! So, the problem seems to be that the group compatibly map as described in section 12.1 of "The X Keyboard Extension: Protocol Specification" does not work properly. Why it does not work, I do not understand. xkeyboard-config in compat/basic already contains "group 2 = AltGr". Also, Mod5 is bound to Mode_switch in the modifier_map, and AltGr is associated to Mod5. For the time being, the problem can be worked around as described above, or by using both a second group and a third level that both contain the third symbol, and switching to the additional symbol using ISO_Level3_Shift. Created attachment 53959 [details] [review] Workaround in xkeyboard-config Just a workaround, the bug is in xkbcomp. Submitted a patch for xkbcomp: http://patchwork.freedesktop.org/patch/8146/ (In reply to comment #3) > Submitted a patch for xkbcomp: http://patchwork.freedesktop.org/patch/8146/ This patch has solved the problem for me. Thank you! Committed to xkbcomp, thanks. |
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.
My keyboard layout makes use of a third level chooser to give additional meaning to certain keys, e.g. key <AD01> { [ q, Q, slash ] }; The third level chooser is defined like so (here the space bar): key <SPCE> { symbols[Group1] = [ ISO_Level3_Shift ] }; So when I press space and Q, I get '/'. This works fine so far. However, when I start an untrusted client, the third level chooser stops working (so pressing space and Q produces 'q', not '/'). Otherwise the layout is maintained. The same happens when using xmodmap. For example, I have a file with the following content: keysym q = q Q slash keysym space = Mode_switch I load it using xmodmap as a trusted client. Then create an untrusted cookie using xauth generate :0 . untrusted and switch to a different user account (via su or whatever) with that cookie in ~/.Xauthority and start an xterm. The combination of space and Q then produces 'q' and no slash anymore. When other changes are done, like for instance keysym q = q X slash then these are available to the untrusted client, i.e., Shift-Q produces an 'X' in a trusted as well as an untrusted client. I am using the latest release of each component from <ftp://ftp.x.org/pub/individual/>. But I remember the same or a similar problem being present in older releases as well. The latest known working release was 7.2.