On Wed, Jun 20, 2018 at 9:15 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Wed, 20 Jun 2018, Linus Torvalds wrote: > >> But what is the *source* of this binary crud? >> >> Because no way in hell do we take binary crud from random places, and >> then add it to the kernel. >> >> NOT EVEN IF IT WENT THROUGH SOME "hidrd-convert" PHASE! >> >> And yes, now that I google for that hidrd-convert pattern, I see that >> we already have other broken chunks like this. >> >> Not ok. At least some of them seem to mention where the data comes from, >> eg >> >> "This is the original report descriptor as reported by lsusb -vd >> 046d:c294" >> >> but this one has no such information. >> >> So guys, you need to think about where things come from, and document >> how some random garbage came to be. Not just add it to the kernel. > > Well, at least for the ones I've done myself in the past, those are > hand-written from scratch. > > It's not really a firmware / code, it's just a description of the data in > the reports, so that HID parser can interpret it properly. >
In case it matters, I have an open-source python script that parses those blobs and output the same level of human description here: https://gitlab.freedesktop.org/libevdev/hid-tools/ (the script parse_rdesc.py). As Jiri said, this is all standardized and documented in the HID protocol[1], and this 'just' describes the data that will be sent over the transport layer. In this particular case, the descriptors were extracted from the Windows driver, not by looking at the binaries, but by looking at the data that was transmitted from the "device". The thing is the data is not stored on the device chip itself but on a third party driver from the vendor. However, from a windows point of view, the third party driver intercepts the I2C commands and supply the information when needed. So it is as if the device answered. Blame the vendor here that decided to reduce the costs and save a few KB on the chip :/ Cheers, Benjamin [1] http://www.usb.org/developers/hidpage/HID1_11.pdf
