Hi Bastien, Apologies for the late reply. This thread sneaked past me somehow. If we want to handle clone controllers with partial protocol implementations, is it preferable to present them identically to userspace, with non-existent functionality being no-ops? Or would it be better to just not create the interfaces for missing functionality (e.g. not create the led_classdevs for controllers without LEDs)? I assume the latter makes more sense, since it doesn't lie to userspace. Though it could potentially make the driver code messier. Thanks, Daniel On Mon, Apr 27, 2020 at 3:56 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > On Sun, 2020-04-26 at 15:31 -0700, Roderick Colenbrander wrote: > > On Sun, Apr 26, 2020 at 2:14 PM Bastien Nocera <hadess@xxxxxxxxxx> > > wrote: > > > On Sun, 2020-04-26 at 13:42 -0700, Roderick Colenbrander wrote: > > > <snip> > > > > I really wonder how a device like this should be handled. It > > > > looks > > > > like the device can also handle a bunch of other classic Nintendo > > > > controllers. > > > > > > > > Is there anyway of detection this adapter? It feels nasty to have > > > > to > > > > hack in quirks for this device... > > > > > > The end game isn't very different from how we handle XBox 360, or > > > PS3/PS4 "clone" devices. > > > > > > Those devices (the adapters) work on the actual Nintendo Switch > > > hardware, so should probably work with the driver that handles the > > > same > > > type of hardware on Linux. > > > > > > > (resend in plain text) > > > > I agree it probably makes sense to handle in this driver. I'm worried > > about the application level implications. We have been doing a lot of > > work e.g. on Android to try to make gamepads consistent. It is weird > > to have a "Switch controller" with different features as applications > > make assumptions and don't expect there to be multiple versions of a > > particular controller. Any button mapping files would potentially be > > wrong for those too, certain features are not there (e.g. no sensors > > or no lights or rumble) or if they are the behaviour is different > > (e.g. HD rumble vs a classic rumble motor). > > > > Ideally we would do some kind of "fixup" to change the device name > > and > > or replace the device ids to at least separate them. > > All those would be detectable at runtime. I'm not sure that it's ever a > good idea to presume that a particular VID/PID combination will have, > say, rumble and LEDs available when the driver can answer those > questions. > > For example, I'm not sure that those controllers have either features > (though I'm not certain they identify as Switch Pro controllers, but > for the sake of argument): > https://store.nintendo.com/super-nintendo-entertainment-system-controller.html > https://store.nintendo.com/nintendo-entertainment-system-controllers.html > > Cheers > -- Daniel Ogorchock
