On Thu, Feb 6, 2020 at 12:10 AM Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote: > > Hi, > > On Mon, Feb 3, 2020 at 12:23 PM Jiri Kosina <jikos@xxxxxxxxxx> wrote: > > > > On Mon, 3 Feb 2020, Benjamin Tissoires wrote: > > > > > 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". > > > > Well, it's not about "we broke it" in the first place, as far as I > > can tell. > > > > Roderick's concern is that 3rd party devices with overriden VID/PID > > malfunction for completely unrelated reason to (correctly working) changes > > done in favor of stock Sony devices, but it'll be Sony receiving all the > > reports/blame. > > After re-reading the code, I am not sure we can easily detect the > clones. So at some point, I think we will break them, but there is not > much we can do. I don't really have a solution for that :( > > > > > > 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. > > > > Yeah; which I wouldn't like to do for upstream kernel, but Sony could > > definitely do this for the products they ship. > > > > The same way distros are tainting their kernels when unsupported modules > > (but otherwise perfectly fine wrt. GPL and everything else) are loaded > > into distro-supported kernels. > > > > > 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/ > > > > ... and words can't express how thankful I am for that :) > > > > OK, I played with that idea earlier this week: > https://gitlab.freedesktop.org/libevdev/hid-tools/merge_requests/74 > I only have a Sixaxis controller, and I only implemented the USB part > of it (AFAICT). > Currently this ensures the button mapping is correct, and that the > LEDs are working properly. > We are still missing a few bits and pieces, but the initialization > (requests made by the kernel to start the device and press on the PS > button) is handled properly. > > If this is something Roderick would be interested in, we can then try > to extend this initial work on Bluetooth controllers and the DualShock > ones. We can probably help out there (need to ask official permission). We have similar tests in Android (still adding more). Just in case you are not familiar this is their framework: https://android.googlesource.com/platform/cts/+/master/tests/tests/hardware/src/android/hardware/input/cts/tests/ It is a small Java class and then there is a json blob with the actual test (forgot where the json is). It defines the report descriptors etcetera. Thanks, Roderick > Adding the clones ones based on the current kernel code is something > doable, but I do not expect Sony to be involved in that process. > > That being said, before we merge this particular patch about Gasia > controllers, now we need to implement a regression test first :) > > Cheers, > Benjamin >
