On Mon, Dec 6, 2021 at 7:24 AM Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > > Hi Angela, > > On Tue, Nov 30, 2021 at 02:51:48PM +0100, Angela Czubak wrote: > > Hi Benjamin and Peter, > > > > I am refreshing this old thread in order to clarify some things > > discussed here :) > > I specifically got lost when reading about virtual IDs for effects. > > Asking more inline. > > [...] > > > > > > > > > So, the solution we came to this morning, while talking to Peter, was > > > > > > > > that the HID driver for a simple haptic HID device would allocate a > > > > > > > > virtual device memory to store the effects and the parameters. > > > > > > > > > > > > > > > > This way, we can: > > > > > > > > - upload effect WAVEFORM_RELEASE with its parameters in id 0 of the > > > > > > > > drvdata of the device > > > > > > > > - upload effect WAVEFORM_PRESS with its parameters in id 1 of the > > > > > > > > drvdata of the device > > > > > > > > - ... > > > > > > > > - upload effect WAVEFORM_VENDOR_ZZZ_ZZZ with its parameters in id N of > > > > > > > > the drvdata of the device -> userspace will use it while scrolling for > > > > > > > > instance > > > > > > > > - ... > > > > > > > > > > > > > > > > Then the kernel on BTN_LEFT press can automatically trigger the effect > > > > > > > > with id 1 and the one with id 0 on release in the case of the > > > > > > > > autonomous mode mentioned below. > > > > > > > > > > > > > > > > To solve the question of knowing which effect should be loaded in > > > > > > > > which slot, I think we should rely on a userspace helper (udev?). > > > > > > > > We definitively not want the kernel to keep a list of devices to > > > > > > > > effects matches, but having a udev database (hwdb and intrinsic?) > > > > > > > > would nicely solve the issue as we do not need to update the kernel > > > > > > > > for each new device coming in. > > > > > > > > > > > > > > > > From the kernel driver, we can populate the WAVEFORM_PRESS and > > > > > > > > WAVEFORM_RELEASE with some sensible parameters, but userspace should > > > > > > > > be allowed to override them. > > > > > > > > > > > > > > > > The advantage of having this virtual memory of device effects, is that > > > > > > > > each userspace implementation could use its own matching for effects. > > > > > > > > For example, libinput might want to say: > > > > > > > > - id 0 -> BTN_LEFT released > > > > > > > > - id 1 -> BTN_LEFT pressed > > > > > > > > - id 0x1000 -> scrolling up > > > > > > > > - id 0x1001 -> scrolling down > > > > > > > > - id 0x2042 -> hard press > > > > > > > > > > Was there some idea up then to implement virtual effect IDs? Right now > > it seems that > > the number of possible FF effects is limited to FF_MAX_EFFECTS and > > that it is the kernel > > and not the user space that assigns the ID when an effect is uploaded. > > Or was it more of a suggestion for the future than a requirement > > regarding the simple haptic feedback implementation? > > I have to admit I barely remember any of this, it happend around a very busy > time and i have little recollection beyond re-reading this thread. The above > was an idea on how to handle custom waveforms, we never went past what was > suggested in this thread. > > Cheers, > Peter Just some additional pennies around this discussion. At Sony we do want to support our Haptic triggers (marketed as Adaptive triggers) as for example first seen on our PS5 DualSense controllers. We created a proof-of-concept, but we need an entirely different interface through evdev. The existing interface is too limiting due to the amount of data needed. The way our haptics works is essentially that per trigger (ABS_Z / ABS_RZ) you can set different types of haptic effects. Depending on the effect, you can have it start at a certain axis position. From that axis position you can make the trigger provide more resistance or it can even start rumbling. Haptic effects include a weapon like effect, a rumble effect, resistance effect and others. Apple implemented some in iOS recently for us. https://developer.apple.com/documentation/gamecontroller/gcdualsenseadaptivetrigger In any case, where I'm going with this is that there might be some similarities and we are running into issues with FF. For our PoC we created a new EV API (EV_HE for haptic effect). I didn't have time to polish it in anyway and wanted to keep it generic. However, there is reluctance in my understanding to add new evdev APIs. Benjamin for example is very keen on leveraging eBPF. So it is probably a bigger discussion. Thanks, Roderick
