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) 0x0000 (NoSymbol) 0xff69 (Cancel)
137 0xff66 (Redo) 0x0000 (NoSymbol) 0xff66 (Redo)
138 0x1005ff70 (SunProps) 0x0000 (NoSymbol) 0x1005ff70
(SunProps)
139 0xff65 (Undo) 0x0000 (NoSymbol) 0xff65 (Undo)
140 0x1005ff71 (SunFront) 0x0000 (NoSymbol) 0x1005ff71
(SunFront)
141 0x1008ff57 (XF86Copy) 0x0000 (NoSymbol) 0x1008ff57
(XF86Copy)
142 0x1008ff6b (XF86Open) 0x0000 (NoSymbol) 0x1008ff6b
(XF86Open)
143 0x1008ff6d (XF86Paste) 0x0000 (NoSymbol) 0x1008ff6d
(XF86Paste)
144 0xff68 (Find) 0x0000 (NoSymbol) 0xff68 (Find)
145 0x1008ff58 (XF86Cut) 0x0000 (NoSymbol) 0x1008ff58
(XF86Cut)
146 0xff6a (Help) 0x0000 (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 0x3600001,
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 0x3600001,
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=['<Alt>1']
move-to-workspace-1=@as []
switch-to-workspace-2=['<Alt>2']
switch-to-workspace-3=['<Alt>3']
switch-to-workspace-4=['<Alt>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). <ctrl>Left and <Shift>Left still work,
except that if you engage Num Lock, <Shift>Left now stops working.
Using xev to see what happens when Left Arrow is pressed yields:
FocusOut event, serial 37, synthetic NO, window 0x3600001,
mode NotifyGrab, detail NotifyAncestor
FocusOut event, serial 37, synthetic NO, window 0x3600001,
mode NotifyUngrab, detail NotifyPointer
FocusIn event, serial 37, synthetic NO, window 0x3600001,
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 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gnome-control-center 1:3.28.2-0ubuntu0.18.04.1
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri May 31 15:17:21 2019
ExecutablePath: /usr/bin/gnome-control-center
ProcEnviron:
LANGUAGE=en_GB
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: gnome-control-center
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: gnome-control-center (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 bionic gnome-control-center
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1831264
Title:
Sun keyboard Front key not accepted by gnome-control-center
Status in gnome-control-center 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) 0x0000 (NoSymbol) 0xff69 (Cancel)
137 0xff66 (Redo) 0x0000 (NoSymbol) 0xff66 (Redo)
138 0x1005ff70 (SunProps) 0x0000 (NoSymbol) 0x1005ff70
(SunProps)
139 0xff65 (Undo) 0x0000 (NoSymbol) 0xff65 (Undo)
140 0x1005ff71 (SunFront) 0x0000 (NoSymbol) 0x1005ff71
(SunFront)
141 0x1008ff57 (XF86Copy) 0x0000 (NoSymbol) 0x1008ff57
(XF86Copy)
142 0x1008ff6b (XF86Open) 0x0000 (NoSymbol) 0x1008ff6b
(XF86Open)
143 0x1008ff6d (XF86Paste) 0x0000 (NoSymbol) 0x1008ff6d
(XF86Paste)
144 0xff68 (Find) 0x0000 (NoSymbol) 0xff68 (Find)
145 0x1008ff58 (XF86Cut) 0x0000 (NoSymbol) 0x1008ff58
(XF86Cut)
146 0xff6a (Help) 0x0000 (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 0x3600001,
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 0x3600001,
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=['<Alt>1']
move-to-workspace-1=@as []
switch-to-workspace-2=['<Alt>2']
switch-to-workspace-3=['<Alt>3']
switch-to-workspace-4=['<Alt>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). <ctrl>Left and
<Shift>Left still work, except that if you engage Num Lock,
<Shift>Left now stops working.
Using xev to see what happens when Left Arrow is pressed yields:
FocusOut event, serial 37, synthetic NO, window 0x3600001,
mode NotifyGrab, detail NotifyAncestor
FocusOut event, serial 37, synthetic NO, window 0x3600001,
mode NotifyUngrab, detail NotifyPointer
FocusIn event, serial 37, synthetic NO, window 0x3600001,
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 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gnome-control-center 1:3.28.2-0ubuntu0.18.04.1
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri May 31 15:17:21 2019
ExecutablePath: /usr/bin/gnome-control-center
ProcEnviron:
LANGUAGE=en_GB
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: gnome-control-center
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1831264/+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
