[Desktop-packages] [Bug 1831264] Re: Sun keyboard Front key not accepted by gnome-control-center
Although reported to gitlab.freedesktop.org (see above), there is no sign whatsoever of activity in that quarter. In the meantime, I have just downloaded the latest batch of 18.04 updates, and the situation has got immeasurably worse. The relevant part of the xmodmap -pk output has now changed to: 136 0xffc8 (F11)0xffc8 (F11)0xffc8 (F11)0xffc8 (F11) 0xff69 (Cancel) 0x (NoSymbol) 0xff69 (Cancel) 137 0xffc9 (F12)0xffc9 (F12)0xffc9 (F12)0xffc9 (F12) 0xff66 (Redo) 0x (NoSymbol) 0xff66 (Redo) 138 0xffca (F13)0xffca (F13)0xffca (F13)0xffca (F13) 0x1005ff70 (SunProps) 0x (NoSymbol) 0x1005ff70 (SunProps) 139 0xffcb (F14)0xffcb (F14)0xffcb (F14)0xffcb (F14) 0xff65 (Undo) 0x (NoSymbol) 0xff65 (Undo) 140 0xffcc (F15)0xffcc (F15)0xffcc (F15)0xffcc (F15) 0x1005ff71 (SunFront) 0x (NoSymbol) 0x1005ff71 (SunFront) 141 0xffcd (F16)0xffcd (F16)0xffcd (F16)0xffcd (F16) 0x1005ff72 (SunCopy)0x (NoSymbol) 0x1005ff72 (SunCopy) 142 0xffce (F17)0xffce (F17)0xffce (F17)0xffce (F17) 0x1005ff73 (SunOpen)0x (NoSymbol) 0x1005ff73 (SunOpen) 143 0xffcf (F18)0xffcf (F18)0xffcf (F18)0xffcf (F18) 0x1005ff74 (SunPaste) 0x (NoSymbol) 0x1005ff74 (SunPaste) 144 0xffd0 (F19)0xffd0 (F19)0xffd0 (F19)0xffd0 (F19) 0xff68 (Find) 0x (NoSymbol) 0xff68 (Find) 145 0xffd1 (F20)0xffd1 (F20)0xffd1 (F20)0xffd1 (F20) 0x1005ff75 (SunCut) 0x (NoSymbol) 0x1005ff75 (SunCut) 146 0xff6a (Help) 0x (NoSymbol) 0xff6a (Help) i.e. the keysyms mapped to keycodes 141, 142, 143, and 145 have all changed, and unpteen things which were working fine this morning are suddenly broken (in addition to gedit, which I can fix, my Opera Browser is affected' libreoffice and firefox seem to have survived, but every application whatsoever, when you press keycode 145, produces an ugly popup concerning my "rear microphone" - which does not even exist). What is going on? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xkeyboard-config in Ubuntu. https://bugs.launchpad.net/bugs/1831264 Title: Sun keyboard Front key not accepted by gnome-control-center Status in xkeyboard-config: New Status in xkeyboard-config package in Ubuntu: Triaged Bug description: A Sun keyboards is recognized by the hardware detector with no problem. xmodmap -pk gives the following for the relevant keys: 136 0xff69 (Cancel) 0x (NoSymbol) 0xff69 (Cancel) 137 0xff66 (Redo) 0x (NoSymbol) 0xff66 (Redo) 138 0x1005ff70 (SunProps) 0x (NoSymbol) 0x1005ff70 (SunProps) 139 0xff65 (Undo) 0x (NoSymbol) 0xff65 (Undo) 140 0x1005ff71 (SunFront) 0x (NoSymbol) 0x1005ff71 (SunFront) 141 0x1008ff57 (XF86Copy) 0x (NoSymbol) 0x1008ff57 (XF86Copy) 142 0x1008ff6b (XF86Open) 0x (NoSymbol) 0x1008ff6b (XF86Open) 143 0x1008ff6d (XF86Paste) 0x (NoSymbol) 0x1008ff6d (XF86Paste) 144 0xff68 (Find) 0x (NoSymbol) 0xff68 (Find) 145 0x1008ff58 (XF86Cut)0x (NoSymbol) 0x1008ff58 (XF86Cut) 146 0xff6a (Help) 0x (NoSymbol) 0xff6a (Help) Observe that the names of the two keysyms 0x1005ff70 and 0x1005ff71 are SUN specials, not in the XF86 set. Pressing either of these using xev behaves as expected: KeyPress event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071686, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071688, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I tried binding "Lower window below other windows" to the SunFront using the Settings app, but it did not work.(Note that back in the days of 14.04 where you uses CCSM to make this setting, it worked fine.) After this I did $ dconf dump /org/gnome/desktop/wm/keybindings/ [/] lower=['0x1005ff71'] switch-to-workspace-1=['1'] move-to-workspace-1=@as [] switch-to-workspace-2=['2'] switch-to-workspace-3=['3'] switch-to-workspace-4=['4'] move-to-monitor-down=@as [] move-to-monitor-up=@as [] So it had recognized the
[Desktop-packages] [Bug 1831264] Re: Sun keyboard Front key not accepted by gnome-control-center
See also https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard- config/issues/172 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xkeyboard-config in Ubuntu. https://bugs.launchpad.net/bugs/1831264 Title: Sun keyboard Front key not accepted by gnome-control-center Status in xkeyboard-config package in Ubuntu: New Bug description: A Sun keyboards is recognized by the hardware detector with no problem. xmodmap -pk gives the following for the relevant keys: 136 0xff69 (Cancel) 0x (NoSymbol) 0xff69 (Cancel) 137 0xff66 (Redo) 0x (NoSymbol) 0xff66 (Redo) 138 0x1005ff70 (SunProps) 0x (NoSymbol) 0x1005ff70 (SunProps) 139 0xff65 (Undo) 0x (NoSymbol) 0xff65 (Undo) 140 0x1005ff71 (SunFront) 0x (NoSymbol) 0x1005ff71 (SunFront) 141 0x1008ff57 (XF86Copy) 0x (NoSymbol) 0x1008ff57 (XF86Copy) 142 0x1008ff6b (XF86Open) 0x (NoSymbol) 0x1008ff6b (XF86Open) 143 0x1008ff6d (XF86Paste) 0x (NoSymbol) 0x1008ff6d (XF86Paste) 144 0xff68 (Find) 0x (NoSymbol) 0xff68 (Find) 145 0x1008ff58 (XF86Cut)0x (NoSymbol) 0x1008ff58 (XF86Cut) 146 0xff6a (Help) 0x (NoSymbol) 0xff6a (Help) Observe that the names of the two keysyms 0x1005ff70 and 0x1005ff71 are SUN specials, not in the XF86 set. Pressing either of these using xev behaves as expected: KeyPress event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071686, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071688, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I tried binding "Lower window below other windows" to the SunFront using the Settings app, but it did not work.(Note that back in the days of 14.04 where you uses CCSM to make this setting, it worked fine.) After this I did $ dconf dump /org/gnome/desktop/wm/keybindings/ [/] lower=['0x1005ff71'] switch-to-workspace-1=['1'] move-to-workspace-1=@as [] switch-to-workspace-2=['2'] switch-to-workspace-3=['3'] switch-to-workspace-4=['4'] move-to-monitor-down=@as [] move-to-monitor-up=@as [] So it had recognized the correct keysym, but does not know that the name of that keysym is SunFront. So far so bad. It works fine with keysyms with known names (e.g. the CANCEL key), and it should not be hard to construct a workaround my modifying the keyboard tables to map that key to some better-named keysym, so it might be argued that this bug is of Low Priority. BUT there is a serious side effect. With that dconf setting in place: the Left Arrow key on the keyboard no longer works (for example, I made that change whilst composing this report, and I cannot now move the cursor backwards with the Left Arrow key, though fortunately the Left Arrow on the numeric keypad still behaves). All applications seem to be affected (e.g. Firefox, Terminal, Gedit). Left and Left still work, except that if you engage Num Lock, Left now stops working. Using xev to see what happens when Left Arrow is pressed yields: FocusOut event, serial 37, synthetic NO, window 0x361, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 37, synthetic NO, window 0x361, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 37, synthetic NO, window 0x361, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 37, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 which is crazy! You should not be surprised that I spent a whole day gradually removing all the changes I had made until finally I narrowed it down to dconf, and then to that particular setting. Changing the binding back to CANCEL removes the problem (except that you have to restart each application affected, so I have just restarted Terminal, but I cannot restart Firefox while I am still typing this report). My main worry is that there may be some other keybinding errors that cause the same side effect, and therefor the Priority of fixing this bug needs to be much higher. Moreover, this problem seems to have been around for a long time. see:
[Desktop-packages] [Bug 1831264] Re: Sun keyboard Front key not accepted by gnome-control-center
On 03/06/2019 16:05, Gunnar Hjalmarsson wrote: > Thanks for your report! > > The issues you describe are upstream in nature, and it would be great if > you could file an upstream issue as well: See https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard- config/issues/172 > > https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues > > If you do, please post the URL to it here for tracking purposes. > -- Charles H. Lindsey -At my New Home, still doing my own thing-- Tel: +44 161 488 1845Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail-mail: Apt 40, SK8 5BF, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ** Bug watch added: gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues #172 https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/172 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xkeyboard-config in Ubuntu. https://bugs.launchpad.net/bugs/1831264 Title: Sun keyboard Front key not accepted by gnome-control-center Status in xkeyboard-config package in Ubuntu: New Bug description: A Sun keyboards is recognized by the hardware detector with no problem. xmodmap -pk gives the following for the relevant keys: 136 0xff69 (Cancel) 0x (NoSymbol) 0xff69 (Cancel) 137 0xff66 (Redo) 0x (NoSymbol) 0xff66 (Redo) 138 0x1005ff70 (SunProps) 0x (NoSymbol) 0x1005ff70 (SunProps) 139 0xff65 (Undo) 0x (NoSymbol) 0xff65 (Undo) 140 0x1005ff71 (SunFront) 0x (NoSymbol) 0x1005ff71 (SunFront) 141 0x1008ff57 (XF86Copy) 0x (NoSymbol) 0x1008ff57 (XF86Copy) 142 0x1008ff6b (XF86Open) 0x (NoSymbol) 0x1008ff6b (XF86Open) 143 0x1008ff6d (XF86Paste) 0x (NoSymbol) 0x1008ff6d (XF86Paste) 144 0xff68 (Find) 0x (NoSymbol) 0xff68 (Find) 145 0x1008ff58 (XF86Cut)0x (NoSymbol) 0x1008ff58 (XF86Cut) 146 0xff6a (Help) 0x (NoSymbol) 0xff6a (Help) Observe that the names of the two keysyms 0x1005ff70 and 0x1005ff71 are SUN specials, not in the XF86 set. Pressing either of these using xev behaves as expected: KeyPress event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071686, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071688, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I tried binding "Lower window below other windows" to the SunFront using the Settings app, but it did not work.(Note that back in the days of 14.04 where you uses CCSM to make this setting, it worked fine.) After this I did $ dconf dump /org/gnome/desktop/wm/keybindings/ [/] lower=['0x1005ff71'] switch-to-workspace-1=['1'] move-to-workspace-1=@as [] switch-to-workspace-2=['2'] switch-to-workspace-3=['3'] switch-to-workspace-4=['4'] move-to-monitor-down=@as [] move-to-monitor-up=@as [] So it had recognized the correct keysym, but does not know that the name of that keysym is SunFront. So far so bad. It works fine with keysyms with known names (e.g. the CANCEL key), and it should not be hard to construct a workaround my modifying the keyboard tables to map that key to some better-named keysym, so it might be argued that this bug is of Low Priority. BUT there is a serious side effect. With that dconf setting in place: the Left Arrow key on the keyboard no longer works (for example, I made that change whilst composing this report, and I cannot now move the cursor backwards with the Left Arrow key, though fortunately the Left Arrow on the numeric keypad still behaves). All applications seem to be affected (e.g. Firefox, Terminal, Gedit). Left and Left still work, except that if you engage Num Lock, Left now stops working. Using xev to see what happens when Left Arrow is pressed yields: FocusOut event, serial 37, synthetic NO, window 0x361, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 37, synthetic NO, window 0x361, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 37, synthetic NO, window 0x361, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 37, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[Desktop-packages] [Bug 1831264] [NEW] Sun keyboard Front key not accepted by gnome-control-center
Public bug reported: A Sun keyboards is recognized by the hardware detector with no problem. xmodmap -pk gives the following for the relevant keys: 136 0xff69 (Cancel) 0x (NoSymbol) 0xff69 (Cancel) 137 0xff66 (Redo) 0x (NoSymbol) 0xff66 (Redo) 138 0x1005ff70 (SunProps) 0x (NoSymbol) 0x1005ff70 (SunProps) 139 0xff65 (Undo) 0x (NoSymbol) 0xff65 (Undo) 140 0x1005ff71 (SunFront) 0x (NoSymbol) 0x1005ff71 (SunFront) 141 0x1008ff57 (XF86Copy) 0x (NoSymbol) 0x1008ff57 (XF86Copy) 142 0x1008ff6b (XF86Open) 0x (NoSymbol) 0x1008ff6b (XF86Open) 143 0x1008ff6d (XF86Paste) 0x (NoSymbol) 0x1008ff6d (XF86Paste) 144 0xff68 (Find) 0x (NoSymbol) 0xff68 (Find) 145 0x1008ff58 (XF86Cut)0x (NoSymbol) 0x1008ff58 (XF86Cut) 146 0xff6a (Help) 0x (NoSymbol) 0xff6a (Help) Observe that the names of the two keysyms 0x1005ff70 and 0x1005ff71 are SUN specials, not in the XF86 set. Pressing either of these using xev behaves as expected: KeyPress event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071686, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 37, synthetic NO, window 0x361, root 0x4fe, subw 0x0, time 3071688, (118,83), root:(1365,168), state 0x0, keycode 140 (keysym 0x1005ff71, SunFront), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I tried binding "Lower window below other windows" to the SunFront using the Settings app, but it did not work.(Note that back in the days of 14.04 where you uses CCSM to make this setting, it worked fine.) After this I did $ dconf dump /org/gnome/desktop/wm/keybindings/ [/] lower=['0x1005ff71'] switch-to-workspace-1=['1'] move-to-workspace-1=@as [] switch-to-workspace-2=['2'] switch-to-workspace-3=['3'] switch-to-workspace-4=['4'] move-to-monitor-down=@as [] move-to-monitor-up=@as [] So it had recognized the correct keysym, but does not know that the name of that keysym is SunFront. So far so bad. It works fine with keysyms with known names (e.g. the CANCEL key), and it should not be hard to construct a workaround my modifying the keyboard tables to map that key to some better-named keysym, so it might be argued that this bug is of Low Priority. BUT there is a serious side effect. With that dconf setting in place: the Left Arrow key on the keyboard no longer works (for example, I made that change whilst composing this report, and I cannot now move the cursor backwards with the Left Arrow key, though fortunately the Left Arrow on the numeric keypad still behaves). All applications seem to be affected (e.g. Firefox, Terminal, Gedit). Left and Left still work, except that if you engage Num Lock, Left now stops working. Using xev to see what happens when Left Arrow is pressed yields: FocusOut event, serial 37, synthetic NO, window 0x361, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 37, synthetic NO, window 0x361, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 37, synthetic NO, window 0x361, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 37, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 which is crazy! You should not be surprised that I spent a whole day gradually removing all the changes I had made until finally I narrowed it down to dconf, and then to that particular setting. Changing the binding back to CANCEL removes the problem (except that you have to restart each application affected, so I have just restarted Terminal, but I cannot restart Firefox while I am still typing this report). My main worry is that there may be some other keybinding errors that cause the same side effect, and therefor the Priority of fixing this bug needs to be much higher. Moreover, this problem seems to have been around for a long time. see: https://unix.stackexchange.com/questions/231307/key-for-the-letter-o-stopped-working-works-only-with-shift-linux which produces exactly the same xev output with a completely different binding problem. To reproduce the Bug, ideally just find a Sun Keyboard and plug it into a spare USB port, and then follow what I have described. If you cannot lay your hands on a Sun Keyboard, then it is likely that $ dconf load /org/gnome/desktop/wm/keybindings/ lower=['0x1005ff71'] will produce the same effect. In case the bug reporting system has not supplied my full details, here is $ uname -a Linux clerew
[Desktop-packages] [Bug 1556295] Re: setxkbmap -I /usr/local/share/X11/xkb broken
I am not quite sure what rules.evdev.lst does, but it certainly gets read by setxkbmap. So to reproduce the bug you may need $ diff /usr/share/X11/xkb/rules/evdev.lst /usr/local/share/X11/xkb/rules/evdev.lst 659a660 > mod3gb: Mod3 modifier which I omitted to mention in my report above. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to x11-xkb-utils in Ubuntu. https://bugs.launchpad.net/bugs/1556295 Title: setxkbmap -I /usr/local/share/X11/xkb broken Status in x11-xkb-utils package in Ubuntu: New Bug description: x11-xkb-utils 7.7+1 (as supplied with Ubuntu 14.04 - Trusty) setxkbmap -I /usr/local/share/X11/xkb should search first in /usr/local/share/X11/xkb, and if not found then search in /usr/share/X11/xkb Instead, it appears to search first in the current directory, and then in /usr/share/X11/xkb To reproduce, set up some file in /usr/local/share/X11/xkb/rules. For example, I created a modified version of evdev with $ diff /usr/share/X11/xkb/rules/evdev /usr/local/share/X11/xkb/rules/evdev 247c247,248 < * $sun_custom $sun_var= pc+sun_vndr/%l%(v) --- > ! *$sun_custom $sun_var= pc+sun_vndr/%l%(v) > $sun gb mod3= pc+gb(mod3) 332c333,334 < $sun $sun_custom = pc+sun_vndr/%l%(v) --- > ! $sun $sun_custom = pc+sun_vndr/%l%(v) > $sun gb pc+gb%(v) Then $ cd /usr/local/share/X11/xkb/ $ setxkbmap -query -v 10 -model sun_type6_unix_usb -layout gb -variant mod3 Setting verbose level to 10 locale is C Warning! Multiple definitions of keyboard model Using command line, ignoring X server Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Warning! Multiple definitions of layout variant Using command line, ignoring X server Trying to load rules file ./rules/evdev... Success. Applied rules from evdev: rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols:pc+gb(mod3)+inet(evdev) geometry: sun(type6unix) rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Observe the "symbols:pc+gb(mod3)+inet(evdev)" which is exactly what I wanted (clearly I had also to set up a suitably hacked symbols/gb file) Now try the following from the home directory, which ought to have produced the same result: $ cd $ setxkbmap -I /usr/local/share/X11/xkb -query -v 10 -model sun_type6_unix_usb -layout gb -variant mod3 Setting verbose level to 10 locale is C Warning! Multiple definitions of keyboard model Using command line, ignoring X server Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Warning! Multiple definitions of layout variant Using command line, ignoring X server Trying to load rules file ./rules/evdev... Trying to load rules file /usr/share/X11/xkb/rules/evdev... Success. Applied rules from evdev: rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols:pc+sun_vndr/gb(mod3)+inet(evdev) geometry: sun(type6unix) rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Evidently it was 'Trying to load rules file /usr/share/X11/xkb/rules/evdev...', but clearly it was still using the rules/evdev from /usr/share/X11/xkb (all of which can be confirmed by running both attempts with 'strace -e trace=open ...) Note that there is some disagreement between the manpage and the -help as to whether there should be a space after the '-I'. The bug arises with and without that space. So this is a subsidiary bug in the -help, which ought to be fixed. Note also that it thinks that it is in the 'C' locale, whereas I actually use 'en_GB.UTF-8'. This is another subsidiary bug; I have verified using gdb that there is no relevant call of 'getenv'. Note also that is -I of xkbcomp appears to work correctly. Share and Enjoy! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/x11-xkb-utils/+bug/1556295/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1556295] [NEW] setxkbmap -I /usr/local/share/X11/xkb broken
Public bug reported: x11-xkb-utils 7.7+1 (as supplied with Ubuntu 14.04 - Trusty) setxkbmap -I /usr/local/share/X11/xkb should search first in /usr/local/share/X11/xkb, and if not found then search in /usr/share/X11/xkb Instead, it appears to search first in the current directory, and then in /usr/share/X11/xkb To reproduce, set up some file in /usr/local/share/X11/xkb/rules. For example, I created a modified version of evdev with $ diff /usr/share/X11/xkb/rules/evdev /usr/local/share/X11/xkb/rules/evdev 247c247,248 < * $sun_custom $sun_var= pc+sun_vndr/%l%(v) --- > ! * $sun_custom $sun_var= > pc+sun_vndr/%l%(v) > $sungb mod3= pc+gb(mod3) 332c333,334 < $sun $sun_custom = pc+sun_vndr/%l%(v) --- > ! $sun $sun_custom = pc+sun_vndr/%l%(v) > $sungb pc+gb%(v) Then $ cd /usr/local/share/X11/xkb/ $ setxkbmap -query -v 10 -model sun_type6_unix_usb -layout gb -variant mod3 Setting verbose level to 10 locale is C Warning! Multiple definitions of keyboard model Using command line, ignoring X server Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Warning! Multiple definitions of layout variant Using command line, ignoring X server Trying to load rules file ./rules/evdev... Success. Applied rules from evdev: rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols:pc+gb(mod3)+inet(evdev) geometry: sun(type6unix) rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Observe the "symbols:pc+gb(mod3)+inet(evdev)" which is exactly what I wanted (clearly I had also to set up a suitably hacked symbols/gb file) Now try the following from the home directory, which ought to have produced the same result: $ cd $ setxkbmap -I /usr/local/share/X11/xkb -query -v 10 -model sun_type6_unix_usb -layout gb -variant mod3 Setting verbose level to 10 locale is C Warning! Multiple definitions of keyboard model Using command line, ignoring X server Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Warning! Multiple definitions of layout variant Using command line, ignoring X server Trying to load rules file ./rules/evdev... Trying to load rules file /usr/share/X11/xkb/rules/evdev... Success. Applied rules from evdev: rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Trying to build keymap using the following components: keycodes: evdev+aliases(qwerty) types: complete compat: complete symbols:pc+sun_vndr/gb(mod3)+inet(evdev) geometry: sun(type6unix) rules: evdev model: sun_type6_unix_usb layout: gb variant:mod3 Evidently it was 'Trying to load rules file /usr/share/X11/xkb/rules/evdev...', but clearly it was still using the rules/evdev from /usr/share/X11/xkb (all of which can be confirmed by running both attempts with 'strace -e trace=open ...) Note that there is some disagreement between the manpage and the -help as to whether there should be a space after the '-I'. The bug arises with and without that space. So this is a subsidiary bug in the -help, which ought to be fixed. Note also that it thinks that it is in the 'C' locale, whereas I actually use 'en_GB.UTF-8'. This is another subsidiary bug; I have verified using gdb that there is no relevant call of 'getenv'. Note also that is -I of xkbcomp appears to work correctly. Share and Enjoy! ** Affects: x11-xkb-utils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to x11-xkb-utils in Ubuntu. https://bugs.launchpad.net/bugs/1556295 Title: setxkbmap -I /usr/local/share/X11/xkb broken Status in x11-xkb-utils package in Ubuntu: New Bug description: x11-xkb-utils 7.7+1 (as supplied with Ubuntu 14.04 - Trusty) setxkbmap -I /usr/local/share/X11/xkb should search first in /usr/local/share/X11/xkb, and if not found then search in /usr/share/X11/xkb Instead, it appears to search first in the current directory, and then in /usr/share/X11/xkb To reproduce, set up some file in /usr/local/share/X11/xkb/rules. For example, I created a modified version of evdev with $ diff /usr/share/X11/xkb/rules/evdev /usr/local/share/X11/xkb/rules/evdev 247c247,248 < * $sun_custom $sun_var= pc+sun_vndr/%l%(v) --- > ! *$sun_custom $sun_var= pc+sun_vndr/%l%(v) > $sun gb mod3= pc+gb(mod3) 332c333,334 < $sun $sun_custom =
