tuxedo-keyboard

this one the hard way. Before I started, I emailed Clevo and asked for technical documentation on the keyboard. Their marketing department replied: "Ubuntu was not supported". I emailed Tuxedo Computers (mentioned above) and they were much more helpful: their developers shared a fan control application they wrote with me! It was great but the keyboard drivers were missing. So I decided to reverse engineer it. While not as complex as the VGA-to-USB device, the process of reverse engineering the keyboard was similar: 1. Boot Windows 10 with the proprietary driver 2. Start Wireshark 3. Capture USB traffic 4. Use the manufacturer's keyboard control program 5. Correlate the data sent to the keyboard with what I did 6. Document the structure of the messages For example, to set the color of a specific RGB LED on my keyboard, the following bytes must be sent to the device through a USB control transfer: 0xcc01kkrrggbb7f 01 = some kind of operation code kk = target LED rr = red gg = green bb = blue cc, 7f always surround all bytes (part of USB protocol?) I used hidapi-libusb to create a small program that sends those bytes to the keyboard: https://github.com/matheusmoreira/ite-829x/blob/master/ite-8... This user space driver gave me access to most of my keyboard's functionality on Linux. I used to have to boot into Windows in order to configure the keyboard lights -- not anymore! The keyboard also generates some custom key codes that are used by the proprietary Windows driver to implement some Fn hotkeys. I know this because the kernel logs these unknown key events. To implement this, I'll have to make a real kernel module that maps them into something user space can make use of. To this end, I've been studying the Linux kernel's documentation: https://www.kernel.org/doc/html/latest/driver-api/usb/ https://www.kernel.org/doc/html/latest/driver-api/usb/writin... https://elixir.bootlin.com/linux/latest/source/include/linux... The input_mapping, input_mapped, event and raw_event hooks seem especially relevant to my case: the custom driver just needs to process the custom key codes and let the generic Linux keyboard driver handle the rest. Might as well add sysfs entries for the LEDs but I don't know how to do that yet. I expect to end up with something like the open razer driver: https://github.com/openrazer/openrazer/blob/master/driver/ra... I used this site to gain a better understanding of USB itself: https://www.beyondlogic.org/usbnutshell/usb4.shtml