Re: [PATCH v11 00/11] HID: nintendo

From: "Colenbrander, Roderick" <Roderick.Colenbrander@sony.com>
To: Daniel Ogorchock <djogorchock@gmail.com>,
	"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Cc: Bastien Nocera <hadess@hadess.net>,
	Roderick Colenbrander <thunderbird2k@gmail.com>,
	linux-input <linux-input@vger.kernel.org>,
	Billy Laws <blaws05@gmail.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Jiri Kosina <jikos@kernel.org>,
	Siarhei Vishniakou <svv@google.com>,
	"s.jegen@gmail.com" <s.jegen@gmail.com>,
	Carl Mueller <carmueller@gmail.com>
Subject: Re: [PATCH v11 00/11] HID: nintendo
Date: Sat, 1 Aug 2020 19:59:11 +0000	[thread overview]
Message-ID: <BY5PR13MB382682A947A8FB72720AA718984F0@BY5PR13MB3826.namprd13.prod.outlook.com> (raw)
In-Reply-To: <CAEVj2t=Az1G6X9Kj050aXVetW+PX==LgoEM9C3ES886NsYygcw@mail.gmail.com>

> 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?

In hid-sony we are not doing anything like hid-steam is doing (no virtual extra hidraw device).

I just don't know how I feel about mixing of evdev and hidraw. It just means userspace drivers are doing things behind the back of the real driver (unless you add a virtual hidraw driver like hid-steam). For Sony devices I'm not a big fan as our devices are very complex. Our devices tend to use a single output report (same report id) for rumble, audio and other types of data. When we will expose audio properly, a user space application doing hidraw will mess up audio streams and other behavior (e.g. power settings are also in the same hid report).

I don't know a good way yet. Has the usage of EVIOCGRAB been explored? If I recall it was intended to claim exclusive access to a device at least for input. It is a way of avoiding of some of the issues for simpler devices.

Virtual devices could work too, but I really dislike the extra complexity to hid drivers. Just in Sony case our driver for future devices will already be quite complex. If we really want virtual device support, I don't think it would scale to add it to every driver. Maybe there would be a generic way in the HID driver in which drivers can blacklist certain reports or hook into just certain requests or so.

Thanks,
Roderick