
Linux Touchpad Like a MacBook update: progress on multitouch - wbharding
https://bill.harding.blog/2020/06/22/linux-touchpad-project-update-progress-on-multitouch/
======
ZeroCool2u
Damn. This is the first open source project I've ever sponsored and been
really excited about sponsoring.

However, I've been using Ubuntu on Wayland for the past 2 years and have
thoroughly enjoyed it. Frankly, I'm not willing to move back to X and it seems
like a step backwards to me to invest any time, effort, or money in X at this
point, so I'm going to discontinue my contribution.

I was hoping my monetary contribution would be a small ($25/Month) way to push
Wayland forward, but the approach Bill and Povilas are taking is doing exactly
the opposite by making it more comfortable for folks to stick with X. I
understand there is disagreement and apprehension among the community with the
slow move to Wayland, perhaps not at the same scale of systemd, but I firmly
believe it's the best path forward and that X should be left behind.

~~~
1_player
That's unfortunate. AFAIK GTK4 will be Wayland-only and out in a few months,
and some bleeding edge distros such as Fedora already run Wayland out of the
box, except if you have NVIDIA, because Xwayland is still crap under nv; but
not for long, apparently there's some rumours and intention to improve the
nv/xwayland situation, just nothing concrete out yet [1].

So yeah, betting on Xorg in 2020 is not a smart move IMO.

1:
[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-G...](https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-
Generic-Allocator-2019)

~~~
p12tic
> AFAIK GTK4 will be Wayland-only and out in a few months

