[SOLVED] startx - Unsopported high keycode

tigerjack · 2018-10-08 09:05:41

As per the title, I receive a strange message from startx saying

Warning: Unsupported high keycode 372 for name <I372> ignored
X11 cannot support keycodes above 255.
This warning only shows for the first high keycode.

Despite the last string, the message is repeated other two times, which I discovered is due to the execution of setxkbmap commands in my .xinitrc.

Everything works fine, but I'm still asking the reason of those messages.

I don't use a desktop manager, only i3 as window manager, and my .xinitrc looks like this

# Go to home
cd ~
# Execute global scripts
for file in /etc/X11/xinit/xinitrc.d/?*.sh; do
if [ -x "$file" ]; then
name=$(basename -s .sh $file)
logfile="$MDIR_LOGS/startx/etc_$name.log$DISPLAY"
($file >"$logfile" 2>&1 & )
fi
done
unset file
## Load X resources, never background them
[ -f ~/.Xdefaults ] && xrdb -merge ~/.Xdefaults > "$MDIR_LOGS/startx/xrdb_defaults.log$DISPLAY" 2>&1
[ -f ~/.Xresources ] && xrdb -merge ~/.Xresources > "$MDIR_LOGS/startx/xrdb_resources.log$DISPLAY" 2>&1
# Source my files with environment variables used by all applications...
# [ -f ~/.global_env ] && . ~/.global_env > "$MDIR_LOGS/startx/global_env.log$DISPLAY" 2>&1
# actually they are sourced via bashrc
# ... and GUI applications
[ -f ~/.xmyenv ] && . ~/.xmyenv > "$MDIR_LOGS/startx/xmyenv.log$DISPLAY" 2>&1
# To avoid terminal bell
xset -b
# Start the OpenSSH agent, evaluating the environment variables
eval $(ssh-agent -s &) >"$MDIR_LOGS/startx/ssh_agent.log$DISPLAY" 2>&1
# Gnome key ring, with ssh agent disabled bcz using ssh-agent
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets) >"$MDIR_LOGS/startx/gnome_keyring.log$DISPLAY" 2>&1
#eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
#export SSH_AUTH_SOCK
# Change the screen settings
#xrandr --output "Screen 0" --brightness 0.5 --gamma 1:1:0.5
xrandr --output $(xrandr | grep -E " connected (primary )?[1-9]+" | sed -e "s/$[A-Z0-9]\+$ connected.*/\1/") --brightness 0.5 --gamma 1:1:0.5 > "$MDIR_LOGS/startx/xrandr.log$DISPLAY" 2>&1
# Activate bloc num
numlockx &
# Set us layout for keyboard
setxkbmap -layout us > "$MDIR_LOGS/startx/setxkbmap.log$DISPLAY" 2>&1
# To remap keys, see http://www.economyofeffort.com/2014/08/ … ey-useful/
setxkbmap -option 'caps:ctrl_modifier' >> "$MDIR_LOGS/startx/setxkbmap.log$DISPLAY" 2>&1
xcape -e 'Caps_Lock=Escape;Control_L=Escape;Control_R=Escape' > "$MDIR_LOGS/startx/xcape.log$DISPLAY" 2>&1
# Alternative method to swap CapsLock and Ctrl key
# xmodmap ~/.config/xmodmap/speedswapper
# Repeat delay (100-1000) and repeat interval (10-200) of keyboard
xset r rate 250 60
# Disable slow-keys
xkbset -sl
# Disable accessibility so slow-keys won't turn back on
xkbset -a
exec i3

The various variables are predefined and only used for logging purposes.

To start the X session, I simply invoke startx.

Any idea?

Last edited by tigerjack (2018-10-23 14:17:47)

seth · 2018-10-08 12:07:50

I372 is in the inet table (/usr/share/X11/xkb/symbols/inet)

pacman -Qkk xkeyboard-config

Also record the "setxkbmap -print -query" output before (and after) messing around w/ it in the xinitrc.

Ftr, you can set layout and options in one step.
Also the caps:ctrl_modifier seems to overlay w/ the xcape juggling??
Are you aware of the caps:escape and caps:swapescape options?

tigerjack · 2018-10-08 13:42:01

seth wrote:

I372 is in the inet table (/usr/share/X11/xkb/symbols/inet)
pacman -Qkk xkeyboard-config

Hi seth, thanks for your help. From the "inet" file I read

key <I372> { [ XF86Favorites ] };

which is definitely not a key I have on my keyboard.

seth wrote:

Also record the "setxkbmap -print -query" output before (and after) messing around w/ it in the xinitrc.

I should've mentioned that even commenting out all the lines related to "setxkbmap", there is still a warning message before everything else. More precisely, when the two "setxkbmap" commands are active I get three identical messages in the log, while commenting them out leaves just one message.
Also, this single message seems to be raised even before the ".xinitrc" file is being processed. What I mean is that even a simple "echo" message as the first string of the ".xinitrc" file is still being logged only after the warning message from "setxkbmap".

Btw, this is the output logged by the query before and after "setxkbmap"

xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
rules: evdev
model: pc105
layout: us

xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)+capslock(ctrl_modifier)" };
xkb_geometry { include "pc(pc105)" };
};
rules: evdev
model: pc105
layout: us
options: caps:ctrl_modifier

seth wrote:

Ftr, you can set layout and options in one step.

Yes, I'm aware of that, but I prefer to have them separated to simplify the debugging process in case of errors. I mean, the layout is fixed, while the "setxkbmap" and "xcape" options are there just to have a specific behavior on "Caps Lock" (in short, "Caps Lock" maps to "Esc" on short press, to "Ctrl" on long press).

seth wrote:

Also the caps:ctrl_modifier seems to overlay w/ the xcape juggling??
Are you aware of the caps:escape and caps:swapescape options?

