I've been working with a keyboard to remap certain keys and create macros etc.
I understand that the keyboard (via USB, I'm talking about a desktop computer with a USB HID keyboard) provides a scancode that is dependent on the keyboard's hardware, is mapped to keycodes based on the rules made up from various hwdb resources. Those keycodes are then interpreted by the operating system.
I find that evtest gives the best results directly from the keyboard since it contains the keyboards scancodes, keycodes and key symbols all in one neat little output. To make it cleaner I usually grep the output to be even tidier:
sudo evtest | grep -B1 "value 1" However, the codes as used by xmodmap and various applications are those as output (and if output) y xev. I don't have a nice grep for xev, I just filter by keyboard events:
xev -event keyboard This questions I have are
- Do keyboards exist where
MIN_KEYCODEis set to something other than8? - From the linked question, I see that
MIN_KEYCODEis hard coded on line 72 of https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c - Why is there a difference in the keycodes as produced by
xevvsevtest
I'm sure someone will suggest it is because the first 8 codes are reserved, but that should be irrelevant, shouldn't it? The keycode, reserved or not, should it not be output as a raw code than a value which is transposed (whether by arbitrary or fixed value) and can lead to errors?
I really am just trying to understand the difference as to why some programs output and why some system require input that are out by 8 and how to ratify that inconsistency in my mind.
evtestwill output keycode info even whenxevwill not. On numerous occasions,xevreports a line of 0,0,0,0,0 instead of anything useful, where asevtestreports keycodes, they're just out by 8 compared to whatxevwould have produced, if it produced anything