Re: Forcepad interface design proposal

On Mon, Dec 6, 2021 at 7:24 AM Peter Hutterer [off-list ref] wrote:

Hi Angela,

On Tue, Nov 30, 2021 at 02:51:48PM +0100, Angela Czubak wrote:

quoted

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

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

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