On Fri, May 6, 2022 at 8:59 AM Roderick Colenbrander <thunderbird2k@xxxxxxxxx> wrote: > > 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. > > > > Using this to hook into the thread with Benjamin. It didn't make it to > the list (due to HTML I guess) and replying from work email messes > things up (Outlook...). > > There is definitely a need for some type of hidraw / evdev interop. > What it should be I'm not fully sure. I think it needs to be some > explicit request or something from user space. > > In case of the Dualsense it is a very complicated device and many > features work through HID including many audio and other features, > which I hope to support at some point. I feel the need for the driver > to be able to 'snoop' what is going through hidraw. The extra node > hack allowed for that, though ideally if a hid driver could get some > callbacks without having to go through all this extra setup code, > would be great. FWIW, as you probably all know by now, I am implementing eBPF at the HID level, and one of the use cases is to be able to have a HID firewall. The main reason for it right now IMO is that we allow uacess for Steam on the PS controllers, but that also means that anybody can try to initiate a firmware update by talking to the correct endpoints. And even if we trust steam to do that properly or not doing it at all, we do not trust others. And this firewall might help you in some cases: > > For me the use cases for snooping include: > - Keep sysfs nodes in sync e.g. LED nodes with whatever a hidraw user > is setting. BPF might help here, because we can directly snoop on HID reports. We need to add hooks to sync the LED state, but that is doable. A pure kernel implementation would work too though. > - Error handling in case of a crashing hidraw client. E.g. a hidraw > client may enable rumble. If the application crashes, we probably want > the kernel driver to disable rumbling. This is going to happen sooner than you think. With the systemd pull request I mentioned in the other thread, we are going to have the ability to revoke hidraw accesses when the client is not in foreground or if there is a fast user switching. Resetting to a known working state is hard if we don't know the context, so we'll probably need some kind of helper in that situation. > - Handling of audio features (speaker, microphone, headphone jack > settings, ...). One day we will provide a proper audio driver over > HID. Many of the control features work over the same HID output report > as used for rumble, LEDs etcetera. Definitely firewall related, possibly with on the fly modifications of the reports. However, there is a chance we see SDL or Steam saying "I'm going to implement the driver on the userspace, so I can have it cross-platform", and it's going to be hairy :( > - When no users (hidraw / evdev) are connected, potentially enable > some of the power management features (e.g. disable touchpad / sensors > at the hardware level) Shouldn't be too hard to do without bpf, and by just adding the correct callback if any. We should already get a notification at the HID core level when there are no users (hid_hw_open/close IIRC), so maybe we just need a hook into the driver if there is not one already. Cheers, Benjamin > > There are probably some others as well. > > Thanks, > Roderick >
