Hi Vicki, Joining the conversation late as I on a long vacation. On Thu, May 5, 2022 at 12:47 PM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > On Thu, May 05, 2022 at 10:50:24AM +0200, Benjamin Tissoires wrote: > > Hi Vicki, > > > > On Thu, Apr 28, 2022 at 12:52 AM Vicki Pfau <vi@xxxxxxxxxxx> wrote: > > > > > > This allows the touchpad input_dev to be removed and have the driver remain > > > functional without its presence. This will be used to allow the touchpad to > > > be disabled, e.g. by a module parameter. > > > > Thanks for the contribution. > > I'd like to hear from Roderick, but I have a general comment here: > > We had Wii and Steam controllers following this logic. Now we are > > adding Sony PS ones... That seems like a lot of duplication, and I > > wonder if we should not have something more generic. > I understand the use case of rejecting input. I wasn't that fond of handling it kernel side also because it would complicate the code a lot more (and some would perhaps want to do the same for accelerometer device). Below Dmitry gives a nice idea about inhibition. Methods I would considered perhaps would have been a custom udev role (it sounds like you have control of the platform). Or another method is using EVIOCGRAB to get exclusive access to an input device to block others from using it again depends on your specific use case. When this topic came up some years ago with Valve it was one of the methods considered there if I recall. > Hmm, if userspace is not interested in data from an input device (and it > does not want to simply not open it), it can use inhibit/uninhibit sysfs > attributes to silence it. > > I am not sure we need to build support for destroying input device or > introducing module parameters, etc. > Inhibition is interesting and could work. I wasn't aware of this feature and we may actually use it for hid-playstation to save some power as there are various HID commands for power saving when the device isn't open. If we were to add that, some care would need to be taken with HIDRAW, which the driver is often unaware of. I guess the end responsibility for making sure the device would work would be with the hidraw user (unless there will be some interop APIs). > Thanks. > > -- > Dmitry Thanks, Roderick
