Linux touchpad like a Macbook: progress and a call for help
public.amplenote.com
public.amplenote.com
A simple test which Macbooks pass, but Windows and Linux laptops fail: fling scroll down a web page, then press Cmd/Ctrl+W to close the tab before the fling scroll has stopped moving. On Macs this works correctly; everywhere else, it acts as though you're spinning an old-style wheel mouse while holding Ctrl, and zooms in repeatedly.
Which is the proper way to do it.
Other vendors wanted to emulate macOS’s inertial scrolling but they had to stay compatible with all sorts of legacy APIs that only knew mouse events, so some of them cut corners and started sending these fake mouse events from the driver, to be the first on the market with “macOS-like scrolling”™.
Of course this is very much a bolted-on solution, which leads to all sorts of nuisances like what’s described in the parent comment, and contributes to the general sad state of trackpad behaviour on Windows and Linux.
They’ve pretty much cornered themselves, because fixing it would require a coordinated effort from the hardware/driver vendors, the OS vendors and the UI toolkit vendors. It’s just unlikely to happen unless you own the whole stack like Apple does.
You can’t abstract away gesture processing because it’s deeply intertwined with the UI logic. Inertial scrolling, rubber band effect, concurrent gestures with complex exusion rules between them, etc. If you try to abstract them away from the UI library, you’ll end up with a bloated meta-toolkit that still won’t cover all use cases, and is inflexible and prone to ossification.
But I generally agree with you. It's up to client/toolkit to handle complex gestures. However, even Apple abstracts pointer movement and scrolling on input level, and that abstraction includes inertial scrolling. Rubber band effect doesn't really interwine input with UI logic (it can easily be entirely encapsulated in the widget itself) and for other gestures you're going to use some gesture-specific API anyway. The scrolling inertia is a function of the input, so the proper place to calculate it is on the OS side, not in the client/toolkit - it can be in toolkit only when the toolkit itself is a part of the OS. You don't have such toolkit in the GNU/Linux land.
Without Force Touch-like trackpad hardware, other laptops are still too far behind.
It's a great solution, but it just doesn't solve any problem I have. I'd rather have a scroll wheel.
I expect I'm not the only person in that situation and it's great if more effort goes into trying to improve the trackpad experience of linux on a laptop!
Done by holding a button that doesn't exist, but which you forget isn't there. Cos the driver is that good.
I prefer being able to scroll horizontally and vertically, zoom in/out and rotate on the spot. There's no question the multitouch model is more expressive, but we're all gimped by mice.
I'd view it as feature that is usable when the hardware and drivers are done well and just miserable when they are bad - the possibility of your typing and your mousing getting in each other's way seems to increase with every generation of laptop form factor, with more gimmicks needed to stop it (oddly similar to the 737 Max problem - reading the edge of software compensation).
What it doesn't do is haptic feedback when it's turned off. There's no click. I infer that's because the click works by applying a mechanical kick back close to the point of deflection. Your finger wouldn't feel it as a click if there was no mechanical movement at all. A bit like a speaker: speakers are mechanical devices too.
https://ifixit.org/blog/7084/force-touch-track-pad/
> we’re pretty sure the magic pressure sensors in the new Force Touch trackpad are tiny strain gauges. Mounted on flexing metal supports, they detect the amount of flex on each—and based on that, the force from above.
Flexing = movement.
Other specs: Acer VN17, Windows 10, Chrome
I think it's because it's using the much more polished Windows 10 touchpad driver instead of the crappy synaptics one.
The touchpad drivers and input stack have come a very long way in Linux, if (BIG IF) you're running well supported hardware.
I also haven't heard from anyone with connections to OSS projects at Google/MS. I've assumed (perhaps incorrectly) there are departments at smart tech cos that selectively contribute to high impact OSS projects (dev resources or other)? Even if not for contributing resources, would be valuable to get a bit of talk time from those that have successfully executed a project like this before.
Thank you for your efforts. Could you explain what exactly is better about the MacOS touchpad?
Just to warn I've used Linux on a cheap PC notebook for the last ten years. I have only very occasionally used a macbook and generally found the touchpad unpleasant due a relatively slow movement (which also might make it more accurate but still doesn't enthrall me). I never particularly had a problem with the touchpad until recently - the current drivers get the location "lost" and needs a reboot about once a week (unloading and reloading with modprobe doesn't work. Also, the current touchpad simulates a three button mouse on a pad with no visible buttons, an effect that generally makes both the center and right buttons hard to use plus the keyboard has no right click button, complain-complain, minor stuff altogether and machine remains usable).
Which is to say that you may be confronted with continual Linux desktop problem the your ideal of UI performance not being everyone's ideal (remember how everyone hated on the Gnome Shell? I still hate on the Gnome Shell). My own idiosyncratic UI ideal is more like older-Windows than Mac (I use Ubuntu Mate).
Still, best of luck.
But I wanted to point out that this is a spot to be careful about decisions. The natural choice is to pick a default that you like yourself, but that's probably a choice that would ultimately hinder adoption of Linux as a desktop OS.
Geeks like a faster setting, but geeks also universally know that this sort of thing can be customized, and can easily figure out how to change it. Non-geeks are more likely to find a fast setting to be frustrating or unusable, and are also less likely to know that they have an option to slow it down.
Any way to keep up to date on this? (And really only this, no newsletters or anything, I hope you understand.)
I'll also setup an easy means subscribe to text updates about this project soon. Check https://bill.harding.blog for updates on that.
https://www.omgubuntu.co.uk/2018/09/google-working-on-apple-...
Let's get him some bounties! :)
The reason for this is they've presumably implemented plenty of other stuff without being paid to. There's no information given so far to suggest otherwise.
Absolutely no insult to that author though. They are entitled to choose to work on whatever they care about.
You gave up on libinput after an inability to configure scroll speed, but the rest of those are all configurable with libinput and libinput-gestures[1].
I don't use gestures yet and default scroll speed has always been fine, and the following tiny libinput configuration hits the rest of your points.
$ cat /etc/X11/xorg.conf.d/30-touchpad.conf
Section "InputClass"
Identifier "touchpad"
Driver "libinput"
MatchIsTouchpad "on"
Option "Tapping" "on"
Option "TappingButtonMap" "lrm"
Option "NaturalScrolling" "true"
EndSection
Is there a reason you haven't asked the libinput maintainer about whether configurable scroll speed would be welcome upstream (in the prior post, it comes across like your question was far more open ended)? Forking it just to add scroll speed configuration and replicate work that's already been done elsewhere seems a little excessive.As far as the broader configurability questions, it's not so much that I want options libinput doesn't have (though that's a little bit of it).
It's more that I want the default behavior to be good enough where accessing the options aren't necessary (e.g., Macbook). In the event that the default options aren't that good, I want visual settings to tune the experience. Gnome 3 with libinput currently provides two options. Neither is pointer acceleration.
Since much of what I hope to improve the "feel" of default behavior, I don't think this could be as straightforward as "submit a PR to libinput." I think it could end up being a lot of work to get the default experience feeling great. The number of folks with interest in this esoteric subject seems to me like evidence of that.
The purpose of the fork cannot be just to provide sane defaults.
Pretty sure that's what the libinput developers want, too.
1. https://developer.apple.com/documentation/appkit/nsscrollvie...
2. https://gist.github.com/zwaldowski/8710fddc8b0b39d2c152#10_9...
1. https://hacks.mozilla.org/2016/02/smoother-scrolling-in-fire...
2. Original article is broken but this is good: https://danluu.com/latency-mitigation/
I had done some investigation on this before. After all, if System76 is open software and hardware, I should be able to get an add on right?
Not so fast. It seems part of what makes the Mac touchpad so good is a combination of software and hardware.
Microsoft is taking a stab at this. What they had been doing was treating touchpads as a mouse device ... but the hardware gives hints on gestures, so they have been improving their drivers to allow for better experience with the touchpad. (Rather than emulating a mouse device using a touchpad).
The hardware is a bigger block. Apple holds key patents on their touchpad, including the use of textured glass. The glass gives the experience a different feel, but I bet it also smooths out the signals being sent to the software driver. I don't know for sure -- but even say, my Samsung Chromebook, which has a decent touchpad, still doesn't feel the same as my Mac's touchpad.
https://appleinsider.com/articles/13/05/14/apple-wins-utilit...
"More importantly, the patent calls for, in one embodiment, a capacitive track pad with an etched glass surface. Because of its unique properties, and its non-conductive nature, glass allows for high levels of control during the manufacturing process."
"For example, traditional glass has a surface with a high friction coefficient, meaning it resists slippage, making it a less than suitable candidate for trackpad use. However, glass can be made to have a low friction coefficient by etching, sand-blasting, honing, or other methods. This makes the surface smooth and easy to navigate with a finger."
https://www.howtogeek.com/286905/what-is-a-precision-touchpa...
"Traditionally, Windows PC touchpads were implemented in a more one-off way. When you moved your finger across the touchpad, the touchpad driver has to look at the input and convert it to mouse input. The touchpad appears as a normal external mouse—either a USB or PS/2 mouse—to Windows itself. PC manufacturers have to tune the touchpad for their hardware, and the driver is responsible for handling the input. If the touchpad uses multi-finger gestures or has palm rejection support so you don’t accidentally move the cursor while you’re typing, this all has to be implemented by the touchpad driver."
"Microsoft decided to move towards a more standard approach starting with Windows 8.1. It created the “precision touchpad” specification along with touchpad company Synaptics. A PC with a “precision touchpad” doesn’t do all the hard work in its own hardware drivers. Instead, it sends the raw touchpad data to Windows itself. Windows is responsible for reading the input and processing the gestures. Windows understands your PC has a touchpad and approaches it intelligently. The touchpad doesn’t just pretend to be a normal mouse."
In my very obscure case, I got lucky in that suspend was working, then stopped working after a kernel update. Since it was a regression, kernel developers were more interested in tracking down the problem and I was able to find a work around: write PWRB to /proc/acpi/wakeup
The gory details are here, which I expect is so obscure it's not your problem, but shows as tedious as it is, filing bugs with a decently good bug report and willingness to do the work devs need you to do can be worth it. https://bugzilla.kernel.org/show_bug.cgi?id=185521
XPS13 which I have is one of the most widely used linux laptops, and it a symptomatic that it doesn't work well.
https://ubuntu-mate.community/t/xps-13-9370-wakes-from-sleep... and
https://askubuntu.com/questions/1029474/ubuntu-18-04-dell-xp...
In addition, I always use a pre-sleep script that disables bluetooth. And enables it afterwards.
Hope it helps!
Would those same logs help me debug my issue too?
I've had an XPS 13 9360 for two and a half years now, and an x230 for roughly four years before that. Before then it was a range of cheapo laptops, and while the touchpads and keyboards sucked, sleep mode was fine starting in the late aughts.
I can attest that it took a little while for sleep mode to function at all though. It was a non starter (not intended) in the mid 2000s, but the problems you describe has never been a problem I've had.
As you mentioned, Linux runs on hardware made by hundreds/thousands of different uncoordinated manufacturers. Mac OS runs on a very narrow range of hardware built by the same manufacturer that makes the software. Linux is a very different project to Mac OS.
So take the best examples of Linux machines and compare those with Macbooks. So if eg. Dell XPSes or modern ThinkPad X series have solved the sleep problem consistently then it's fair to compare those with Macbooks.
Of course this doesn't help those people who have trouble with sleep on Linux and hopefully it will get better... but comparing a broad elastic OS running on a vast mess of thousands of different devices with an OS designed specifically for a small range of tightly controlled hardware isn't reasonable. It would make more sense if there were no good examples of decent Linux machines, but this isn't the case.
In fact it shows that they don't at all get the point you've made that Linux runs on orders of magnitude more hardware variants than macOS does and thus it should be obvious that all hardware can't be equally well supported.
From https://github.com/JackHack96/dell-xps-9570-ubuntu-respin/is... from https://github.com/stockmind/dell-xps-9560-ubuntu-respin
What works out-of-the-box: Sleep/wake on Intel
What does't work properly: Sleep/wake on nVidia
I recall the issue is something to do with the chip that switches between the two video outputs?
There are more knobs to fiddle with, naturally, but the desktop Linux experience has vastly improved over the last few years, and I'm happy enough with it that I don't see myself willingly going back to OS X or Windows as my primary anytime soon. My desktop feels like the synthesis of all the things I like from both Windows and OSX, with the added benefit of an actual package manager and first-class support for all my development toolchains. The amount of time my coworkers spend fighting oddities in their brew installs becomes really apparent when I'm not fighting those battles.
The hardware (particularly) touchpad is the single biggest advantage Macs have left. I use a mouse rather than touchpad, but if the touchpad is solved, I'd have nothing I'd say that OS X does better.
* Touchpad
* Sleep mode
* USB-C display
If I can't trust that my laptop will go to sleep when I shut the lid and put it in my bag, it's not useful as a portable device.
Then at some point they fixed the issue, which if I remember correctly came down to "stop trying to be fancy and just do the straight-forward thing, which is correct". And since then I've had no issues.
I'm unclear why I had an issue with the Thinkpad but never had issues with any of the 5 or so Dell Inspirons I've had over the years.
Sleep mode. It's failed on my a couple of times in the last year, but my Macbook Pro failed about as often. I'm not sure what the issue is here.
USB-C display. Using one right now. Got a USB-C hub plugged into my Xiaomi Air that is providing it with power, keyboard, mouse, HDD and display. What is the issue you're seeing with this?
My Dell is running Ubuntu 18.04 LTS. Xiaomi Air is running Linux Mint 18.3 Sylvia.
meanwhile the sleeping t470s drains the battery by keeping the RAM alive and eventually runs out. the arch wiki has some content on this, but it did not make me hopeful to get it to work
systemctl hybrid-sleep
And configure it as the lid close action trough logind conf (or your DE's).
It works differently, though (AFAIK). It saves the state to both RAM and disk, so when battery eventually runs out, you can resume from disk. The solution you offer seems interesting. It would just need a RTC wakeup event, so that the system goes all the way to S5 after a set time.How's the battery life? I used to use Linux as my daily driver until about 2015, but grew tired of replacing batteries in laptops that weren't made to have their batteries replaced.
For non-physical features, I don't really notice any difference, since a full-screen terminal SSH client and Chrome window are the only things I ever run.
How much raw data is sent from the device to the computer? Or, to what extent is the information preprocessed before sending?
I could see palm rejection being implemented either in hardware or in software. When a user's palm is resting on the pad, there's a large area of slight capacitance change (i.e. hand is either just barely in contact with the surface, or very very close above it), which is not normal when the user is intentionally dragging their fingertip across the surface.
Does the touchpad report a real-time capacitance map across the whole surface? Or does it do some interpretation onboard and send to the machine what it thinks are the separate touch points and pressure values for each?
See:
https://github.com/jnordberg/FingerMgmt
https://web.archive.org/web/20120323025118/http://www.steike...
I haven't had time but should try to open-source whatever bits I've had over the years when I was bootstrapping thimblemac.com
previous hn discussion on this: https://news.ycombinator.com/item?id=17547817 (where I also commented here: https://news.ycombinator.com/item?id=17551984 )
I haven't kept up with the windows ecosystem to look into the 'precision touchpad' data, assume it's something similar just delivered ~8 years later.
One thing I found interesting is you can purposely trigger the palm detection by doing something like putting your finger above the trackpad on the edge and running it slowly down.
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
For testing, you don't have to install if you don't want. I suggest installing the latest Fedora 30 beta test candidate. It's more reliable than Rawhide, and yet has the latest libinput so you won't be asked to build a newer version from git. Download the workstation live file, image to a USB stick, and do the testing from the live environment. Software installation is supported, it uses the RAM overlay.
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1...
While it's tedious to have to file such detailed bug reports, they make it pretty straightforward to figure out what is needed and how to get it. The devs have no way of guessing what the problem is. Plus, the fix eventually finds its way to all distributions, so people just get the fix rather than you having to maintain a local hack.
https://wayland.freedesktop.org/libinput/doc/latest/reportin...
I don't have the time or the skill to hack on most open source software, but I do file detailed bug reports, feature requests, and documentation updates whenever I run into an issue.
"It ain't much but it's honest work"
Then again, when a relative ordered one of these laptops, the mousepad was dead on arrival, so ymmv.
At any rate, I'd be curious to know if libinput is your driver in use? If you don't know, `cat /var/log/Xorg.0.log | grep "input driver"` should indicate the answer
I caution you against using just my anecdote to determine anything concrete, of course.
I've got a 2011 MacBook Pro and a logic analyser, which I'd be willing to use for a bit of touchpad driver testing/development. But, it seems like the missing link is a way to generate consistent signals that cause problems on Linux but not MacOS - I cuss my XPS15 w/ Ubuntu daily, but haven't figured out how to intentionally generate the touchpad issues.
Will try to make a test jig that consistently triggers one of the irritating behaviours, but my touchpad R&D period (aka conference call) is wrapping up, so it'll be a while.
I am guessing that touchpads use similar tech.
A fun fact is that capacitive sensors such as the one used on touchscreens are fully 3D-capable, but that seems to be rarely used (I've seen it once or twice on Samsung phones, and Sony's "glove mode").
I really, really hope that this project is successful.
I would argue that it is less a quality issue, and more that experienced GNU/Linux users tend not have a strong preference for touchpads. There's no collective desire to improve them.
Away from my desktop (where a touchpad is irrelevant) my X200 doesn't even have a touchpad. I have an X250 thinkpad with touchpad, but it sees minimal use and performs just fine. I tend to use it when the laptop is at arms reach and it's easier to select a file that way than lean over and use the keyboard.
When I'm working I use i3wm (tiling window manager) and most GNU/Linux application make huge use of keyboard bindings. Using a mouse, or worse a trackpad, is massively inefficient.
'OMG, I wish my new MacBook Pro enormous trackpad functioned better when I'm using Ubuntu' is not a phrase I hear often.
It has a "multitouch live view" debug window that displays exact pixel touch locations and shapes.
The homepage showing this (third screenshot) is here: https://blog.boastr.net/
That said, I don't know if your request will be quite fruitful. It comes across as too "I'd like to run this project if you want to help out and here's how we will run it". Instead, I think what you need to do (if you could) is start the technical work yourself and get others to help out.
If I knew how to fix the touch pad issue, I'd probably just do it independently or else find someone else technical who can help out and we could do it together. I wouldn't be looking for a PM (and the timeline or project plans is kind of a turn off for a side project). Anyway, I hope you're able to find someone who can help you out.
I so wish that I had the time to start the technical work myself. But I'm currently experiencing the misfortune of trying to run three products at the same time for my day job (as a CEO/developer).
But I care about touchpads (or at least, not relying on Macbook) too much to do nothing. So even though it sucks that I can't just make time to work on setting up the project myself, at least this effort holds the possibility that like-minded folks will join me to make that happen.
Would it be possible to emulate touchpad input? Maybe see if you can record enough touchpad data on macOS to be able to make a replay driver on Linux, or maybe with an arduino emulating a touchpad with synthetic input.
That way, testing could become a set of test cases along the lines of "given this input and a cursor at position 0,0, the cursor should end up at position X, Y", and you'd be able to see how big the current error is. A bunch of those tests with various recorded movements should be a lot more stable than a human test.
When I go to the nearest computer store all I see is shitty 4cm-wide black plastic stuff with a depth of easily 2mm. The plastic will get "shiny" from fat fingers (dito for the keyboard), and the tiny-ness makes any kind of gestures ... weird if not impossible at all.
Edit: oh, you said affordable. I think the answer is probably "no" then, but macbooks are not cheap either. These dells are comparable in price to macbooks.
I've never tried Linux on a MacBook, but those must be some really bad drivers. I used my trackpoint on the same size/difficulty settings and scored 160. I'd probably do better with practice.
Or a really bad trackpad. It's not just the drivers.
>I used my trackpoint on the same size/difficulty settings and scored 160.
Still nowhere close to 250.
Right, but I was using a little nub on my keyboard. I don't expect it to be as good as a trackpad.
Asking because clicking on them here doesn't seem to be registering. eg I can click the buttons to start/end the recording session, but clicking on the dots does nothing. Score of 0 at the end.
Then again, I'm super tired so could have missed something super obvious. ;)
Not to say that others won't be better at the game than my control runs, but I think that's going to contribute to some pretty high variance among ad hoc results reported here.
250 doesn't seem to be anything to write home about, but I get the feeling the limiting factor is not the trackpad / trackpad drivers (so comparing users doesn't seem to make much sense).
I'm all for improvement, but it doesn't seem that bad.
[1] https://docs.microsoft.com/en-us/windows-hardware/design/com...
-- someone carrying a mouse or using the red thinkpad button thingy since 2004.
I can't donate dev time but I'm happy to donate testing time and to throw in some cash too.
I'm using both the integrated touchpad of my Lenovo Yoga 2 Pro (produced in 2014) and Apple Magic Trackpad 2. The former with xf86-input-synaptics driver, the latter with libinput. My partner has a MacBook Pro which I sometimes lend to test some stuff on macOS. Overall my touchpads on GNU/Linux feel somewhat better; macOS however wins when it comes to application support and integration. I've tried Windows once on my Yoga and it was completely unbearable.
IMO the main thing GNU/Linux needs in this regard aren't the drivers. libinput will get there eventually (it improved a lot over past few years; initially it was pretty much just as unusable as Windows). The main thing that's dramatically needed is application support. You get an absolutely awful touchpad experience with Firefox on X11 until you set MOZ_USE_XINPUT2=1 environment variable, for instance. However, if you enable it, there's a bug somewhere that's triggered by KWin[0] that sometimes makes scrolling unbearable until you refocus the window. I don't even have to mention missing out-of-the-box touchpad gestures support and the fact that macOS implements them smoothly (say, the transition progresses exactly as you move your fingers), while all of the solutions I've seen on GNU/Linux work as simple triggers.
Let's back it up with some data. I've never seen mouseaccuracy.com in my life before, fun stuff. Tried it with the same settings as the author ("hard", "small"; for 30 seconds):
Yoga 2 Pro touchpad on GNU/Linux (synaptics): "TOTAL SCORE: 345; TARGET EFFICIENCY: 69%; CLICK ACCURACY: 96%"
Apple Magic Trackpad 2 on GNU/Linux (libinput): "TOTAL SCORE: 299; TARGET EFFICIENCY: 63%; CLICK ACCURACY: 87%"
MacBook Pro 13 Mid-2012 touchpad on macOS: "TOTAL SCORE: 286; TARGET EFFICIENCY: 58%; CLICK ACCURACY: 93%"
Apple Magic Trackpad 2 on macOS: "TOTAL SCORE: 262; TARGET EFFICIENCY: 56%; CLICK ACCURACY: 82%"
It was definitely harder to do those fast clicks on the Magic Trackpad, because it only emulates a clickpad, while all the other touchpads can be physically clicked (this is a feature that actually made me buy the Magic Trackpad as it makes it exceptionally quiet, but it doesn't really help with accuracy and agility). When it comes to "personal feeling" during the game, the Yoga touchpad handled by synaptics driver definitely felt the best, while all the other runs felt kinda similar (libinput won with macOS in numbers, but I didn't really "feel" it).
TOTAL SCORE: 302; TARGET EFFICIENCY: 63%; CLICK ACCURACY: 89%
The result is very similar to Magic Trackpad's one, although the movement "felt" a bit better (OTOH, the clicking was slightly awkward after all this time of using clickpads).
I forgot to mention that Magic Trackpad 2 got a bit handicapped due to Bluetooth connection, as I'd have to find that damn Lightning cable in order to test it via USB. But it's meant to be used over Bluetooth, so...
TOTAL SCORE: 386; TARGET EFFICIENCY: 80%; CLICK ACCURACY: 89%
Am I the only one who uses a mouse whenever possible, no matter how 'good' the trackpad is?
The Logitech Master Anywhere 2s (the smaller version of the mouse I used above) is very portable, very accurate (even on glass), has excellent battery life and works well with bluetooth. It really isn't much of a hassle to bring it along anywhere you go.
TOTAL SCORE: 574; TARGET EFFICIENCY: 91%; CLICK ACCURACY: 98%
I would definitely use a mouse over a trackpad; in fact I have an IBM X60 but it is not on hand at the moment, and I'd rather use the "clitmouse" on that than a trackpad. All the trackpads I've tried, including the Macbook ones, induce an unpleasant sticky feeling on the fingers.
googling returns no results apart from a forum link from 2013 about quake
For me, touch gestures trump accuracy. I had some Logitech thing with a million buttons all mapped to different actions, and I never managed to get mouse gestures (in Opera at the time) to ever be effective.
Certainly it's a matter of personal choice though, everyone does what works for them. Lots of people swear by only using a keyboard too.
The only issue I have is that it's too conservative about starting to recognize gestures. On macOS, you can quickly transition from scrolling to pinching/rotating and it knows what you want. On libinput, you have to very deliberately stop scrolling, put two fingers into a pinch position, and start pinching.
I don't usually run Linux on it, but I have, and I don't recall it behaving any differently than it does in Windows. Maybe the pinch gesture doesn't work in Linux; I'm not going to reboot to test.
particularly the physical clicking. It got progressively harder to click as you moved up from the bottom 1/4 of the touchpad.
* The touchpad doesn't feel as smooth as the Macbook Pro (despite it also being glass) -- there's some sort of matte finish which gives it a more rubbery finish.
* The gestures are less accurate (I frequently activate 3-finger gestures despite only using 2 fingers).
* The buttons at the top are harder to use than buttons on the bottom.
* You can only click the touchpad on the bottom half.
(spoiler: it a good touchpad, but not really exceptional)
How does the phrase "pragmatist at heart" relate to "Good Old Grateful Dead" and what is "Good Old Grateful Dead"?
edit: this isn't a joke
A task for a logic analyser as much as for software dev.
I have taken a look at the libinput-debug sample code and my main DE (Gala, written in Vala, which is a frontend for C), with the resulting opinion that for someone decently-experienced it should be fairly easy to do. Unfortunately I am not that person (yet).
You may be (and I agree on gestures), but I'm not. Apple's touch pad is literally the only thing that keeps me using a Mac.