Ubuntu
xkeyboard-config package

Sun keyboard Front key not accepted by gnome-control-center

Bug #1831264 reported by Charles Lindsey on 2019-05-31

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	xkeyboard-config	New	Unknown	auto-gitlab.freedesktop.org-xkeyboard-config-xkeyboard-config #172
	xkeyboard-config (Ubuntu)	Triaged	Low	Unassigned

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)

Tags: