On Fri, 15 Jan 2021 06:23:01 -0700 Thomas Frohwein <tfrohw...@fastmail.com> wrote:
> On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote: > > On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote: > > > > > > I have heard from others who tried the diff that the PS4 > > > > controller is causing problems with the way it attaches. I > > > > ordered one to trial-and- error this myself at home. Could you > > > > share output of lsusb -vv? Thanks for giving it a try! > > > > > > Sure, here we go. > > > If I can find anything myself in the meantime I let you know. > > > > So the problem doesn't seem to be in your new ujoy(4) code, but how > > the dev/hid/hid.c:hid_is_collection() function tries to cope with > > the PS4 controller. > > So with the hid_is_collection() problem not easy to mitigate [1], > should we table the ujoy(4) proposal for now pending a fix for the > problems with the PS4 controller? Or is this interesting enough for > some to work on moving forward despite this issue and finding a > solution for this specific (and in some ways unusual) device later? > > 3-4 have tested and reported to me so far. It seems so far that the > only new breakage is with the PS4 controller, and there is probably > another solution that can be found later that doesn't break other > drivers like [1]? > > [1] https://marc.info/?l=openbsd-tech&m=161043081617336&q=mbox What I don't like when we import ujoy(4) as is; It will break currently supported devices like the PS4 controller. The kernel change won't even be the problem since the PS4 controller still would attach to uhid(4), same as before. But after the import we will need to start changing the ports for those controllers which attach correctly, and require the ports to query the new ujoy(4) device. At this point the PS4 controller won't work anymore ... And unfortunately it doesn't look like there is a proper HID fix in sight currently which would work for all the devices.
