RFC: Support tablet tool pressure curves?
This is primarily motivated by this gnome-control-center issue to request adjustable min/max thresholds for the pen, in particular the min threshold part. The minimum threshold is a user specific configuration to set the pressure required for a tip down event to happen.
libinput currently hardcodes when a tip down event happens (5% of range). If we adjust the minimum thresholds libinput needs to adjust the tip down handling accordingly. So if we add min threshold support, we need to have this exposed by libinput, e.g. as libinput_device_config_tablet_tool_set_min_threshold()
.
Now the argument is that it would be more useful to shove max threshold and pressure curve into libinput as well. Technically this isn't needed since neither of those affect anything else in libinput but it makes for a nicer API and better consistency.
A possible API could be:
libinput_device_config_tablet_tool_set_pressurecurve(tool, A, B, C, D)
where:
-
A
isx/0.0
and defines the minimum pressure threshold. -
B
andC
arex/y
in the range of[0.0, 1.0]
and define two control points on the cubic bezierABCD
- Notably the Windows driver requires
B == C
but this seems to be primarily for a simpler GUI, there's no mathematical requirement for this
- Notably the Windows driver requires
-
D
is isx/1.0
and defines the maximum pressure threshold
This curve would give us min/max threshold handling as well as the pressure curve between these two.
I've always maintained that the pressure curve should be ideally handled by the application (to have per-application curves) and if not by the compositor but not by libinput. Having this handled in apps is unlikely to ever happen. Having it in the compositor is what happens today Windows, Macos and Linux and with application-specific profiles are handled through focus tracking and then applying a new pressure curve.
So the argument now is: if we need to add a new API anyway for the min threshold handling it's probably better to have the whole handling of pressure curves in libinput rather than just the min threshold and leave the bits above it to the compositor. This would remove a bunch of code from the compositors and unify it in one implementation.
The only technical downside is that if for some reason an application needs the unmodified raw pressure that one is no longer available. I don't know if there's a use-case for this though.
Thoughts?
Side note: this would also provide a work around offset bugs like #834 (closed) which are more difficult to solve heuristically.