I have been working for a while now on implementing haptic control functionality into Linux.
Following the earlier works in the upstream kernel that established this standardized interface ( Making sure you're not a bot! )
In short, this works on all haptic trackpads, and functions by switching the trackpad to “Host controlled” mode, in which a trackpad will only click when explicitly told to do so. Using Libinput, this simply manifests as triggering clicks/releases when a certain total pressure threshold is met. I hope to integrate such functionality too into other devices like MX Master 4, which newly released its own haptic functionality too.
Since the clicks are triggered explicitly by userspace, this provides a few main advantages:
- Userspace (KDE+Libinput) now can control/configure explicitly the pressure at which a click triggers
- And the force at which the click feedback is felt.
- KDE (And KDE’s in-house apps) can now send its own custom haptic feedback in response to certain actions being performed in the desktop. (For example, triggering a bump effect when window snapping)
- We use this newly exposed interface in Libinput to produce a brand new custom effect, where you can press down on your touchpad to trigger an ordinary click, then push down even further to trigger a secondary “Deep click”.
The Libinput details on how specifically will pressure thresholds and click intensity be communicated between libinput and KDE is still being worked on, but when that’s done that should be fairly trivial to add a configuration option into the KDE menu.
I believe that this would be a meaningful quality of life improvement, and would further help to improve KDE’s position as a modern, configurable, and feature complete desktop environment, and there is a lot of space to expand upon this functionality in the future as well. For example, the MX Master 4 mouse has a haptic button, and this same haptic feedback triggering on a mouse just like it would on a trackpad should map very well, and could be useful to set the groundwork as more hardware like this continues to be released in the future.
So from the KDE side, this would look like:
- KDE will still receive click events from libinput like normal.
- KDE will now newly start receiving deep click events from libinput in addition to normal click events
- KDE can also talk to the kernel to independently trigger haptic events as responses to its own events, independently of libinput.
- KDE will then add a new set of options to its trackpad configuration menu, to configure haptic click strength and sensitivity. This should be fairly straightforward and uncontroversial.
So the questions that I would like to open a discussion on are:
- What do we want to use a new deep click functionality for?
- What do we want to do with a new possible hardware feature to trigger haptics in response to KDE events?
My thoughts in response to 1, is that we perhaps could have it default be mapped to ctrl+click, and then over time slowly integrate this functionality into more and more places in KDE in a app and context dependent manner, like for example if we’re in dolphin, renaming the deep clicked item, or opening a settings for a widget we deep clicked, etc and have that be dependent on the individual app/component. Or should we implement an option in the menu to allow the user to map it to a custom script?
And for 2, maybe implement some sort of KDE framework for standardizing how haptic effects are sent, and then integrating that into the KDE shell for things like a haptic effect for window snapping, or triggering haptic effects when scrubbing over a timeline in kdenlive, or when you move the position of an app in the taskbar, etc. I believe there a lot of great potential uses for such a mechanism.
What are our thoughts?