From: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
To: Daniel Ogorchock <djogorchock@gmail.com>,
Bastien Nocera <hadess@hadess.net>
Cc: Roderick Colenbrander <thunderbird2k@gmail.com>,
linux-input <linux-input@vger.kernel.org>,
Billy Laws <blaws05@gmail.com>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
Jiri Kosina <jikos@kernel.org>,
"Colenbrander, Roelof" <Roderick.Colenbrander@sony.com>,
Siarhei Vishniakou <svv@google.com>, <s.jegen@gmail.com>,
Carl Mueller <carmueller@gmail.com>
Subject: Re: [PATCH v11 00/11] HID: nintendo
Date: Wed, 22 Jul 2020 11:54:14 -0700 [thread overview]
Message-ID: <292d45aa-cd32-3348-ce32-965281a52b20@valvesoftware.com> (raw)
In-Reply-To: <CAEVj2tnXNF0BCSdH46DmNRtxPRO7oHkjdmvJuCmiRz4t4pFWuA@mail.gmail.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
>>
>
>
next prev parent reply other threads:[~2020-07-22 19:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 3:29 [PATCH v11 00/11] HID: nintendo Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 01/11] HID: nintendo: add nintendo switch controller driver Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 02/11] HID: nintendo: add player led support Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 03/11] HID: nintendo: add power supply support Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 04/11] HID: nintendo: add home led support Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 05/11] HID: nintendo: add rumble support Daniel J. Ogorchock
2020-04-25 13:01 ` Bastien Nocera
2020-03-17 3:29 ` [PATCH v11 06/11] HID: nintendo: improve subcommand reliability Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 07/11] HID: nintendo: send subcommands after receiving input report Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 08/11] HID: nintendo: reduce device removal subcommand errors Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 09/11] HID: nintendo: patch hw version for userspace HID mappings Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 10/11] HID: nintendo: set controller uniq to MAC Daniel J. Ogorchock
2020-03-17 3:29 ` [PATCH v11 11/11] HID: nintendo: add support for charging grip Daniel J. Ogorchock
2020-04-01 16:27 ` [PATCH v11 00/11] HID: nintendo Benjamin Tissoires
2020-04-03 13:16 ` Jiri Kosina
2020-04-25 13:01 ` Bastien Nocera
2020-04-26 20:42 ` Roderick Colenbrander
2020-04-26 21:14 ` Bastien Nocera
2020-04-26 22:31 ` Roderick Colenbrander
2020-04-27 8:56 ` Bastien Nocera
2020-05-22 19:11 ` Daniel Ogorchock
2020-07-22 18:54 ` Pierre-Loup A. Griffais [this message]
2020-07-22 19:22 ` Daniel Ogorchock
2020-07-22 19:47 ` Bastien Nocera
2020-07-22 20:03 ` Daniel Ogorchock
2020-08-01 19:59 ` Colenbrander, Roderick
2020-08-04 5:59 ` Daniel Ogorchock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=292d45aa-cd32-3348-ce32-965281a52b20@valvesoftware.com \
--to=pgriffais@valvesoftware.com \
--cc=Roderick.Colenbrander@sony.com \
--cc=benjamin.tissoires@redhat.com \
--cc=blaws05@gmail.com \
--cc=carmueller@gmail.com \
--cc=djogorchock@gmail.com \
--cc=hadess@hadess.net \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=s.jegen@gmail.com \
--cc=svv@google.com \
--cc=thunderbird2k@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).