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