I think this is incorrect. See the following, X11 backend is listed among
supported backends. [https://developer.gnome.org/gtk4/stable/extra-
configuration-...](https://developer.gnome.org/gtk4/stable/extra-
configuration-options.html#id-1.9.2.6.7)

------
thinkbud
Honestly the write up seems ok but does not evoke optimism to me. I can't help
it but to me macOS and it's multifinger gesture support is not about how many
gestures it supports or which actions it supports, but the fluidity of the
execution of gestures with animations.

When you start pinching/unpinching fingers apart, the zoom happens in sync
with your finger spacing. As soon as you start pinching, the application seems
to receive with the event stream all the x and y coordinates so that pan and
zoom can be done simultaneously in lockstep with the finger positions and
spacing on the touch pad.

Similarly when you pull 2 or 3 fingers from the side to e.g. go back a page,
the reveal animation starts, or an arrow appears, and you can change your mind
mid gesture by reversing the finger movement and the animation feedback is
helpful enough to tell you that indeed the gesture will be canceled.

I honestly hope that the developers interested in improving this in libinput
and stack have the same understanding that gestures are not about recognizing
the one-off side/pinch movement with a couple of fingers, but about low
latency fluid interaction of fingers with visual animation feedback tightly
coupled. The other (one-off) type of gestures where you swipe your three
fingers to the left and then after a sampling interval the framework or stack
receives a ThreeFingersLeft swipe event (with length or time or xy values) is
IMO a very underwhelming experience.

~~~
CountSessine
I’m a long time MBP user who’s switched to Linux on a thinkpad recently, after
the butterfly switch debacle.

I think the one gesture I used more than any other on my MBP was the 4-finger
swipe left and right to switch workspaces. I would have a fullscreen
iterm/tmux/vim session in each workspace - each tmux is a separate project
with multiple panes and windows. I can't really bind a keyboard shortcut to
switch workspaces because I have so many shortcuts already bound to
tmux/vim/coc and other vim extensions, which is why it's so nice to be able to
switch workspaces with a touchpad gesture. I could flip back and forth between
workspaces effortlessly, without losing precious key shortcuts for
development. It’s a fantastic dev setup.

Fedora 32 seems to support this now! I don’t think that F31 did, but on F32 I
can do the 4 finger swipe to switch workspaces, and on my thinkpad it works
pretty much as smoothly and as interactively as it did on my MBP - swipe
slowly and the screen slides following your fingers, change direction in the
middle of the gesture and the screen slides back - the whole ‘stream input
events and the screen is an extension of your fingers’ as you describe.

The Linux desktop is getting a lot better. I don’t think I would ever have
switched without Wayland and now they’re getting gestures right.

~~~
tstrimple
Three finger drag is the killer one for me. Once you're used to it, it's
difficult to go back.

~~~
jonny_eh
Agreed. It strikes me as odd that Apple hides this ability deep in the
Accessibility settings.

~~~
vetinari
Because it changes the gestures for workspace switching / expose. They are no
longer three-finger, but four-finger, thus more difficult.

I'm in the group that gladly foregoes three finger drag, if it means we get to
keep other three finger gestures.

~~~
FillardMillmore
When did switching workspaces become four-finger? Meaning you can't use the
three-finger option? Catalina? I have a MacBook Pro on Mojave and the trackpad
accepts three-finger for the gesture of switching workspaces and the Magic
Mouse has an option for two-finger.

~~~
vetinari
When you enable three finger drag, all the other gestures will switch to four
finger.

Disabling the tree finger drag is not enough to return everything back, you
have to configure that in separate control panel.

------
kerkeslager
The touchpads on Macs are, in my opinion, one of the biggest advantages they
have. It's not just multitouch, it's also the sensitivity, the clarity between
clicks and scrolling, and the general responsiveness of it. Force clicks are
one exception: when I force click it's almost always by accident and I have
never found a situation where force click was tied to useful functionality.

~~~
xrisk
I think force click to look up the dictionary is useful, but that's pretty
much it.

~~~
exprez135
My Catalina install broke the dictionary app for me, so there are no
dictionaries other than Wikipedia. This was one of the most useful features of
force touch for me :(

~~~
LeoPanthera
You can reinstall macOS without erasing your data or apps. Maybe give that a
try. [https://support.apple.com/en-us/HT204904](https://support.apple.com/en-
us/HT204904)

------
geerlingguy
After trying out my Magic Trackpad on Pi OS a couple weeks ago, and finding
that experience to be somewhat frustrating, I found out about this project and
immediately sponsored it.

Even on Windows, trackpad support with my giant Apple trackpad is pretty good.
On Linux (at least with Pi OS and XFCE) I couldn't figure out how to get it to
have any good acceleration curve or work at all like on my Mac or Windows
laptop.

Scrolling was pretty smooth, but the cursor control was all over the place, so
I had to pull out an old mouse for that day.

~~~
dhosek
This is one of those things that mark where the Linux desktop experience falls
short. I've been a trackpad user since 1997 when I bought a keyboard with a
built-in trackpad for my home-built OS/2 system, and the superiority of the
experience on Apple hardware has been a significant factor in why I've stuck
with Apple as my primary OS since 2001. I've occasionally had to use Windows
for work since then and the trackpad experience has gone from unusable to
acceptable but it still hasn't caught up to the Mac and Linux hasn't caught up
to Windows.

~~~
Yetanfou
I've been using trackpads since Cirque launched the GlidePoint, using it first
in OS/2 and later in Linux. I have never had problems with these things other
than the touch surface wearing through, the things generally 'just work'. I
tend to increase the acceleration factor so I can move from left to right in
one fell sweep, use two-finger scroll, touch-to-click and sometimes double-
and triple-touch to click for button 2 and 3. What are these problems I keep
on hearing Apple aficionados talk about which make life on Linux unbearable?
Is it fancy gestures? If so, there's tools for that. Is is the size of the
pad? Well, just use a bigger one. For me it just works so I don't understand
what the problems are, all I read is that 'the experience is bad' and
similarly subjective claims. Can you give some objective examples where a
Linux-based desktop fails to live up to expectations related to trackpad
support?

------
agurk
I was impressed with the momentum this project has been building and was just
about to sign up to become a sponsor. Reading the update though shows their
current focus on X.Org - as an otherwise happy Wayland (Mutter) user I'm going
to hold off supporting this until they start making changes that will benefit
me.

~~~
p12tic
Povilas from the linked article.

It's not obvious, but adding touchpad gesture support to X will benefit you
too even if you're not using X.

This will make our work of convincing the maintainers of other open source
projects much easier. X and Wayland cover essentially al Linux users, so we
will not need to estimate how many users will benefit from implementing
gesture support in toolkit X or application Y.

This is really important, because maintainers of open source projects don't
usually care about suggested features if they're not interested in them
themselves. A new feature means additional work to them - discussing the
design, reviewing PRs and handling of eventual bugs. Often the person who
implements a feature disappears after the PR is merged. This makes the
maintainers to view all feature proposals with a grain of salt. We need to
have a convincing story of how majority end users would benefit in order to
make the contributions easier.

~~~
modzu
i dont follow..

~~~
p12tic
Say you have a widget toolkit that doesn't support touchpad gestures. The
maintainers of that widget toolkit would be more willing to integrate this
feature if there's support in both Xorg and Wayland compared to Wayland alone.

------
sitkack
The focus on multi-touch gestures is missing the forest for the trees.

If you look at the all of the next highest rated "features" they are not
features but bugs. The reason that mac touchpads are so nice to use has
_nothing_ to do with multitouch and everything to do with palm rejection,
filtering, etc. It is a hard problem, analogous to and more difficult than
writing multicopter flight control software. Having looked at the trackpad
code, and fixing (in a very hacky way) some of the issues I was having, I have
zero expectation that Linux laptops will get a mac like experience in the next
couple years. Like all problems, it isn't a technical it is political.

Trackpad software and cut and paste are the two largest detractors for desktop
Linux.

~~~
ssivark
> _Like all problems, it isn 't a technical it is political._

Could you explain how/why? Is it about specializing in specific
hardware/firmware?

~~~
p12tic
Povilas from the linked blog here.

In open source often no one really cares about a suggested feature or even a
submitted pull requests. It means additional work for the project maintainers
- discussing design, reviewing code and handling of eventual bug fixes. Often
the person who made a PR disappears leaving all future bugs the problem of the
maintainer. So naturally project maintainers are risk averse and often say no
to new features. Things end up not being implemented, not because it's
technically difficult, or there's nobody willing to do the work, but because
the incentives don't align.

The above opinion applies to open source in general as I've witnessed during
the past decade. I'm not describing any projects that are related touchpad or
input that I've been interacting with lately.

------
grawprog
I'm curious how this will compare with
[https://github.com/iberianpig/fusuma/blob/master/README.md](https://github.com/iberianpig/fusuma/blob/master/README.md)

I've also personally been using multitouch zooming and scrolling in kde for
years now.

It will be cool to see a simplified, 'just working', desktop independent
multitouch system for linux though.

~~~
ah-
With full gesture support we'll hopefully get more interactivity, so e.g. if
you switch workspaces with a four finger drag it moves as you perform the
gesture and stops if you stop moving your fingers. fusuma seems to only
recognise the gesture and then run a command afterwards.

~~~
thinkbud
Exactly, gestures without interactivity are honestly not worth it in my
opinion.

~~~
shaan7
Depends on what "not worth it" means really. Even though gestures minus
interactivity is far from how "proper" gestures feel, I'd rather have
something rather than nothing (for example, it is still more convenient to
3-finger swipe to switch virtual desktop than a keyboard shortcut or clicking
a button).

~~~
thinkbud
Ok, I admit that "not worth it" is better rephrased as "not the end goal". If
the end goal is interactive gestures, one-off discrete gestures are welcome as
an intermediate step or halfway solution.

Ideally the input framework would know if the streamed gesture was consumed
real-time, and if not (e.g. no support for such interactice gesture in some
program), the one-off event is issued.

This reminds me of current xorg libinput two finger scrolling / wheel event.
Xinput2 is the relevant keyword but I am not sure exactly how it all fits in,
only what I can observe: \- applications that don't know about multi finger
scroll/pan listen for and accept classic mouse4 / mouse5 events and interpret
them to scroll in steps if relevant. As an example, xev x event testing uility
is not xinput2 aware AFAIK nor are classic x or older gtk programs \-
applications can be xinput2-aware (e.g. eog Eye of Gnome image viewer, but
maybe also any non-ancient gtk3 application as well), in which case they can
scroll more directly (pixel-smooth) and with appropriate acceleration /
smoothing / inertia (gtk-specific ?). In firefox there's an env var like
MOZ_USE_XINPUT2 which tells firefox it can do this smoother wheel handling,
not sure if it's required or automatic these days. To test received events
including xinput2, there is utility xinput --test-xi2

As a closing anecdote, there's an interesting interaction bug I have
experienced with xfce where both xfwm will react to Super+scroll (compositor-
level full screen zoom), and the application under the mouse pointer will also
react to the scroll up/down. I have not deciphered the interactions here but
it depends on app under mouse cursor...

------
habitue
It sounds like no matter how much money is put into this, the sheer variety in
how graphics are done on linux is going to make this a neverending task.
Others have rightfully mentioned that the syncing animations with the trackpad
is the big thing that makes the experience better, and even with Wayland,
you're talking about interacting with both the window system and the
compositor, both of which can be different.

I'm not a huge fan of apple, but these kinds of small details are basically
impossible to get right unless you've spent decades relentlessly deprecating
old apis and consolidating them so there's only one fish in the barrel to
shoot.

~~~
bluedays
Since we can't see the source for MacOS or Windows we can't judge whether or
not these are the same challenges that they also faced. Aside from the
different display server protocols the challenges may not be unique to Linux.

Perhaps the money that went into supporting this feature allowed them to
overcome these challenges with much more ease. Unless someone who is more
familiar with the source of MacOS can clarify otherwise I think it would be
safe to say that this is not a new challenge, perse. Just new to Linux.

------
hajile
My pixelbook touchpad works incredibly well (better than a macbook IMO). Is
there any way that work can be integrated into this project?

~~~
jeffbee
Also using a Pixelbook here. Interestingly last time I had to reboot for
update it spent a long time reprogramming the firmware in the touchpad. I
wonder if this means that Google develops the touchpad firmware or if they
just ship vendor firmware. Either way, I agree it works perfectly and the
correspondence between my gesture and the animation of the display is perfect.

------
urbeanplayed
As a long-time Linux on desktop user and tweaker, an early adopter of libinput
under X, and an early adopter of Wayland, a historied-user of MBPs with nice
touchpads, and Chromebook Pixels with glass touchpads, I just don't get it.
There's still very little concrete information here that gives points to any
solid net improvement for anyone using a modern Linux desktop (aka
Wayland+libinput, which already support all of the original goals of this
project).

If you read the first two blog updates, they're straight out of FAANG PM-speak
land. I can just hear the words echoing from a PM who vaguely understands an
amalgamation of customer wants, without having any of the technical context of
_actual_ customer needs, architectural limitations, alternatives, etc.

And this is exemplified in the nearly useless survey data. It is so poorly
sliced, and presented that it's hard to know what was learned. There's no axis
for X/Wayland, which X input driver was used, what DEs were used, etc. All of
these significantly matter in the day-to-day feel of the touchpad considering
how libinput is configured.

Frankly, and this blog post more or less implies it, Wayland and libinput
address nearly all of the original goals, and the ways in which they don't are
either bugs in the drivers/libinput quirks that should be filled and fixed in
libinput, or are simply the choices of GTK/Qt toolkits or DE designers and are
part of a bigger design discussion that could help establish better defaults
across toolkits+DEs.

I just don't see why people are putting their hopes or money on this project.
I don't see current, useful-to-Wayland problems being identified or worked on.

Finally, a tip, for wayland + gestures, consider `gebaar-libinput`. And a
solid net improvement to libinput (and up the stack) would be "stop scroll
events". It's the only thing keeping the scrolling experience in
Firefox+wayland+webrender from feeling just as good as Safari on a MBP.

------
kitotik
With such limited resources, I wonder if just targeting wayland initially
would get usable results faster.

~~~
pantalaimon
Most users are on Xorg, so this will have the most impact.

There is also no single Wayland compositor they could focus on.

~~~
vertex-four
There are, in practice, 3 that anyone cares about - GNOME’s, KDE’s, and
wlroots. I don’t know how much of their work is potentially portable across
the three.

But while most users are currently on Xorg, the work going into improving
responsiveness and suchlike is all going into Wayland. This project is really
putting lipstick on a pig.

~~~
floatboth
Also, compositors don't really need much improvement in this area, everything
has been done ages ago.

It's all about the toolkits, and some great work is happening in GTK, e.g.:

[https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1562](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1562)
[https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1117](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1117)

------
Onyros
I would settle for Chrome OS-like touchpad smoothness and gestures in Linux.
The out-of-the-box touchpad sensitivity and scroll smoothness in Chromebooks
with outdated hardware and something as low-end and old as an a Celeron N2840
is incomparable to anything I've ever managed to configure in Linux,
multifinger gestures included.

------
hootbootscoot
I'm still stuck on default trackpad Y-scroll direction under Linux. I've done
some hacky input stream filter fix, but it's not working in ALL applications.
(dunno why...don't really care...)

I STILL feel uncomfortable using my thinkpad scrollpad in geany under linux,
as it jumps and the scrolling isn't clearly indicating (through some
animations i gather?) scrolling direction when I drag 2 fingers up and down...

Multi-touch, great!

...I just feel like basic behavior still appears to be an anti-intuitive, if
admittedly equally logically viable (swiping the paper up or down vs swiping
the scrollbar, metaphorically speaking)

~~~
6AA4FD
Could be wayland/xwayland if you're using that. My first thought.

~~~
hootbootscoot
thanks for the helpful tip! but alas, I'm still on Xorg

------
modzu
wait, what? so if they are ignoring wayland wont default ubuntu users on gnome
not get these benefits? seems odd to do all the surveys and research but not
actually check what distro/compositor respondents use?

~~~
nomadluap
from the article, apparently Wayland display servers already support multi-
touch gestures.

------
sly010
One of the difficulties of working on any improvement in the free-desktop
ecosystem is the difficulty involved in getting everybody on the same page.
It's interesting to realize that the chops required to write the code is not
necessarily the same as the experience required to push a project to
completion. This of course shouldn't be surprising, the product management
role is present in every high performing organization, what's surprising is
that it's taking so long for the open source ecosystem to realize the
importance of this.

------
wing-_-nuts
Double Tap to Zoom. That's literally the only thing I desperately miss from my
touchpad on linux. If anyone knows of a way to get this on linux, please let
me know I'd be ever grateful.

~~~
ghostpepper
In case anyone is unfamiliar, on a mac in chrome or safari (not firefox for
some reason) on any article, a double tap with two fingers on any row of text
will smoothly zoom the page so the text takes up the exact width of the window
- effectively hiding the margins while preserving the formatting of the text
(ie. not reflowing the text)

------
dang
Recent threads:

[https://news.ycombinator.com/item?id=23235609](https://news.ycombinator.com/item?id=23235609)

[https://news.ycombinator.com/item?id=23080435](https://news.ycombinator.com/item?id=23080435)

[https://news.ycombinator.com/item?id=23039515](https://news.ycombinator.com/item?id=23039515)

------
noiv
I'm on Ubuntu Gnome with touchegg and use three finger up/down for workspaces
and three finger left/right for the history in browser and Nautilus. There's
even a gesture to toggle tabs in Firefox like ctrl-tab. It's not as smooth as
a Mac, but still better than Windows :)

------
derefr
How does Android do multi-touch? How do Chromebooks? Is none of that work
portable?

------
ah-
Woo! Amazing progress, and great to see the sensible approach. Well done
Povilas and Bill.

------
MayeulC
Unsure why the blog article itself is in an iframe?

[https://public.amplenote.com/embed/TnE3JJDDy5QDo5aZAYtqyHz4?...](https://public.amplenote.com/embed/TnE3JJDDy5QDo5aZAYtqyHz4?hostname=bill.harding.blog)

This plan has also has a huge flaw, that can be shortened to one letter: X.

    
    
        > Add gesture support to the Xorg display server
        > A "fun" fact: if all of this work was already done today, it would appear on Ubuntu as of next April's release.
    

I'm betting you a drink that next April's release won't have an updated X
server package. I haven't been following ubuntu packaging too closely, but
last major x.org release was in 2018, and the next one hasn't been discussed:
[https://en.wikipedia.org/wiki/X.Org_Server#Releases](https://en.wikipedia.org/wiki/X.Org_Server#Releases)

I expect Wayland to be the default on even more systems by then, maybe even
KDE could default to it? Though Qt has been weighting them down with the
transition, there are less and less rough edges remaining.

So, this is probably going the hard way, for little at the end. It sounds like
it caters more to the author's system configuration of choice (well, it's
their money, though not really).

As the author said, Wayland has most of the bits in place, we mostly need to
tweak toolkits into supporting this (Qt, SDL, wx, fltk, Gtk?, etc). Starting
there would lead early results, and the code path might be reusable is X is
worth implementing later.

On the other hand, X.org probably nears its final release, so if you want it
to be burried _with multitouch support_ , it's probably a good strategy to
hurry.

Let's see who is left in the X ecosystem:

    
    
        * GNOME: moved on to wayland, mostly, though strangely not with Ubuntu
        * KDE: moving along, a lot needs to be done in Qt
        * i3: sway is mostly compatible and quite nice to use (typing this there)
        * XFCE/LXDE: not sure, I think the projects have merged into LxQt, which has wayland support comming along. XFCE itself meanwhile doesn't have a timeline for wayland, but I think it's on the horizon
        * Openbox/fluxbox/Windowmaker: you're probably not into wayland. But there's a myriad of Wayland compositors that caters to the same
        * firefox: starts to work quite nicely, has hw-accelerated video decoding now under wayland.
        * Inkscape: supports it as of the 1.0 release
        * Gimp: On the roadmap for 3.0 with the GTK3 port (same situation as Inkscape)
    

Tablet support is here (mostly), network transparency now has an alternative,
albeit quite young, with waypipe ("network transparency" has never been a
fundamental issue with Wayland, waypipe was bound to happen, I expect a lot
more rough edges will disappear once 90% of the users are on Wayland).

The missing pieces of the puzzle now are probably xdg-desktop-portal+pipewire
support in the web browsers, that I often see people complaining about (and
GNOME having their own screenshot interface doesn't help). That is coming. And
the last piece, unified color correction with HDR support, I don't know that
much about it to comment, but I've at least seen some work on HDR support for
sway.

~~~
abrowne
Chromium is also still X-only, which also includes Electron apps.

