Hi Pierre-Loup,

On Wed, Jul 22, 2020 at 1:54 PM Pierre-Loup A. Griffais
[off-list ref] wrote:

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,

I have run into the same issue of Steam/kernel fighting over the device.
I opened an issue describing it here:
https://github.com/ValveSoftware/steam-for-linux/issues/6651.

I'd been telling people to use firejail as a temporary workaround to prevent
steam from seeing the hidraw device. Note that hid-nintendo sets the most
significant bit of the evdev's version number to allow userspace applications
to discern it from the default hid device. There's no current mechanism in
the driver to yield to userspace using hidraw, but I can look at what
hid-steam is currently doing to accomplish that.

I guess the downside to that method is that any other process listening to
the controller's evdev events would cease to receive them (maybe a voice
chat program using one of the buttons as a push-to-talk hotkey or something
similar).

Does steam use hidraw for the sony dualshock controllers as well? If so, is
hid-sony doing anything special for that usecase?

As an additional note to anyone following this thread: I have a newer patchset
I need to submit which has a couple fixes for issues people have found while
testing (sets a missing power supply flag and improves bluetooth connection
stability). I will probably hold off on submitting that until we
figure out the right
solution to the hidraw issue.

Thanks,
Daniel

  - Pierre-Loup