How much of PC laptops' touchpad quality is due to hardware limitations? I seem to recall back when I owned an Apple laptop (circa 2010) that its trackpad was connected internally via USB. Meanwhile, PC touchpads almost universally used PS/2 which provided far lower bandwidth. Is this still the case?
Yes and no. Some trackpads are connected over actual PS/2, but others via the EC and that one simulates PS/2 internally. On the MacBook side it's SPI now, not in all cases, but pretty often. Not sure if it's a Double or Quard SPI interface but apparently it still does the same nice experience they had with USB - and better.
The Microsoft Precision Touchpad[1] devices are interfaced over I2C or USB. Bandwidth for I2C depends on implementation AFAIK, but should be plenty for a responsive touchpad.
I can't read the article because the site is hosed. I have a Lenovo ThinkPad X1 Extreme, and the touchpad is as good as any MacBook I've ever owned. It's the only non-MacBook that I've encountered where the touchpad is even usable.
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.
I also have a X1 Extreme, it's a bit smaller than the MacBook touchpad, but I concur that it is very responsive and works reasonably well with ubuntu 18.04.2.
It's a fair bit smaller than the current MBP touchpad. More like older MBP models. I don't like how gigantic the current MBP one is. Apple does a good job of ignoring rogue palm touches, via software, but in a way that makes it unresponsive when you want to do keyboard+touchpad combinations (which are rare, but important in some drawing apps and some games). Overall I find that I don't need that much touchpad real estate.
It appears it's actually designed that way, where it's sort of hinged from the top. I hadn't noticed myself, since I prefer the soft click. Odd design decision, and if you're a hard-clicker, I can understand being disappointed.
I switched from a Macbook Pro to the X1 Extreme as well, and have been very disappointed.
* 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.
Wow, that's impressive! I wonder if screen size impacts score on that test? Both my test laptops were 15", which probably means more space between the bubbles.
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 like my xps, but I would never brag about the keyboard or trackpad. I really miss my old macbook's kb/trackpad. Its just that I want to run linux, not macOS these days
Surprisingly I also got 292 (156+136 bonus) on the first try on Lenovo X1 gen 4 (NixOS, Xorg). Both synaptics and libinput powered touchpads have always felt perfect for me, with minor to none customization. (Currently my only setting for libinput is to enable natural scrolling.) However, I have no experience with the Apple laptops.
Doesn't Apple have some sort of patent on the hardware part of things, such as the glass in the trackpad? I can't read the site as it's being hugged to death...
I have a question regarding Apple's touchpad palm rejection. Or, maybe my question is regarding touchpads in general.
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?
Typically, touchpads and touchscreens send a complete pixel map (with pressure info if available) to the touch controller, and the touch controller filters that large amount of information into very minimal messages for finger-tracking and touch points. Some devices do substitute the CPU for the touch controller, though.
Regarding apple trackpads - For raw data, you get enough to do ellipsoid tracking, paired with 'state' information to help with palm rejection. This is my experience from working with the multitouch private framework on macos - it's generally been enough to good enough work with and arguably prefer it rather than attempting to do any raw pixel-level tracking (which would tax the CPU)
Its 100% OS level. I installed Linux mint on my macbook ages ago and my palms were constantly moving the mouse. I then installed fedora and it was back to working perfectly.
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.
I don't see why you'd need to fork libinput. I'm fine with my cursor movements, what I want is gestures, and libinput already delivers those. It is up to the desktop environment to implement them (PROPERLY).
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).
There's a lot of work still to be made when it comes to application support on GNU/Linux and that's actually what usually makes people feel bad with their touchpads (and it's what macOS excells at, not the hardware and/or drivers). In fact, drivers aren't as bad as they're usually painted, although libinput still needs to catch up to the synaptics driver a bit.
> Linux touchpad scores on par with Macbook touchpad per mouseaccuracy.com testing. As of today, I can consistently score twice as high on macOS (average score 250 with “Hard” + “Small” options) vs Linux (average score ~100).
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.
With that website, is it just a matter of clicking on the red dots as they appear?
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. ;)
Just for fun, I tried that test using my Android phone as input device via KDE Connect. The first time I got 0, because I usually only use the remote input functionality for clipboard sharing, but then I got it up to 12. What killed me was the input lag. It wouldn't surprise me if the Macbook drivers had seen a lot more work on latency optimization than the Linux equivalents.
As I've seen more responses here, I started getting curious about how screen size impacts results with that game, so I ran a few test runs on my desktop. I'm finding that my score varies by around 30-40% depending on the size of the viewing window, with smaller windows being better. So the results I posted, for 15" screens, figure to be lower than what folks would score with a 13" screen (or if using 15" with small viewing window).
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.
First time score, Hard and Small on a Windows trackpad - 295
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).
My current solution is to use a 2013 BMP streaming trackpad events to linux via Synergy. I have to use a specific old (1.8.8) version that has been patched for smooth scrolling though. Having a laptop setting in my lap while I use my desktop is not ideal though.
I'm using it with both and aside of poor touchpad support in applications (which is of course a big thing, but it applies to every touchpad out there), there's not much difference. Driver is fine, it's apps and toolkits that need a lot of work. When the app supports it well, it works really well.
I am too lazy to RTFM and debug things, but does anyone know why libinput does not have the same behaviour as the old xorg synaptic driver ? I have a *30 thinkpad, and the synaptic driver is great, but libinput is terrible. It's too imprecise and jumpy. This is a fairly popular generation of thinkpads (the actual touchpad goes back even further). So I thought that it would eventually be fixed, but it looks like so far it hasn't. How does one make libinput act like synaptic ? I don't need gestures or anything fancy. I just want the pointer to work well, which the synaptic driver does an admirable job of handling. It's even better than windows.
I'd say it should just work or it's a bug. And I know it's tedious to file bugs and report required information but that's really the only way it's going to get fixed. You could start by asking on the list, just to see if this is a known problem that's already fixed in a later version.
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.
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.
Filing detailed bug reports is still easier than fixing it myself.
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.
Thanks for all the information. It's one of those things that I'm aware of, but have just been procrastinating mainly because the synaptic driver is still packaged by all distros. Eventually, it may be deprecated. So I better get to it before that. I do test fedora betas/rawhides and ubuntu nightlies as well from time to time. I don't think this is fixed yet. Or maybe it's some hardware quirk and I'm hitting some other corner case.
Looks like a bit of HN was too much for my web host to handle (investigating). In the meantime, here's the note that I wrote the update in and copy/pasted to the blog: https://public.amplenote.com/4wdQRLmYVU6wAHo1V9yKgaJK
According to the chat rep at Porkbun (the web host for this site), "it appears the site may have received spam complaints." Which I think is their way of saying they can't handle this much traffic. Actively working all possible angles to get the blog restored with them, but this backup version seems to be holding up so far.
My solution is to use macbook pro as a terminal and editor, and do most of developments on remotely accessed linux machines. I really tried to transition to Linux but UX is so inferior, and there's very little hope that it improves.
I find the UX on a Mac to be vastly inferior to Mate or Cinnamon on Linux. The first thing I do when an employer gives me a Macbook is to install Linux on it so I have an usable UI.
By UX I include the touchpad. I have a linux XPS13 and their touch pad isn't comparable to what MacBook Pro provides. Interface on Linux isn't that bad now, I agree, but I like Mac more due to better hardware support and lack of problems.
I agree. And the touchpad is what is stopping me from say, getting a System76 laptop or an XPS13.
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.
"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."
"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."
Another problem which I include in UX is sleep mode. On Mac it works flawlessly. On XPS13 + Ubuntu/Fedora (I tried both) which I used, there's non zero probability that when I open laptop again, the battery is almost empty.
Check the logs, is it waking, sleeping, waking, sleeping, waking, sleeping? Power management bugs are super annoying because they are tedious to dig into.
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
I honestly tried my best to debug it. I installed different tools, and at some point it seemed to work, but after some time, due to some updates, it broke down. Some time after this, I just stopped using sleep mode. It was easier to turn on/off the whole machine.
XPS13 which I have is one of the most widely used linux laptops, and it a symptomatic that it doesn't work well.
my xps 13 has no problem going to sleep. It just wakes up slow and drunk sometimes. My "workaround" is to put it into 'performance mode' which kills the battery.
I have not had an issue with sleep mode in Linux since ~2007 or so. (In the early days, it basically didn't work at all)
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.
At the risk of sounding uncharitable, what is the purpose of your comment? It is hard fact that sleep mode is not a consistently solved problem on Linux. Hardware variations abound, and "works for me on my hardware" isn't very helpful to people with different hardware where it's not as reliable.
I guess it's to demonstrate that it does work on some hardware. I've not experienced any sleep issues worse than what I had on a Macbook. ie, it works 99% of the time.
Right, but I think that demonstration is unnecessary (because, duh, of course it works on some hardware), and entirely unhelpful (because, duh, the person being replied to does have issues with it, and describing an unrelated experience doesn't add anything to the discussion).
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.
I'm not making that comparison (I never mention macOS at all); not sure where your reading that. I'm merely pointing out that a response of "it works for me and has for 10+ years" when someone says "it doesn't work on my laptop" is entirely unhelpful.
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.
I must say that in general sleep mode has been working pretty well for me over the past 10 years in Linux. I had issues on my destop, but tracked it down to a USB headset sometimes not correctly honoring sleep states. I also had a slight problem with one of my laptops when Bluetooth was paired, Bluetooth tended to be broken after coming back from sleep. though I have had more issues my current 2017 MacBook. often when I take it out of my bag after a weekend it will be on 1% battery. it stopped happening around Autumn last year so I think they fixed it.
I have an XPS13, I've changed a kernel command line parameter to change from a soft sleep to a hard sleep and battery life has greatly improved.
The first comment in this reddit thread helped me out.
https://www.reddit.com/r/Dell/comments/8b6eci/xp_13_9370_bat...
I use a Macbook and a Linux (Kubuntu 19.10) desktop, and I vastly prefer the Linux desktop for UX.
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.
As a counter point, I've had repeated issues with my several different laptops in the last few years with them not going to sleep (2015~2018?). I have a new laptop now that I primarily run windows on now...
There was an issue with hibernate memory mapping that broke hibernate on my work Thinkpad for the first year or two that I had it.
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.
my retina MBP 15" 2012 would wake up with the lid closed on macOS. prolly hardware related and still linux acpi should get to 100 but I think it's gotten good
Touchpad - my work Dell touchpad is not as good as my old Macbook Pro, but my Xiaomi Air touchpad feels just as good to me. The only gestures are use are two finger scrolling so I don't make use of the touchpad as much as others do.
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.
Sleep and USB-C display work out-of-the-box on my Lenovo T470s running Ubuntu 18. I've even used a USB-C hub with Ethernet, HDMI, USB3, and power delivery. Just one wire for everything. Sleep has worked for years now. YMMV
what's missing to bring my private t470s on par with my work macbook is "hybrid sleep". the macbook seems uncannily smart of sleeping when i close the lid, then eventually hibernating, so that even after a whole weekend unplugged it has an almost full battery when i open it on monday.
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
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.
> I use a Macbook and a Linux (Kubuntu 19.10) desktop, and I vastly prefer the Linux desktop for UX.
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.
I used to strongly feel this way, but the 2016 MacBook was such an unmitigated input disaster that I switched to a ThinkPad. The function key Touch Bar died on mine twice in a year, and was never a desirable feature. And the keyboard was sticking and broken literally brand new out of the box. I had it all replaced by Apple, and within days the same problems came back. I simply can't use a new MacBook.
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.
The idea of forking libinput, vs. simply generating ~$95-150k p/annum for the guy behind libinput to go full-time, is a silly one. He was the same guy behind synaptics, and understands all of this far better than the OP.
That's not a bad idea, though that Peter is already full time employed on behalf of working on this plus other kernel projects. Perhaps seeing the enthusiasm for his project may increase his interest in working on it more. He's been a great help to me in emails thus far.
My interpretation was that the fork is to be a temporary one, with the results of this endeavour to be merged back in when the time is right. This allows them to make mistakes and drastic changes without regard for the release cycle or backward-compatibility promises of libinput, and if everything is successful then they can bundle up the results into a mergable form and get it into libinput.
I feel that this logic is faulty. The reason being if the libinput author hasn't already done this over the past near decade Mac has been trashing competition with their touchpad, it's more likely that they don't know how (or don't care about) implementing that support.
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.
Synaptics touchpads have multiple "APIs." Very likely, linux drivers simply don't get the same input as Mac's that may use Synaptics non-hid data format.
A task for a logic analyser as much as for software dev.
As a exclusive touchpad user for years, "Feels like a Macbook" isn't really the best idea for me. When it comes to drivers, MacBook gives you an okay experience. Windows often gives you terrible one ("precision drivers" helped a lot there - no such drivers for my touchpad though). GNU/Linux can give you variety depending on configuration, although there are some pitfalls and compromises. For instance, I definitely wouldn't trade my xf86-input-synaptics experience with the MacBook one, however, it has a trouble of kinetic scrolling being implemented very naively and the "thumb detection" is a bit worse than with libinput (which is actually too aggressive in this regard and it negatively affects things like two-finger scrolling for me).
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).
I've just tested with my old Dell Vostro 2520 on GNU/Linux with xf86-input-synaptics driver. What's interesting about this touchpad is that it's not a clickpad, but it has a physical, separate click buttons.
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...
And here is a comparison with an actual mouse (first try on a Logitech Master MX 2s):
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.
I tried it with a "actual mouse" too --- a Microsoft Wheel Mouse Optical (the "classic" one that apparently a lot of gamers use, but I'm not much of a gamer myself --- it's just a cheap and comfortable mouse):
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.
source on the gamer reference? nearly every tournament i see either razer or logitech. haven't seen any ms mouses in the past 3 years and i see all the major tourneys(cs,overwatch,dota etc)
googling returns no results apart from a forum link from 2013 about quake
I've been using a trackpad exclusively for 9 years now (since the original Bluetooth Magic Trackpad came out).
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.
libinput works pretty much perfectly for me, both on a Thinkpad X240 (Synaptics PS/2, FreeBSD psm(4)) and a Magic Trackpad 1st gen.
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'd love to see this happen. I know Windows's support of the touch pad is not as magical as macOS's when running on a MacBook.
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.
> 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.
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.
Apple has put a lot of work and polish into its touchpad drivers, and it makes a huge difference; it's probably the largest single differentiator Macbooks have over other manufacturers. Part of it is latency (which will probably also require some work on the graphics stack), part of it is handling all the corner cases correctly. (Improving latency probably also requires some work on the graphics stack, not just the touchpad drivers.)
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.
It's because macOS implements kinetic scrolling in the toolkit, not in the driver (like xf86-input-synaptics and some Windows drivers do). The driver itself on macOS isn't really exceptional.
>It's because macOS implements kinetic scrolling in the toolkit
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.
Not really, at least not in the GNU/Linux case. The proper way is to do it in the driver (or in some HID abstraction of the operating system - so compositor maybe), but clearly differentiating such events in the client API, so it can be properly interpreted by clients and ignored when not relevant. Otherwise you fail to handle the case where you put your finger still to stop the scrolling steadily enough to not generate any cursor movement (libinput+GTK combo fails here, btw) and to fix that you have to move all gesture processing (including basic scrolling) to the toolkit, which is a bad idea in an environment where multiple toolkits can be used at once (basically a recipe for UX disaster).
Well, at least Apple’s gesture handling API have a proven track record.
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.
Apple's gesture handling API lives in a completely different environment.
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.
I agree 100%, and I also think Force Touch doesn't get the attention it deserves. To me the 2015 Macbook Pro is the pinnacle of laptop engineering because it added the Force Touch touchpad. Being able to click anywhere on the pad and configure the strength of the haptic feedback is huge. Not having haptic feedback, or having to use a separate button, or having it vary from top to bottom depending on how far I am from the hinge, is no longer acceptable to me.
Without Force Touch-like trackpad hardware, other laptops are still too far behind.
I have bought Magic Touchpad for its "Force Touch" quietness, but other than that, I find it to be more of a gimmick. It is slightly better than the hinge-pad of my Yoga 2 Pro, but it's not a life-changing experience. What is a deal-changer for me is the volume of its click sound, especially when configuring its force feedback engine on GNU/Linux to get even lower than what macOS allows ;)
I've been an exclusive touchpad user for years already. This really isn't a big change - well, it could be if you move from a really crappy touchpad (and from my experience perceived crappiness is usually software's fault, although of course there are some bad apples in hardware too).
Having used the Macbook trackpad... I don't understand the hype. As a trackpad, it's brilliant. But so what? On a table, I'd much rather use a mouse. The weirdly inaccurate precision, odd acceleration, and clumsy movement makes the trackpad feel off. There's no acceleration sweetspot and there's no sensitivity sweetspot that I could find.. On my lap, I don't usually have enough space to use a trackpad over say a trackpoint.
It's a great solution, but it just doesn't solve any problem I have. I'd rather have a scroll wheel.
Having used a trackpad for years, I don't even use a mouse when one is available (outside of 'gaming') and use my trackpad 100% of the time. I also use my laptop for hours per week on planes / trains on my lap without any issues from the trackpad. For me, that's not something that ever felt comfortable to do with the trackpoint.. and trying to use a mouse on a train seems like it would be unpleasant.
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!
How do I do gestures on a mouse? Example: drag a file, 3 finger swipe to different desktop, drop file.
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 hate Touch-Force and wish I could buy a machine with distinct mouse buttons today.
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).
Palm rejection on the latest 15" MBP is impeccable, in my experience. I was pretty worried about that before purchasing, just because it's hard to imagine how they've perfected it on a touchpad that large, but they truly have.
Would you care to elaborate on why this is your opinion? For now, your comment just reads like a regular post on the MacRumors forums: a short and generic complaint.
I disagree, I still prefer the old-style Macbook Pro touchpad. Though I haven't used the new one on daily basis, I have always thought it felt strange.
I can only speak for my mid-2015 15" Retina MacBook Pro, and the whole pad is clearly flexible and very slightly sprung (and yes, it's made of glass - thin glass is quite flexible). You can see it flex and bend by looking across it while deflecting it - it's most easily seen by looking at the gap around the edge of the pad, between the pad and the laptop casing, while deflecting it close to the edge. The gap varies as the pad is deflected.
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.
> 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.
That's not Force Touch though. It's the Apple Taptic Engine simulating a click with a vibration. Force Touch, or later 3D Touch, refers to the ability to distinguish between various levels of force: https://en.wikipedia.org/wiki/Force_Touch
It's been working correctly since 2013 on my Thinkpad T530. Ctrl+scroll zooming is definitely enabled, I use it regularly. I use the Windows Update-supplied driver.
Have a Thinkpad X1 yoga, can confirm that this test works on Windows 10 but does not on standard Ubuntu linux. It's something which annoys me regularly, but one get's used with it, especially if one doesn't sit in front of a Mac daily ;-)
I'm using default Ubuntu on a very cheap Lenovo Ideapad and it passes this test. Additionally, the touchpad works almost as well as my Mac, other than one significant annoyance: double finger right click is difficult, because it has a tendency to scroll the window as I try to press down, meaning I miss the thing I'm trying to right click.
The touchpad drivers and input stack have come a very long way in Linux, if (BIG IF) you're running well supported hardware.
This is just improper handling of an inertial scroll and zoom in applications, not something that OS deliver. On Mac the issue has been known for much longer and most applications adopted the proper API to detect that.
I absolutely love the Macbook touchpad, the keyboard has gotten subjectively worse since around 2010 though imho. The only reason I bought my macbook (around 2015) is because of the touchpad (and screen) and while some laptops had equally good screens or mildly better keyboards the touchpad was lacking. Still hoping for a better hardware alternative in the future (that doesn't cost an arm and a leg) I don't think I'll throw down $3500 on a laptop again either.
> Visual or terminal-based means to configure rudimentary touchpad settings. The fewest options I could imagine supporting for v1 would be: scroll speed/acceleration, scroll speed, natural scrolling toggle, hopefully support for gestures.
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.
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.
Does anyone know of a good material to simulate a hand, for objectively testing a touchpad?
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.
Just tinkering with a pair of those - the glove itself doesn't activate the XPS 15's touchpad unless my hand is in it. There doesn't appear to be any conduction between my hand and the contact point on the outside of the glove according to the resistance measurement function on a good handheld multimeter, so it's not clear to me how the gloves work. But, I have managed to get a piece of copper foil, kapton, and some wire to activate it. I guess the touchpad uses some kind of RF, which makes sense...
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.
Usually capacitive touchscreens sense a capacitance difference, which is set by the dielectric permittivity (ε) of the material above. Ours is close to water's, but an insulating layer from another material will yield different measurements.
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").
218 comments
[ 1.5 ms ] story [ 289 ms ] thread[1] https://docs.microsoft.com/en-us/windows-hardware/design/com...
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.
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.
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.
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.
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.
See https://news.ycombinator.com/item?id=19486081
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.
(spoiler: it a good touchpad, but not really exceptional)
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...
https://gitlab.freedesktop.org/libinput/libinput/issues
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"
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
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.
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.
A task for a logic analyser as much as for software dev.
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).
[0] https://bugs.kde.org/show_bug.cgi?id=348270
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.
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.
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.
https://support.mozilla.org/en-US/questions/1018310
The touchpad drivers and input stack have come a very long way in Linux, if (BIG IF) you're running well supported hardware.
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.
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.[1] https://github.com/bulletmark/libinput-gestures
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.
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").
edit: this isn't a joke