Hi Pierre-Loup, On Wed, Jul 22, 2020 at 1:54 PM Pierre-Loup A. Griffais <pgriffais@xxxxxxxxxxxxxxxxx> 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 >
