Re: Forcepad interface design proposal

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.

[...]

quoted

quoted

quoted

quoted

quoted

quoted

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