Don't panic. Of course it isn't. Stop typing that angry letter to the editor and read on. I just picked that title because it's clickbait and these days that's all that matters, right?
With the release of libinput 1.4 and the newest feature to add tablet pad mode switching, we've now finished the TODO list we had when libinput was first conceived. Let's see what we have in libinput right now:
- keyboard support (actually quite boring)
- touchscreen support (actually quite boring too)
- support for mice, including middle button emulation where needed
- support for trackballs including the ability to use them rotated and to use button-based scrolling
- touchpad support, most notably:
- proper multitouch support on touchpads [1]
- two-finger scrolling and edge scrolling
- tapping, tap-to-drag and drag-lock (all configurable)
- pinch and swipe gestures
- built-in palm and thumb detection
- smart disable-while-typing without the need for an external process like syndaemon
- more predictable touchpad behaviours because everything is based on physical units [2]
- a proper API to allow for kinetic scrolling on a per-widget basis
- tracksticks work with middle button scrolling and communicate with the touchpad where needed
- tablet support, most notably:
- each tool is a separate entity with its own capabilities
- the pad itself is a separate entity with its own capabilities and events
- mode switching is exported by the libinput API and should work consistently across callers
- a way to identify if multiple kernel devices belong to the same physical device (libinput device groups)
- a reliable test suite
- Documentation!
- know the DPI density of a mouse
- know whether a touchpad is internal or external
- fix up incorrect axis ranges on absolute devices (mostly touchpads)
- try to set the trackstick sensitivity to something sensible
- know when the wheel click is less/more than the default 15 degrees
The hard work doesn't stop of course, there are still plenty of areas where we need to be better. And of course, new features come as HW manufacturers bring out new hardware. I already have touch arbitration on my todo list. But it's nice to wave at this big milestone as we pass it into the way to the glorious future of perfect, bug-free input. At this point, I'd like to extend my thanks to all our contributors: Andreas Pokorny, Benjamin Tissoires, Caibin Chen, Carlos Garnacho, Carlos Olmedo Escobar, David Herrmann, Derek Foreman, Eric Engestrom, Friedrich Schöller, Gilles Dartiguelongue, Hans de Goede, Jackie Huang, Jan Alexander Steffens (heftig), Jan Engelhardt, Jason Gerecke, Jasper St. Pierre, Jon A. Cruz, Jonas Ådahl, JoonCheol Park, Kristian Høgsberg, Krzysztof A. Sobiecki, Marek Chalupa, Olivier Blin, Olivier Fourdan, Peter Frühberger, Peter Hutterer, Peter Korsgaard, Stephen Chandler Paul, Thomas Hindoe Paaboel Andersen, Tomi Leppänen, U. Artie Eoff, Velimir Lisec.
Finally: libinput was started by Jonas Ådahl in late 2013, so it's already over 2.5 years old. And the git log shows we're approaching 2000 commits and a simple LOCC says over 60000 lines of code. I would also like to point out that the vast majority of commits were done by Red Hat employees, I've been working on it pretty much full-time since 2014 [3]. libinput is another example of Red Hat putting money, time and effort into the less press-worthy plumbing layers that keep our systems running. [4]
[1] Ironically, that's also the biggest cause of bugs because touchpads are terrible. synaptics still only does single-finger with a bit of icing and on bad touchpads that often papers over hardware issues. We now do that in libinput for affected hardware too.
[2] The synaptics driver uses absolute numbers, mostly based on the axis ranges for Synaptics touchpads making them unpredictable or at least different on other touchpads.
[3] Coincidentally, if you see someone suggesting that input is easy and you can "just do $foo", their assumptions may not match reality
[4] No, Red Hat did not require me to add this. I can pretty much write what I want in this blog and these opinions are my own anyway and don't necessary reflect Red Hat yadi yadi ya. The fact that I felt I had to add this footnote to counteract whatever wild conspiracy comes up next is depressing enough.
9 comments:
Many thanks for all the hard work!
Well done!
Hi! now that libinput 1.4 is out with all the nice features, how can I make use of them in gnome 3.20? I’m on an updated Fedora 24 computer with a Intuos Pro Small connected but no multitouch gestures seem to work and touch input lags so it’s difficult to even use it. i also wanted to say thank you for the great work!
Hi Peter. I use a trackball mouse and saw that you mentioned on this post that libinput has support for button-based scrolling. How would I enable this feature such that, for example, I'm able to scroll a page by holding down the right mouse button then moving the cursor towards the direction I want to scroll to? Apologies if this is not the appropriate place to ask my question.
Schicko: look up man libinput, you'll need the ScrollMethod and ScrollButton options set
Ok, will do. Thanks for your time.
I see you haven't even reacted to my post, so I guess I'm asking the wrong question. So you work on getting all the possible data to/from the tablets, while the guys at gnome need to make sure there are ways how to handle the data and provide a gui (which hasn't happened yet)? thanks
jruaj: we just pass the data on, it's up to the caller to handle/interpret it. for touch this means we do some gesture interpretation, at least on those devices that are touchpad-like (the bamboos are those devices). But Fedora 24 doesn't use libinput for wacom tablets yet, that's likely your problem here.
thank you for the explanation :)
Post a Comment