[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2002031100500.31058@cbobk.fhfr.pm>
Date: Mon, 3 Feb 2020 11:02:19 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Roderick Colenbrander <thunderbird2k@...il.com>
cc: Martyn Welch <martyn@...chs.me.uk>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
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 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
:) ).
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists