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
