Brad DeMorrow <[email protected]> wrote: > I'm trying to add support for Xbox One Controllers to OpenBSD. > > It looks as though I can fairly easily get the device to attach as a uhid > device, but I believe the device requires some special initialization data > sent to it before it will actually begin functioning. > > That being said, I'm pretty sure that the answer is not to continue adding > special cases within uhidev.c - it feels weird already that there is Xbox > 360 controller code inside there to me, to be honest. > > My question is this: If I create a new driver that attaches after uhidev, > will software expecting a standard HID gamepad work, or will they not work > because they haven't been taught about my new, special driver? > > If a new driver isn't the answer, and it must remain a uhidev device - is > there a standard approach to something like this? Should I just break out > the Xbox Controller code into a new file and call out to it from the > uhidev.{match,attach,detach,etc..}? > > Should Gamepads be exposed via wsmux like keyboards and mice instead?
there is an extended discussion happening elsewhere about how the ugen and uhid 'generic' interfaces are very unsafe. If a user wants to use one specific device, (since everyone expects usb port agility) they must chmod a+rx /dev/uhid* or /dev/ugen*, depending on the usb device's capability. But this means any softwre on the machine may open and talk to any and all usb devices without drivers 'in-the-raw', creating side effects. There are a lot of downsides. My strong preference is that we encourage people to write proper kernel device drivers, and thereby reduce the incentives which prompt people to chmod a+rw all the unknown devices on their usb busses. It is a mess.