Here I'm not following you anymore. What are those options? Also, what do you mean by xcape juggling?

seth · 2018-10-08 14:01:48

You're first setting caps to ctrl, then (through xcape) caps to escape and ctrl to escape (but I'm not sure whether that call only affects them as single keys and preserves the modifier)
The options are for setxkbmap and map caps to escape (and vv. in one case)

On topic: the keyboard is initially configured to the us+inet layout (so you layout modification should be idempotent) - you likely have some keyboard config in {/etc,/usr/share}/X11/xorg.conf* ?
Are you using evdev or libinput as keyboard driver (xorg log)?
Did you check the integrity of the xkeyboard-config package?

tigerjack · 2018-10-08 14:20:44

There's no file in /etc/X11/xorg.conf.d/, while

> cat /usr/share/X11/xorg.conf.d/*
Section "OutputClass"
	Identifier "AMDgpu"
	MatchDriver "amdgpu"
	Driver "amdgpu"
EndSection# Collection of quirks and blacklist/whitelists for specific devices.


# Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable
# http://bugs.freedesktop.org/show_bug.cgi?id=22442 
Section "InputClass"
        Identifier "ThinkPad HDAPS accelerometer blacklist"
        MatchProduct "ThinkPad HDAPS accelerometer data"
        Option "Ignore" "on"
EndSection

# https://bugzilla.redhat.com/show_bug.cgi?id=523914
# Mouse does not move in PV Xen guest
# Explicitly tell evdev to not ignore the absolute axes.
Section "InputClass"
        Identifier "Xen Virtual Pointer axis blacklist"
        MatchProduct "Xen Virtual Pointer"
        Option "IgnoreAbsoluteAxes" "off"
        Option "IgnoreRelativeAxes" "off"
EndSection

# https://bugs.freedesktop.org/show_bug.cgi?id=55867
# Bug 55867 - Doesn't know how to tag XI_TRACKBALL
Section "InputClass"
        Identifier "Tag trackballs as XI_TRACKBALL"
        MatchProduct "trackball"
        MatchDriver "evdev"
        Option "TypeName" "TRACKBALL"
EndSection

# https://bugs.freedesktop.org/show_bug.cgi?id=62831
# Bug 62831 - Mionix Naos 5000 mouse detected incorrectly
Section "InputClass"
        Identifier "Tag Mionix Naos 5000 mouse XI_MOUSE"
        MatchProduct "La-VIEW Technology Naos 5000 Mouse"
        MatchDriver "evdev"
        Option "TypeName" "MOUSE"
EndSection
Section "OutputClass"
	Identifier "Radeon"
	MatchDriver "radeon"
	Driver "radeon"
EndSection# Match on all types of devices but joysticks
Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput touchscreen catchall"
        MatchIsTouchscreen "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput tablet catchall"
        MatchIsTablet "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

It seems that nothing related to the layout is defined in those files.

Also, I think I'm using "libinput"

grep -e "Using input driver" /var/log/Xorg.0.log
[    34.634] (II) Using input driver 'libinput' for 'Power Button'
[    34.658] (II) Using input driver 'libinput' for 'Video Bus'
[    34.664] (II) Using input driver 'libinput' for 'Power Button'
[    34.671] (II) Using input driver 'libinput' for 'HP Webcam: HP Webcam'
[    34.677] (II) Using input driver 'libinput' for 'AT Translated Set 2 keyboard'
[    34.682] (II) Using input driver 'libinput' for 'SynPS/2 Synaptics TouchPad'
[    34.688] (II) Using input driver 'libinput' for 'HP WMI hotkeys'
[    34.692] (II) Using input driver 'libinput' for 'HP Wireless hotkeys'

Lastly,

>pacman -Qkk xkeyboard-config
xkeyboard-config: 452 total files, 0 altered files

tigerjack · 2018-10-08 16:15:33

seth wrote:

You're first setting caps to ctrl, then (through xcape) caps to escape and ctrl to escape (but I'm not sure whether that call only affects them as single keys and preserves the modifier)
The options are for setxkbmap and map caps to escape (and vv. in one case)

Btw, closing the off topic, it seems that the two options have a different behavior from the actual one. As said, I don't want a simple exchange between Caps and Esc keys; what I have now is an Esc key on a fast "tap" of Caps, while a Ctrl key on a normal press of Caps.
Indeed, I get the following message

> Error:            Key <CAPS> added to map for multiple modifiers
>                   Using Control, ignoring Lock.

but to be honest everything works just as expected.

EDIT: The previous error disappeared after removing Control_R=Escape from xcape command.

Last edited by tigerjack (2018-10-08 16:19:52)

seth · 2018-10-08 20:32:58

Google is our friend: https://bugzilla.redhat.com/show_bug.cgi?id=1615700

tigerjack · 2018-10-08 20:37:23

woops, I missed it. So it seems that there's nothing to worry. I'll leave the thread open for a few days just in case. Thanks again for your help.

Arch Linux

#1 2018-10-08 09:05:41

[SOLVED] startx - Unsopported high keycode

#2 2018-10-08 12:07:50

Re: [SOLVED] startx - Unsopported high keycode

#3 2018-10-08 13:42:01

Re: [SOLVED] startx - Unsopported high keycode

#4 2018-10-08 14:01:48

Re: [SOLVED] startx - Unsopported high keycode

#5 2018-10-08 14:20:44

Re: [SOLVED] startx - Unsopported high keycode

#6 2018-10-08 16:15:33

Re: [SOLVED] startx - Unsopported high keycode

#7 2018-10-08 20:32:58

Re: [SOLVED] startx - Unsopported high keycode

#8 2018-10-08 20:37:23

Re: [SOLVED] startx - Unsopported high keycode

Board footer