Linux touchpad like a MacBook: April 2020 update
bill.harding.blog
bill.harding.blog
One of the problems in inertia scrolling is that in Linux, it’s implemented in the driver level — which means that while scrolling by inertia, if I close the window, the window below will scroll. This is basically a hack because of backwards compatibility with the legacy APIs that only concern mouse events.
The proper way to do this (which is implemented in macOS) is to do this inertia scrolling in the GUI toolkit, which in macOS is AppKit. (macOS implements this in NSScrollView.)
Fixing this in Linux will be hard, since it needs coordinated effort between at least GTK, Qt, libinput, and the harware vendors — it’s an artifact of the fragmented ecosystem of Linux.
> Also personally I like the fact that inertia scrolling works everywhere consistently the same way.
> Just think about the horrors everybody now implementing their own scrolling.
Which should be a reason for advocating one toolkit that rules everywhere (maybe systemd-toolkit?), not a reason to have poor inertia scrolling experience that doesn’t work properly across different windows.
> Consequently the fact that Linux is "hacks over hacks" is a feature not a bug.
How can this is a feature, not a bug? Isn’t it technical debt?
(And I’m not joking — systemd gets criticized a lot about the monolithic design, but it’s design which ‘knows’ each other means that it can cooperate on big changes and features, provide consistency, etc...
> it’s an artifact of the fragmented ecosystem of Linux
You mentioned literally two frameworks gtk and qt, which both use libinput, i.e. one thing. How is this fragmented?
I considered it as fragmented b.c. the reason it was implemented this way (instead of implementing in the toolkit) was mostly because one can’t coordinate big changes in at least three big libraries (vendor drivers + libinput + Qt/GTK) to achieve something relatively small (inertia scrolling) when Apple can just decide to ‘fix everything related’ if one decides to adopt a new feature.
Not that fragmentation is a necessarily bad thing, but it’s not great in these cases.
That was my question. So macOS has one blessed toolkit working nicely and everything else feeling "wrong". So this has nothing at all to do with being "fragmented" but simply says "apple has one good toolkit and lots of bad ones".
I've been putting my hope on Linux, but what the world really needs, is for someone to create a unified vision for a Linux/BSD/open source based OS and hardware that basically takes the Apple approach, or at least the approach Apple had 15 years ago.
It's amazing how little progress there has been in this field. If I had money and some expertise in this area, I'd start my own company making better laptops with a Unix-like OS that's not afraid of breaking compatibility with old Linux ideas like this that are holding us back. But that's never going to be more than a dream.
That's what OS X did, only for BSD rather than Linux.
Meanwhile, it was few clicks on windows.
Atleast anything on ROC India/GST portal is impossible with Mac.
Not anymore, at least for any system that uses libinput (which I think is most of them at this point).
The reason libinput doesn't implement it is exactly for the reason you described, too.
The old synaptics driver worked as you describe (implementing kinetic scrolling at the driver level)
Libinput (which all modern distros switched to ages ago) does NOT implement kinetic scrolling at the driver level.
Instead libinput implements 'scroll sources' and it's up to the toolkits/clients to use that data to perform kinetic scrolling.
Unfortunately the state of Linux as a desktop OS in the past decade has missed entirely the hardware developments. No proper support for scaling for hidpi monitors, scrolling with precision mice/touch pads, no touch UI, UI is that still not deep enough and casually requires the user to spawn a terminal, graphics drivers that are still not stable and do not support the latest standards like hdr.
I wish there was a for profit company that would focus on making a polished desktop linux distro. There is only that much that the oss community can provide for free, but it is simply not enough.
It always had the options there in previous versions, but it only ever honoured the value you set on a single monitor. Now, I can have my 4K monitor at 200% while I leave my laptop at 100% (1080p) and it works perfectly.
If only it handled Bluetooth audio devices better it'd be perfect; Currently, I can't connect a pair of truly-wireless earbuds and play audio out of them without using Blueman to mess around with the audio sink settings etc each time I connect them. On my desktop, with Manjaro (KDE) and an Intel AX200 WiFi/Bluetooth I can connect both the earbuds (with no additional tweaking) and for example an Xbox One S Bluetooth controller (with the minor tweak of disabling etrm), and they both work perfectly.
I'm not sure how much of that is related to Gnome/KDE but Ubuntu really could do with some better Bluetooth device handling, especially for audio devices.
I own a pair of Master Dynamic MW07 and a UE BOOM speaker. As for my laptop, a Dell 7470 with Ubuntu 18.04.4
I've found that without Blueman installed my earbuds will pair but are not even detected as being an audio device. I dislike having Blueman installed/running so I'd like to get it working without.
I'm running Ubuntu 20.04 upgraded from Ubuntu 19.10 on an XPS 13 (it has worked on neither). I'm tempted to test on my Ubuntu 18.04 laptop (XPS 15) to see if perhaps it was broken recently.
One thing of note perhaps, is that the XPS range use the horrid "Killer Wireless" card from the Alienware/Gaming range, their Linux driver performance has been generally horrid in the half a dozen of them I've experienced.
I must therefore conclude that something has been broken since 18.04 as it neither worked for me on 19.10 nor now on 20.04.
You can do it on pretty much any modern X on linux using xrandr, FYI, it's just not easily done in a settings app. I've been doing this with xfce for a while.
On X11, scaling of entire framebuffer (i.e. scaling macOS style) is a standard xrandr functionality, but it was never exposed to UI. It has some drawbacks that macOS never had to solve (how it behaves over remote x11/vnc/etc, or memory requirements for framebuffer, for example), that make it unsuitable as a general solution. It is basically one of the hacks complained in this threads.
Are you saying it would have worked had I used xrandr?
Are you sure you were running Wayland? In Fedora under Wayland, you could pick a monitor and choose scaling for it in the setting applet.
It is quite possible that 18.04 has some bugs. I don't have 18.04 machine with hidpi monitor at hand, so I can't have a look myself, so I chalk it up that there is something weird happening.
I'm using the proprietary Nvidia driver.
My XPS 13 is using Intel from an 8th gen i7.
My xrandr line is not that easy to read but effectively, after I've set xfce hidpi support to double the size of screen elements, I increase the view window of the smaller screen by a factor of 1.8, and of the larger screen by a factor of 1.2, and put them next to each other -
xrandr --output HDMI-0 --mode 1920x1200 --pos 0x100 --scale 1.8x1.8 --output DP-2 --mode 3840x2160 --primary --scale 1.2x1.2 --pos 3456x-180
If Wayland can do that without so much messing around, great :)
Welcome to the world that Fedora users have been living in for years already. Ubuntu users can thank to Canonical's decision not to enable Wayland in 18.04 for that...
With a hindsight, the remote desktop/screen sharing solutions caught up faster (except the closed source ones - they have no motivation when ubuntu works, so why bother) than figuring out how to handle several displays with different dpis under X11 so that legacy apps not using modern Gtk/Qt work.
If it really was intentional, a small dialog or log that explains _why_ I couldn't scale monitors differently would have sufficed, or, simply moving the percentage adjustment control out of the settings for each display.
On that note, 20.04 is supposed to support fractional scaling, but if I try to turn the toggle on, it just fails silently, so are we back to square one, or did a developer somewhere decide some precondition means I can't _currently_ turn it on, but didn't feel it was worth telling me, the user, why?
In the past, when it wasn't exposed in GUI, and worked for Wayland only, it was necessary to logout and login between enabling fractional scaling and setting the scale itself (the reason was, that Xwayland was started in different mode then; technicality, that doesn't matter no normal users, but then, the functionality was labeled experimental and enabled via gsettings anyway).
The X11 fractional scaling is a different beast; it uses xrandr scaling and requires cooperation from the graphic card (the output encoder, specifically - it sets up framebuffer at different size than the output to display). That also means, that it won't work on machines that do not have output encoder at all and assume framebuffer resolution is equal to output resolution, like remote sessions or virtual machine clients. Here I agree, that some error message would be appreciated. It was also brave from Canonical to enable it for LTS, without going through a testing cycle in a non-LTS release.
There is system76 with "Pop OS!" but I would like to see a company who's entire focus is on release a very slick OS _only_.
By all means make the OS downloadable separately, share with the community and all that, but to make a profit, you need to sell hardware. And the hardware needs to be good.
So I am about to start a new job, and the new workplace was about to send a new Macbook Pro out to me, which I didn't want. So I went to do some research for a laptop with any Linux distro preinstalled so that I could go back to them and tell them I'd rather have this.
I found out that there is no decent laptop with Linux preinstalled. System76 has some decent systems, but they didn't come close to what the likes of Dell and Lenovo offer with Windows. For now System76 seems to show most potential in this area though, so it will be interesting to see what they do going forward.
Lenovo's upcoming ThinkPad laptops include some models with preinstalled Fedora as an option:
The announcement regarding Lenovo's upcoming ThinkPad laptops coming with Fedora pre-installed came a literally 1 or 2 days after I'd already ordered the P1 Gen 2, which according to Canonical is certified[0] to run Linux correctly, and it's the reason I went for that. Regardless, the next generation would have left me without a laptop for the job.
I'm sitting here with a 4k 32" monitor and a 1920x1200 24 inch side by side, scaled perfectly so both are pretty and readable, in xfce, and when moving things between screens nothing changes size, or re-renders weirdly, or can't be resized due to invisible boundaries, or ...
It's better than windows or MacOS can manage with the same setup.
I'm not sure what you count as 'proper', and yes I had to write a two-line script with xrandr commands so ease of use isn't massively present. But the underlying system absolutely has great scaling support.
Graphics drivers are also fine these days, I've not had any problems with my mouse either. Hardware in general "just works" better than windows these days, with older devices supported and no drivers to hunt down on the web.
I'm not trying to claim it's better for you, only you can decide that. But it works great for a lot of people.
You didn't understand the problem mentioned by GP. Neither of your monitors requires HiDPI scaling. Your first monitor has approximately 138 dpi and the second a paltry 94 dpi.
Compare that to a 2012 MacBook Pro that has a 15.4-inch display with a 2880x1800 resolution. That's 221 dpi. The hallmark of a HiDPI is that its DPI is so high that you need to render UI elements at 2x or more (though sometimes 1.5x also works), so that originally a one-pixel line becomes two pixels wide. This requires support not just in drivers and the OS, but the application. ArchLinux has an entire wiki page discussing application support: https://wiki.archlinux.org/index.php/HiDPI
I beg to differ, 4k/32 does need scaling to my eyes. I don't want things to be that tiny.
Not every application needs to support scaling, so long as the GUI framework they use does, and the window manager does (XFCE has support, which I have activated) that makes the 4K screen more usable to me (while allowing the full res to be used for smooth rendering), then I use xrandr to scale the lower-dpi screen back down so elements are the same size across both. Sure, there are a few apps that don't behave brilliantly, but they aren't things I use much.
Like I said, it works better for me than MacOS or Windows (I have both, and a 2103 Retina MBP I still use).
For stuff like this, Linux is bullshit. For many desktop usecases, Linux is bullshit. After a Skype call I need to kill the app else the process takes my CPU usage to 100%. Why? God knows. Probably the same reason my lock screen sometimes shows a password prompt when I press 'Esc' or 'Enter' and sometimes it requires me to click the mouse. Did I mention I spent the last nine months without a working microphone because the drivers for my new Thinkpad hadn't made their way into any major distribution??
Don't get me wrong. I love Linux. I'd take its broken ass over Windows any day of the week. But fuck me if I don't miss macOS.
Pretty sure it doesn't :) That '1200p' screen I have certainly isn't in need of scaling for usability, but I have scaled it to match the size of screen elements on my 4k screen next to it.
I've been going back and forth between MacOs and linux a lot lately, been using my Mac as my work laptop for the last couple of years, now that I'm working remotely 100% I figured I'd switch over to linux. Honestly not having much issue with it, bar the odd "Teams has decided it can't use your headset microphone, for reasons" error.
Never even heard of Dia, let alone had call to use it. Just installed it and yes, for unknown reasons it doesn't seem to scale does it? Which is odd given it's presumably a gtk3 app and others do scale just fine. Looks like GIMP is another one that's not onboard yet.
My daily use at the moment is IntelliJ, MS Teams, Skype, Firefox and Steam. I guess gedit, meld and a few other utilities. They all seem to be fine. Perhaps my relatively constrained set of requirements is why I'm happy with it.
It's been years coming but it's getting there: https://gitlab.freedesktop.org/wayland/wayland/-/merge_reque...
Linux touchpad like a Macbook: progress and a call for help (Mar 2019) https://news.ycombinator.com/item?id=19485178
Linux touchpad like a Macbook: goal worth pursuing? (2018) https://news.ycombinator.com/item?id=17547817
NOTE: I should've read the 'WIP' comment at the top before posting this. Sorry if I shared this early!
> - Has access to a modern Linux laptop
> - At least a couple years experience with C/C++
> - Proven track record of delivering projects on schedule (please provide examples)
> - Strong English skills
> - Self-starter, able to make progress toward high level goals with minimal oversight
> - Positive, solution-oriented collaborator
> - (Preferred) Has personally struggled with Linux touchpads.
These requirements are much much lower than majority of programming job descriptions out there...
I don't know if OP has actually fully noted the requirements, but the point of this job is to work on improving gestures in Linux and that's all. If these requirements are all that's needed then that's it.
Oh, and also from booting the same Dell XPS laptop in Linux and macOS, guess which trackpad experience is superior.
3 and 4 are more like a tie.
On macOS, when I move the cursor with the trackpad, it’s almost intuitive for me where the cursor is going to end up. With Linux, it’s almost always an uphill struggle. Like the acceleration curve adopted by Apple is more ergonomic.
If it works reliably you could have great hardware with a good OS and a decent price.
A MacBook’s trackpad hardware is differentiated because it is covered in glass, larger than most trackpads by a lot, and it clicks using a force sensor + haptics (so it is more reliable / has an even click across its surface).
It’s the one thing that’s keep me on the Apple platform for almost 2 decades now.
I encourage looking at the earlier discussions since much has been talked about this before.
Having used Gnome 3 with Wayland and libinput (the best Linux trackpad experience at the moment) until last year, I can say that while the latency and acceleration curve are definitely not there, at least the animations are better implemented than those of Windows 10
See this small section in a very long and detailed blog: https://pavelfatin.com/scrolling-with-pleasure/#mac-os
Also, it rubs me the wrong way that the blog author is seeking a person to do all the dirty work — even for compensation — and then what? Have all the credit? Basically, act as a glorified Forward button?
If I felt up to the task enough, I’d slap a sponsorship button onto my github on my own. And here’s the difference: prior to asking for the money, I’d have something to show to prove I’m not a phony.
The upstream is not without its problem as well. Right now it’s being maintained by Peter Hutterer from Red Hat, and judging by his LinkedIn, it’s pretty much his job description. Recently he did a talk about how overloaded he is with libinput[1], and how someone volunteering to comb through pull requests and issues would easily become his “number two”. Which also is striking me as odd.
libinput, given its importance for Linux ecosystem as such in general, and Red Hat ecosystem in particular (especially since they bet on Wayland as the future, and there libinput is the only choice), is important enough that Red Hat better make sure it’s well maintained. It’s Red Hat/IBM, really, who should be interested in making sure the bus factor of libinput is > 1. Thus the problem should be raised within Red Hat’s management, and they should _hire_ additional people for fair buck to help. Otherwise it looks as if someone who’s paid for X input stack maintenance is seeking free labor to help him.
If I asked someone to help me do my paid job for free, open source or not, I don’t think it would even be ethical.
[1] http://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1....
However, I think the tracking may change slightly with major MacOs releases. So which version do we prefer..?
On the other hand touchscreen is really disappointing on Linux (Ubuntu), just not a smooth experience at all for me.
I get the same feeling with high vs low quality touchscreens (e.g. my phone vs some ATMs), and especially with gaming controllers. With a good, ergonomic controller I sort of forget about the shape and weight of the controller in my hands after a while; my entire sense of it narrows down to the buttons/triggers/joysticks.
Last time I used Linux on my MBP, libinput was more... linear.
I’d love to contribute to this project, but I’m not sure how.
Nowadays I work mostly at my desk, but for several years I've worked 90% of the time on my laptop keyboard. Synaptics with a bit of customization (Area*Edge size for palm detection, single and double tap timings) worked extremely well, and I consider myself very picky.
Edit: this seems to be about libinput, in which case I understand, as the two times I've used libinput I gave up after a few hours of intense frustration
Nothing beats a he MBPs trackpads. I’m not sure what it is exactly, but I feel that on Windows the cursor drifts, when I lift my finger. On Linux I feel the trackpad is very sensitive (I get more cursor jumping around).
Also, on both Windows and Linux it just feels like they are less precise.
I guess it is the ‘it’s hard to explain’ factor that makes it hard to replicate?
I’m not due how it is in Linux, but last time I tried running Ubuntu on my 2017 MBP, It wasn’t possible to move from edge to edge in one swipe.
I’m in the opposite camp. I’ve been using a Linux laptop at home (by choice, obviously) for the last 5-10 years and have finally been able to setup a Linux-powered workstation at work.
It feels so refreshing and liberating. I can’t imagine ever going back.
So for those of you frustrated with the Linux touchpad driver... what is the problem? Or is it just that it's not the same (which is a completely valid complaint, IMHO)?
Just all round it wasn't very pleasant to work with. Perhaps if you have been using trackpads on Linux all your life, you are used to moving your hands away from the trackpad when not in use -- and so accidental presses are maybe never an issue for you.
As an exclusively Linux user, my only real issue with touch pads is palm rejection, I feel like it has never worked so I end up in all sorts of awkward hand positions trying not to tap it by accident.
As a 6ft4in male (with the large hands to go with it) it becomes painful when trying to do this for any period on my XPS 13. On the XPS 15 it's easier because there are large enough spaces either side of the touchpad to rest my palms.
Plus, with how the T2 chip is going you might not even be able to boot Linux on a Macbook in a few years.
The trackpad is extremely responsive. The "click but it's not a clickpad" feature they have is perfect.
Combine that with the responsive, intuitive and really great gestures that aren't event based, but rather they are smooth gestures that can be turned back and undone. Compared to something like libinput-gestures which captures the gesture and then triggers a shortcut of some sort at the very end.
I find it hard to explain. The trackpad doesn't feel like it's in the way. It feels part of you once you understand and get used to the gestures.
Since macOS uses GPU-backed windows all interaction animations run highly responsive at 60fps. Scrolling through a webpage or navigating to another windows with 'expose' or just swiping between workspaces is really instantaneous. Also, try swiping 'back' in Safari and you immediately see the current page moving a bit out of the way, exposing the previous page. If you decide you don't want to go back you just let go of the trackpad and the action reverts.
Applications implementing their own rendering (Firefox/Chrome and other non-native toolkits) do not have that quality consistently.
Same hardware with Linux or Windows 10 feels completely different. Windows profits from GPU optimisations, but the UI situation is a mess. Every Linux distribution's GUI (X11 _and_ Wayland) I've worked with has even more noticeable lag between user input and output.
Fuck touch pads and hidpi monitors. They're honestly dumb. Who wants to work all day on a laptop? People who optimize their equipment for working in meetings or working on the move are doing it wrong.
No wonder Silicon Valley is a bubble of Mac users. They're concerned with all the wrong things, just like the Mac OS UI or any other OS that has been tainted by its influence.
So, some can make it work.
My frustration with MacOs is, mousing around to all four corners of the screen constantly. They've separated everything into the corners. But with a touchpad, less frustrating.
Think the best we can do for now is to give a star to https://github.com/gitclear/libinput although it doesn't feel very significant.
> I presume nobody is randomly visiting pages on bill.harding.blog, so you aren't seeing this.
FeelsBadMan.
How many touchpads expose the raw touch data (ie. A bitmap of capacitance data) necessary to replicate macos gestures? Things like palm detection absolutely require that.
Is the project worth it if it only works on one model of hardware?
So, I have good hope that Linux users will enjoy this experience also one day. Microsoft forces the vendors in it.
If this setting isn't there, try setting that option in your xorg/libinput configs.
Touch to click is more or less as old as the idea of a touchpad.
I beg to differ, Bill.