Re: [GIT PULL] HID fixes

From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Hans de Goede <hdegoede@redhat.com>, Julian Sax <jsbc@gmx.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] HID fixes
Date: Wed, 20 Jun 2018 09:35:47 +0200	[thread overview]
Message-ID: <CAO-hwJLkOx-12HAG3YEEFjOsiQScSgetVoF6gi+KSCpXyGXeGw@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1806200913420.6203@cbobk.fhfr.pm>

On Wed, Jun 20, 2018 at 9:15 AM, Jiri Kosina <jikos@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