eltariel
commented
3 years ago Every keycode you see has been through at least one level of translation. in X, keycodes are an abstraction based on the fact that it's a network protocol, and you can't assume anything about the system it runs on. In a linux VT, everything you see has already been processed by the kernel to get a scancode, as it works with a lot of different types of hardware and not all of it reports a key event in the same way, so it's all translated to a common representation.
We're not working in that space. We're pretending to be a keyboard using the USB HID standard. Keys are represented by HID Usage Pages and HID Usage Codes in a HID Report. The confusing part about this is that although the standard refers to Page 0x07, Usage 0x04 as 'A', it's explicitly referring to the position on the keyboard where the A key lives on a US keyboard. This means that the 'A' key on an AZERTY keyboard will not be the same code, it will in fact be 0x07:0x14, which is labelled 'Q' on a US keyboard. The intention of this is to allow a single keyboard to work with many layouts just by swapping keycaps etc, no firmware changes are necessary in the device.
Supporting alternate languages at the key level requires mapping the HID keynames to a language-specific internal keyname. Supporting it at the string level means doing exactly what I was doing for english upper/lowercase strings, but extended to cover the entire character set: a mapping from a character to the sequence of key events required to produce that character for a given language, applied to a string one character at a time. This is where most of the effort for the per-language key maps comes in - pick a keyboard, and for each key on it list what it produces for a given combination of modifiers. Also note that pressing caps lock never changes the code a key sends.
Olfried2
Definition of the task Keyboards differ from type and language. For example there are cable connected, radio connected, USB connected keyboards And there are desktop keyboards (105 keys) and laptop keyboards and so on. (A list will be shown when you set up a new Linux-system) . The regular chars A,a,B,b ... are fairly easy to handle. the bytes send to the receiver(computer) are [Key-pressed], [which char], [key released] this is aleady implemented in the code It starts to get difficult when you want more than the normal letters like [ALT-something] or [CTRL-something] and unfortunately gets more difficult when you want [ALT-GR-Q] to print the "@". Even if you press ENTER on the num-block the code is "0xe0 0x1c 0xe0 0x9c " the regular ENTER is "0x1c 0x9c"
These topics need more investigation
As resources I found the following pages helpful and/or informative
https://en.wikipedia.org/wiki/Keyboard_layout also see the German page https://de.wikipedia.org/wiki/Tastaturbelegung _https://kodi.wiki/view/Archive:Keyboard_Internationalisation ARCHIVED_ https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes http://xahlee.info/linux/linux_keybinding_index.html Some informationes maybe outdated here https://www.win.tue.nl/~aeb/linux/kbd/scancodes.html
Pitfall when checking scancodes If you're on a linux desktop running GUI like X, you get different scancodes you have to change to a virtual console (e.g. CTRL-ALT-F6) and run
Note: under x you can get informations using xev (typed in terminal) not further examined, or proofed
If you could build me a small testprogram with the HID and USB parts of njak I could examine which codes are reliable, using some of my spare keyboards in english and on my different laptops in german. It should be able send up to six hex-values like "0x38 0xe0 0x38" (hope this are real keys not only pressed, released) Just a variable in the sourcecode, where I can copy my results in. Nothing fancy.
My next goal is to install and manage git to be able to send you "real code".
Never thought that I opened "pandora's box" when buying the USeless taBle lightshow