Hi Daniel,
Sorry for hijacking this branch of the thread (it's the last one that
survived my inbox) - it seems like merging this driver as-is would break
Steam, according to user reports.
Is there any mechanism built into this hid_nintendo patch series to duck
out of the way if userland directly opens the underlying hidraw device?
That's what hid_steam does to coexist peacefully with userspace drivers
(Steam being one of them, but not the only one).
Thanks,
- Pierre-Loup
On 5/22/20 12:11 PM, Daniel Ogorchock wrote:
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
