Re: [PATCH v11 00/11] HID: nintendo

["Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>]

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@hadess.net> 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@hadess.net>
>>> 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
>>
> 
>