Re: [PATCH v16 00/16] HID: nintendo

[Daniel Ogorchock <djogorchock@gmail.com>]

Hi Benjamin,

On Tue, Oct 19, 2021 at 6:19 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> On Tue, Oct 19, 2021 at 11:44 AM Jiri Kosina <jikos@kernel.org> wrote:
> >
> > On Tue, 19 Oct 2021, Jiri Kosina wrote:
> >
> > > > Rebased onto Linus' tree (sha 926de8c4326c14fcf35f1de142019043597a4fac)
> > > > Depends on Roderick's patch to add the player LED defines:
> > > > https://patchwork.kernel.org/project/linux-input/patch/20210908165539.3102929-3-roderick.colenbrander@sony.com/
> > >
> > > I just got Ack for the joydev part from Dmitry.
> > >
> > > v16 is now queued in hid.git#for-5.16/nintendo
> >
> > Benjamin noticed that I pushed wrong version of the branch -- the one that
> > still doesn't contain the LED_FUNCTION_PLAYER[1-5] defines, which I've had
> > staged here locally, waiting for Pavel's Ack (which is taking time,
> > unfortunately).
> >
> > So please ignore this branch for now, I'll push v2 once that situation is
> > cleared out.
> >
> > CCing Pavel as well here to make him aware of the issues this is causing
> > all over the place (see .e.g my mail [1] from yesterday).
> >
> > [1] https://lore.kernel.org/all/nycvar.YFH.7.76.2110181739310.12554@cbobk.fhfr.pm/
> >
>
> I am also jumping on this to raise a concern I recently had with all
> of the work we do for HID devices in the kernel regarding game
> controllers.
>
> Foreword: this is definitely not a NACK on the series, but more trying
> to open a discussion to take a step back.
>
> The SDL developers recently took a hard turn in how they are handling
> game controllers on Linux: libsdl now directly talks to hidraw or
> libusb to handle the controllers in user space, bypassing the kernel
> processing.
> Which means that a game working on a recent SDL release already has
> the PS5 player LEDs ready for instance.
>
> I think that part of this work was the integration of the steam client
> database, which already supports a lot of fix ups for game
> controllers.
>
> So I am starting to wonder if we are not adding dead code in the
> kernel, because both steam and SDL will disable the input handling of
> the controllers when they open the hidraw node (IIRC about what was
> done in this series).
>
> I know that Android/Chrome is interested in having actual input nodes
> created, but are they the sole users of those now?
> What is the benefit of having game controllers in the kernel?
>
> I am opening the discussion and we probably want to bring in the SDL
> folks here too. But I'd like to have some sort of confirmation that
> these series which are adding game controllers are not just adding
> dead code.
>
> Cheers,
> Benjamin
>

I agree that interactions with sdl are in a strange state where it
essentially bypasses kernel control over the controller. I'm not
really a fan of that technique when there's a specific kernel driver,
since it removes the ability for multiple applications to share the
input (e.g. if I wanted to bind one of the buttons on my controller as
a push-to-talk key in voip software while still using the controller
in a game). I understand why this technique was used, since it allows
for predictable cross-platform code from the sdl perspective.

The patch series follows the example of the hid-sony driver in
modifying the version field to allow userspace to detect the use of
the kernel driver, which gives userspace the option of behaving
differently if a kernel hid driver is in use for a game controller.

That said, I don't believe kernel game controller drivers are
amounting to dead code, since there are userspace applications using
evdev rather than libsdl for their controller inputs. A couple
examples specific to hid-nintendo:
https://github.com/DanielOgorchock/joycond
https://github.com/joaorb64/joycond-cemuhook

I know that several people use these kernel drivers alongside game
console emulators with evdev backends (e.g. dolphin, higan, etc.).

I'd personally like to see fewer cases of applications taking sole
control over the input devices, maybe keying off the version field
change mentioned above to determine their behavior. I understand that
is a tougher sell when the userspace driver implementation predates
the kernel driver's existence.

- Daniel Ogorchock