Input handling in spring 2025

Community Blogs
1

Since Akademy 2024, input handling improvements have been one of three KDE Goals with myself as a co-instigator. You may be wondering why you didn't see a series of dedicated blog posts on this topic, which I had hoped to write. Instead of taking accountability for a longer absence from Planet KDE, here's a quick recap of what's noteworthy and exciting right now.

This is a companion discussion topic for the original entry at https://blogs.kde.org/2025/05/14/input-handling-in-spring-2025/
7 Likes
2

It’s really encouraging to see the combination of existing volunteer work, funded projects, and clear opportunities for new contributors to jump in! Nice write-up @jpetso :slight_smile:

2 Likes
3

The main thing that I hope to see, as a user on handheld PC (ROG Ally) is making drag-to-scroll touch input more consistent and intuitive. On many elements and apps, it works well. On many of the applet windows, it doesn’t properly scroll down when I touched and then dragged up on the content. Nor does the scrollbar properly follows dragging, sometimes.

Also, a good default On Screen Keyboard would be nice. The maliit one is really barebones. Steam’s is better, but it still lacks necessity like Ctrl, Meta, and Function row. And it both case, it still has some limitations with some apps, like playing the nwjs-based RPG Maker MV/MZ, none of the OSK inputs registers at all. I don’t like how Win11’s OSK is just so much better than any of the KDE ones.

It’s all getting better, but it is tough to feel that when your One Issue doesn’t see much update…

1 Like
4

Thanks for this insight. I am curious: Is a trackpoint (Thinkpad) configuration module on the radar of this project. It existed (quite a while ago) in the past.

5

The trackpoint generally announces itself as mouse, so it can be configured in the Mouse page in System Settings. (That’s on Wayland where different mouse devices can have different settings. On X11, there’s only a single anonymous mouse device with merged settings and input from everywhere.)

What kind of settings in particular did you have in mind for the trackpoint?

6

I am mostly missing tap-to-click/ press-to-select which in the past was configurable or you could do it with the command line. I used this a lot, but given up on it, as the setting was frequently reverted when updates where installed. Here is an (very outdated) page on the Trackpoint-config-options: How to configure the TrackPoint - ThinkWiki

7

Thanks. I tried running echo -n 1 > /sys/devices/platform/i8042/serio1/press_to_select on my ThinkPad and the path indeed exists, the feature actually works. I didn’t know it can do that. However, sudo libinput list-devices shows n/a for the Tap-to-click option, I’m not seeing another related setting either.

The Arch wiki shows how to make a udev rule to enable the press-to-select option on a permanent basis, that looks like it should generally survive updates.

If we want this to be exposed in Plasma’s System Settings, we need two things:

  • libinput needs to recognize and advertise support for this feature for trackpoints that support it.
  • KDE needs to add Tap-to-click (or whichever setting libinput provides for this) on the Mouse settings page. Currently we only show it on the touchpad settings page.

I’d recommend opening an issue on the libinput bug tracker to support the press_to_select toggle for trackpoints in some way. Let me know what comes out of it!

1 Like
8

Exciting news!
Love hearing that the input stuff is progressing nicely.

On that topic, are there plans to make mouse acceleration curves configurable, maybe in a graphical way in settings similar to the recently added drawing tablet pressure curve settings?

This would be very useful for being able to align mouse behavior more to how other OS’ feel, which is an especially nice feature to have for gaming.

9

That’s Bug 464868 and it’s kind of half done: the back-end part (a new KWin API) has been implemented before, and I missed this patch initially so I wrote an alternative version from scratch (oops).

What’s still missing is a graphical interface for exposing these settings. The code for the tablet pressure curve could be useful as a starting point, but it works differently from custom acceleration curves:

  • A tablet pressure curve goes from 0% to 100% on both the X and Y axis, with user-defined points anywhere in between.
  • A custom acceleration curve (as defined by libinput) maps from an X axis, measured in the scale of libinput pointer distance units per millisecond, to a Y axis that’s basically a speed modifier for the X value. There is no 100% mark because it’s always possible to go faster. Instead, libinput lets us provide a custom number of Y values with an evenly spaced, also user-defined step interval on the X axis. It then extrapolates from the last two provided X/Y values into infinity.

So, the concept is more complicated, it will be more of a challenge to represent it in an intuitive way. I can’t currently find the time to work on this GUI. If anyone is up for a first shot at designing and/or implementing this, I’m happy to discuss and test your stuff.

1 Like
10

Wow, I am glad I’ve stumbled upon this. 2 of the most sore points of Plasma from my point of view, and long-standing ones. I mean touch gestures and integration of layouts and input methods. I have hope now I will be able to switch to Plasma and ditch Windows / shrink Windows partition for good.