Date:   Mon, 3 Feb 2020 11:48:14 +0100
From:   Benjamin Tissoires <benjamin.tissoires@...hat.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Roderick Colenbrander <thunderbird2k@...il.com>,
        Martyn Welch <martyn@...chs.me.uk>,
        linux-input <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "Conn O'Griofa" <connogriofa@...il.com>,
        "Colenbrander, Roelof" <roderick.colenbrander@...y.com>
Subject: Re: [PATCH] HID: Sony: Add support for Gasia controllers

On Mon, Feb 3, 2020 at 11:02 AM Jiri Kosina <jikos@...nel.org> wrote:
>
> On Tue, 28 Jan 2020, Roderick Colenbrander wrote:
>
> > Let me explain the situation a little bit better from our angle. These
> > devices exist and from the Linux community perspective of course they
> > should see some level of support. And as I said since this is PS3
> > generation I don't have much of a concern.
> >
> > Where it becomes tricky for any company in our situation is the support
> > side. We don't know these devices and don't have access to datasheets or
> > anything, but when such code is in our "official driver" it means we
> > have to involve them in our QA process and support them in some manner
> > (kind of legitimizing their existence as well). We now support this
> > driver in a large capacity (pretty much all mobile devices will start
> > shipping it) it puts challenges on our partners (not a big issue since
> > just PS3 right now).
> >
> > As you can see this creates an awkward situation. I'm sure there other
> > such devices as well e.g. counterfeit Logitech keyboards, USB serial
> > adapters and other periperhals with similar challenges. In an ideal
> > world the support would live in another driver, but since in case of
> > this "fake" PS3 controller it "share" our product / vendor ids it is
> > tricky. At this point there is not a strong enough case yet to augment
> > the "hid-quirks" to do so, but perhaps if it became a serious issue
> > (e.g. for newer controllers) maybe we need to think of something.
>
> If this is a big issue for you, one possible way around it would be
> creating a module parameter which would tell the driver whether it should
> those "fake" devices, and you can then turn it off in your products (or we
> can of course start the "what should the default setting me" bikeshedding
> :) ).
>

I am definitely not in favour of that :(

The basic problem we have here is that some vendors are overriding
your VID/PIDs, and this is nasty. And I do not see any reasons why you
can't say: "well, we broke it, sorry, but we only support *our*
devices, not third party ones".

One thing that comes to my mind (probably not the best solution), is
to taint the kernel if you are facing a non genuine product. We do
that for nvidia, and basically, we can say: "well, supporting the
nvidia blob is done on a best effort case, and see with them directly
if you have an issue".
Tainting the kernel is a little bit rough, but maybe adding an info
message in the dmesg if you detect one of those can lead to a
situation were we can count on you for supporting the official
products, and you can get community support for the clones.

One last thing. Roderick, I am not sure if I mentioned that or not,
but I am heavily adding regression tests for HID in
https://gitlab.freedesktop.org/libevdev/hid-tools/
Given that hid-sony.ko seems to only use pure HID communication, it
should be easy enough to write regression tests for the devices, and
this way you can split up the QA in 2: automated and upstream tests
run by me for all devices handled by hid-sony, and your QA can focus
on the actual physical hardware, and ignore all of the clones.

Cheers,
Benjamin

Powered by blists - more mailing lists