My understanding is most for driver code is written in C or C++. The 'new' way of developing - the kernel development is in Rust.
How can this work that is written in pure Python?
My understanding is most for driver code is written in C or C++. The 'new' way of developing - the kernel development is in Rust.
How can this work that is written in pure Python?
The normal Linux drivers implement what's needed to receive the HID message. This just handles some vendor specific messages on top of that. A bit like how a program can send a custom vendor specific TCP message on top of the existing OS network drivers without having to itself be a kernel level network driver.
Solaar is not a device driver and responds only to special messages from devices that are otherwise ignored by the Linux input system
Sounds like this isn't working at the kernel level.
fast forward to today, and the hardware industry has made great advancements in standardizing how devices operate. memory-mapped I/O allows the OS to treat many device drivers the same, they just need to handle manipulation of the memory after it's read/written. for USB, the industry standardized on device classes , so something either acts like a communication device (serial port, JTAG reader), an audio device, a video capture device, or in this case, an HID (human interface device). So based on the general characteristics of how the thing operates, the kernel can do 80% or more of the driver development for you. especially because of the linux credo that "everything is a file"
you plug in a usb dongle and you get (hypothetically) a few files called /sys/class/hid/<serialnum>/{control, data}. so you could, say, change the RF channel of the dongle by writing a very specific value to the "control" file, which will get sucked in by the kernel and sent to the device. Or you could get raw kb/mouse data by catting the .../data file. this would in theory, allow you to write a device driver in python by connecting the .../data file to a read handler, processing the input (the hard part, which requires reverse engineering), and emitting the corresponding output, such as the OS command to move the mouse or generate a keyboard event.
I made some generalizations here, but this is the main idea.