Re: Forcepad interface design proposal

[Peter Hutterer <peter.hutterer@who-t.net>]

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