Hello, On 5/5/22 22:21, Roderick Colenbrander wrote: > 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). > I would like to know more about these sysfs controls. I wasn't aware of any way to do this from userspace, and paired with udev rules that allow access to these controls (can udev modify sysfs permissions?) to the right users/groups, this might be a viable way to manage this. My sponsor is Valve, so that might be why this is somewhat familiar. They want to be able to have the Steam input daemon disable various reporting from the controllers without requiring root or getting too deep into the system, but I think udev rules that allow Steam itself access to the sysfs inhibition controls may be a good approach if there's a way to do that, especially already in the kernel. I know the kernel they're shipping right now is a few versions old. Thanks, Vicki >> Thanks. >> >> -- >> Dmitry > > > Thanks, > Roderick
