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) 0x0000 (NoSymbol) 0xff69 (Cancel)
137 0xffc9 (F12) 0xffc9 (F12) 0xffc9 (F12) 0xffc9 (F12)
0xff66 (Redo) 0x0000 (NoSymbol) 0xff66 (Redo)
138 0xffca (F13) 0xffca (F13) 0xffca (F13) 0xffca (F13)
0x1005ff70 (SunProps) 0x0000 (NoSymbol) 0x1005ff70 (SunProps)
139 0xffcb (F14) 0xffcb (F14) 0xffcb (F14) 0xffcb (F14)
0xff65 (Undo) 0x0000 (NoSymbol) 0xff65 (Undo)
140 0xffcc (F15) 0xffcc (F15) 0xffcc (F15) 0xffcc (F15)
0x1005ff71 (SunFront) 0x0000 (NoSymbol) 0x1005ff71 (SunFront)
141 0xffcd (F16) 0xffcd (F16) 0xffcd (F16) 0xffcd (F16)
0x1005ff72 (SunCopy) 0x0000 (NoSymbol) 0x1005ff72 (SunCopy)
142 0xffce (F17) 0xffce (F17) 0xffce (F17) 0xffce (F17)
0x1005ff73 (SunOpen) 0x0000 (NoSymbol) 0x1005ff73 (SunOpen)
143 0xffcf (F18) 0xffcf (F18) 0xffcf (F18) 0xffcf (F18)
0x1005ff74 (SunPaste) 0x0000 (NoSymbol) 0x1005ff74 (SunPaste)
144 0xffd0 (F19) 0xffd0 (F19) 0xffd0 (F19) 0xffd0 (F19)
0xff68 (Find) 0x0000 (NoSymbol) 0xff68 (Find)
145 0xffd1 (F20) 0xffd1 (F20) 0xffd1 (F20) 0xffd1 (F20)
0x1005ff75 (SunCut) 0x0000 (NoSymbol) 0x1005ff75 (SunCut)
146 0xff6a (Help) 0x0000 (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) 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/xkeyboard-config/+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
