Re: [PATCH v12 00/14] HID: nintendo

On Sat, 22 Aug 2020, Daniel J. Ogorchock wrote:

I've included round 2 for the IMU support patch. The documentation is
improved and the precision increased for the gyroscope values reported
to userspace.

There is still the important question of how to deal with userspace
implementing custom drivers using hidraw (i.e. Steam). I am resistant to
having hid-nintendo completely yield when userspace uses hidraw, since
that would prevent other applications from receiving the events from the
controllers (like maybe someone configures a voip client to use one of
the triggers as push-to-talk).

In my personal testing with steam, I don't see much issue since I
introduced the patch to not send rumble subcommands when no effect is
playing. Steam/hid-nintendo seem to fight when hid-nintendo is sending
lots of subcommands (e.g. rumble, setting LEDs). Others have reported
though that hid-nintendo/Steam are still fighting even with that patch.

I guess there's not much that can be done though to guarantee a
userspace and kernel driver coexisting at the same time, since one of
them could completely reconfigure the controller's reporting mode, IMU
resolution, etc.

The two extremes seem to be either having the hid drivers yield to
userspace completely when hidraw is in use (e.g. hid-steam with its
virtual hidraw dev) or mask out exposing the hidraw device when a kernel
hid driver is being used. It feels wrong to have things in the current
state where the HIDRAW device is being exposed, but it's not actually
supported.

Could you please elaborate a little bit better about this conflict? 
hid-steam and hid-nintendo seem to be supporting different VID/PID 
combinations, so that's not the conflict I guess.

Is Steam implementing some (proprietary?) userspace driver for conflicting 
VID/PID with hid-nintendo, using hidraw?

Thanks,

-- 
Jiri Kosina
SUSE Labs