On Mon, Feb 3, 2020 at 11:02 AM Jiri Kosina <jikos@xxxxxxxxxx> 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
