I personally find the Linux desktop to be never as polished as macOS because it’s hacks over hacks.
One of the problems in inertia scrolling is that in Linux, it’s implemented in the driver level — which means that while scrolling by inertia, if I close the window, the window below will scroll. This is basically a hack because of backwards compatibility with the legacy APIs that only concern mouse events.
The proper way to do this (which is implemented in macOS) is to do this inertia scrolling in the GUI toolkit, which in macOS is AppKit. (macOS implements this in NSScrollView.)
Fixing this in Linux will be hard, since it needs coordinated effort between at least GTK, Qt, libinput, and the harware vendors — it’s an artifact of the fragmented ecosystem of Linux.
At this moment I'm just generally frustrated with the state of desktop OSs in general. I used a Mac for a decade, and was generally happy with it, but not so happy with Apple's direction and recent poorer hardware. I recently installed Windows on a couple of machines, and that's just a horrific experience, and below the shinier surface, the OS is still as clunky as ever.
I've been putting my hope on Linux, but what the world really needs, is for someone to create a unified vision for a Linux/BSD/open source based OS and hardware that basically takes the Apple approach, or at least the approach Apple had 15 years ago.
It's amazing how little progress there has been in this field. If I had money and some expertise in this area, I'd start my own company making better laptops with a Unix-like OS that's not afraid of breaking compatibility with old Linux ideas like this that are holding us back. But that's never going to be more than a dream.
That's what Ubuntu was trying. Every time they stray from the norm, they get killed. The bigger problem is that we still depend on software that depends on the norm. (What was Mir and Unity?)
That's why I loved OS X 15 years ago. But it's not open source, and it feels like it's getting less open with every new version. But worse is their hardware: I can't access it anymore. In a way, I think they peaked with the 2011 unibody design.
If these problems don’t get fixed promptly, systemd might have to start a project related to GUIs so that Linux can finally get a proper & consistent GUI environment.
(And I’m not joking — systemd gets criticized a lot about the monolithic design, but it’s design which ‘knows’ each other means that it can cooperate on big changes and features, provide consistency, etc...
I was saying that the inertia scrolling should be implemented in the toolkit level, instead of emitting bogus mouse events for ‘inertia’. Which means that GTKScrolledWindow (or whatever is NSScrollView’s eqivalent is) should implement it’s functionality, not in libinput.
I considered it as fragmented b.c. the reason it was implemented this way (instead of implementing in the toolkit) was mostly because one can’t coordinate big changes in at least three big libraries (vendor drivers + libinput + Qt/GTK) to achieve something relatively small (inertia scrolling) when Apple can just decide to ‘fix everything related’ if one decides to adopt a new feature.
Not that fragmentation is a necessarily bad thing, but it’s not great in these cases.
I’m not quite understanding the question (probably due to my lack of English skills) but if you’re asking if it’s implemented in the macOS equivalent of Qt/GTK(which probably means AppKit), yes AFAIK it’s true.
Some apps on macOS are not written using AppKit but are cross platform apps which use either the QT or GTK toolkits even on macOS. The question is asking how inertia scrolling is handled on macOS for applications which use these toolkits instead of AppKit.
It’s not handled there at all. Qt likely uses NSScrolledView underneath, but Java/Swing and GTK feel foreign even if they look the same (which they don’t, with different levels of unsubtlety).
Well, I'm not sure (as I always erase GTK/Qt apps as soon as they become useless), but what I remember is that they do handle window changes (b.c. event propagation is handled in AppKit), but the inertia doesn't feel right. I think there are apps that do implement inertia, and there are also apps that don't implement inertia. Both feels wrong.
That was my question. So macOS has one blessed toolkit working nicely and everything else feeling "wrong". So this has nothing at all to do with being "fragmented" but simply says "apple has one good toolkit and lots of bad ones".
Both GTK and QT are exceptionally bad toolkits and are part of the reason the Linux Desktop never took off. Giving GUI toolkits responsibly for even more things is clearly a bad Idea. Also personally I like the fact that inertia scrolling works everywhere consistently the same way. Just think about the horrors everybody now implementing their own scrolling. Consequently the fact that Linux is "hacks over hacks" is a feature not a bug. People should stop assuming that copying Windows and Mac will somehow give Linux more popularity.
> Also personally I like the fact that inertia scrolling works everywhere consistently the same way.
> Just think about the horrors everybody now implementing their own scrolling.
Which should be a reason for advocating one toolkit that rules everywhere (maybe systemd-toolkit?), not a reason to have poor inertia scrolling experience that doesn’t work properly across different windows.
> Consequently the fact that Linux is "hacks over hacks" is a feature not a bug.
How can this is a feature, not a bug? Isn’t it technical debt?
I'm sure that the real issue with Linux is more a philosophical one, where certain aspects about freedom overlap with UX in a counter productive way, preventing devs from being very opinionated about important UX things.
Unfortunately the state of Linux as a desktop OS in the past decade has missed entirely the hardware developments. No proper support for scaling for hidpi monitors, scrolling with precision mice/touch pads, no touch UI, UI is that still not deep enough and casually requires the user to spawn a terminal, graphics drivers that are still not stable and do not support the latest standards like hdr.
I wish there was a for profit company that would focus on making a polished desktop linux distro. There is only that much that the oss community can provide for free, but it is simply not enough.
> No proper support for scaling for hidpi monitors
I'm sitting here with a 4k 32" monitor and a 1920x1200 24 inch side by side, scaled perfectly so both are pretty and readable, in xfce, and when moving things between screens nothing changes size, or re-renders weirdly, or can't be resized due to invisible boundaries, or ...
It's better than windows or MacOS can manage with the same setup.
I'm not sure what you count as 'proper', and yes I had to write a two-line script with xrandr commands so ease of use isn't massively present. But the underlying system absolutely has great scaling support.
Graphics drivers are also fine these days, I've not had any problems with my mouse either. Hardware in general "just works" better than windows these days, with older devices supported and no drivers to hunt down on the web.
I'm not trying to claim it's better for you, only you can decide that. But it works great for a lot of people.
> I'm sitting here with a 4k 32" monitor and a 1920x1200 24 inch
You didn't understand the problem mentioned by GP. Neither of your monitors requires HiDPI scaling. Your first monitor has approximately 138 dpi and the second a paltry 94 dpi.
Compare that to a 2012 MacBook Pro that has a 15.4-inch display with a 2880x1800 resolution. That's 221 dpi. The hallmark of a HiDPI is that its DPI is so high that you need to render UI elements at 2x or more (though sometimes 1.5x also works), so that originally a one-pixel line becomes two pixels wide. This requires support not just in drivers and the OS, but the application. ArchLinux has an entire wiki page discussing application support: https://wiki.archlinux.org/index.php/HiDPI
I beg to differ, 4k/32 does need scaling to my eyes. I don't want things to be that tiny.
Not every application needs to support scaling, so long as the GUI framework they use does, and the window manager does (XFCE has support, which I have activated) that makes the 4K screen more usable to me (while allowing the full res to be used for smooth rendering), then I use xrandr to scale the lower-dpi screen back down so elements are the same size across both. Sure, there are a few apps that don't behave brilliantly, but they aren't things I use much.
Like I said, it works better for me than MacOS or Windows (I have both, and a 2103 Retina MBP I still use).
Of course I meant a 2013 rMBP, I'm not a time traveller :)
I'm still impressed that it can do its scaling stuff on a 4K screen, using onboard intel iris graphics. It's been a great investment that little machine.
I'm not sure if 1900x1200 counts as hidpi. I have a 4K screen and I find the experience at native resolutions awful. Please install Dia and tell me about your wonderful experiences with that program. Provided you can see any of the icons that is. Then tell me why the scaling isn't across the entire operating system but app specific.
For stuff like this, Linux is bullshit. For many desktop usecases, Linux is bullshit. After a Skype call I need to kill the app else the process takes my CPU usage to 100%. Why? God knows. Probably the same reason my lock screen sometimes shows a password prompt when I press 'Esc' or 'Enter' and sometimes it requires me to click the mouse. Did I mention I spent the last nine months without a working microphone because the drivers for my new Thinkpad hadn't made their way into any major distribution??
Don't get me wrong. I love Linux. I'd take its broken ass over Windows any day of the week. But fuck me if I don't miss macOS.
Pretty sure it doesn't :) That '1200p' screen I have certainly isn't in need of scaling for usability, but I have scaled it to match the size of screen elements on my 4k screen next to it.
I've been going back and forth between MacOs and linux a lot lately, been using my Mac as my work laptop for the last couple of years, now that I'm working remotely 100% I figured I'd switch over to linux. Honestly not having much issue with it, bar the odd "Teams has decided it can't use your headset microphone, for reasons" error.
Never even heard of Dia, let alone had call to use it. Just installed it and yes, for unknown reasons it doesn't seem to scale does it? Which is odd given it's presumably a gtk3 app and others do scale just fine. Looks like GIMP is another one that's not onboard yet.
My daily use at the moment is IntelliJ, MS Teams, Skype, Firefox and Steam. I guess gedit, meld and a few other utilities. They all seem to be fine. Perhaps my relatively constrained set of requirements is why I'm happy with it.
I too have thought for a long time there needs to be a for-profit company that focuses on a polished Linux distro. Sure there is Canonical but IMHO they're not doing such a great job on the polish side of things.
There is system76 with "Pop OS!" but I would like to see a company who's entire focus is on release a very slick OS _only_.
I think we really need the system76 approach. The only way to make a profit on a desktop Linux is to take the Apple approach of selling hardware with the OS preinstalled and tuned for that hardware.
By all means make the OS downloadable separately, share with the community and all that, but to make a profit, you need to sell hardware. And the hardware needs to be good.
So I am about to start a new job, and the new workplace was about to send a new Macbook Pro out to me, which I didn't want. So I went to do some research for a laptop with any Linux distro preinstalled so that I could go back to them and tell them I'd rather have this.
I found out that there is no decent laptop with Linux preinstalled. System76 has some decent systems, but they didn't come close to what the likes of Dell and Lenovo offer with Windows. For now System76 seems to show most potential in this area though, so it will be interesting to see what they do going forward.
The Dell XPS developer edition is a great little laptop, however, my issue with it was that it only came in 13" size. My ex-collegue had one and played around with it for a bit, it was great except for the screen size.
The announcement regarding Lenovo's upcoming ThinkPad laptops coming with Fedora pre-installed came a literally 1 or 2 days after I'd already ordered the P1 Gen 2, which according to Canonical is certified[0] to run Linux correctly, and it's the reason I went for that. Regardless, the next generation would have left me without a laptop for the job.
Ubuntu 20.04 (Gnome) is the first version of Ubuntu that's ever been able to scale different density monitors to different scales.
It always had the options there in previous versions, but it only ever honoured the value you set on a single monitor. Now, I can have my 4K monitor at 200% while I leave my laptop at 100% (1080p) and it works perfectly.
If only it handled Bluetooth audio devices better it'd be perfect; Currently, I can't connect a pair of truly-wireless earbuds and play audio out of them without using Blueman to mess around with the audio sink settings etc each time I connect them. On my desktop, with Manjaro (KDE) and an Intel AX200 WiFi/Bluetooth I can connect both the earbuds (with no additional tweaking) and for example an Xbox One S Bluetooth controller (with the minor tweak of disabling etrm), and they both work perfectly.
I'm not sure how much of that is related to Gnome/KDE but Ubuntu really could do with some better Bluetooth device handling, especially for audio devices.
> Ubuntu 20.04 (Gnome) is the first version of Ubuntu that's ever been able to scale different density monitors to different scales.
Welcome to the world that Fedora users have been living in for years already. Ubuntu users can thank to Canonical's decision not to enable Wayland in 18.04 for that...
But I _was_ using Wayland in 18.04. So it wasn't just that Wayland wasn't the default, it didn't work even in Wayland on 18.04. I know Fedora works better, a friend/colleague of mine who uses Fedora repeatedly reminds me of it :D
If it was intentional, it was a horrific UX fail. Every ounce of my being convinced me that the way it was presented, I should be able to scale my monitors differently, and the fact that it didn't was just a bug nobody cared to fix.
If it really was intentional, a small dialog or log that explains _why_ I couldn't scale monitors differently would have sufficed, or, simply moving the percentage adjustment control out of the settings for each display.
On that note, 20.04 is supposed to support fractional scaling, but if I try to turn the toggle on, it just fails silently, so are we back to square one, or did a developer somewhere decide some precondition means I can't _currently_ turn it on, but didn't feel it was worth telling me, the user, why?
Are you trying to enable fractional scaling under X11 or Wayland session?
In the past, when it wasn't exposed in GUI, and worked for Wayland only, it was necessary to logout and login between enabling fractional scaling and setting the scale itself (the reason was, that Xwayland was started in different mode then; technicality, that doesn't matter no normal users, but then, the functionality was labeled experimental and enabled via gsettings anyway).
The X11 fractional scaling is a different beast; it uses xrandr scaling and requires cooperation from the graphic card (the output encoder, specifically - it sets up framebuffer at different size than the output to display). That also means, that it won't work on machines that do not have output encoder at all and assume framebuffer resolution is equal to output resolution, like remote sessions or virtual machine clients. Here I agree, that some error message would be appreciated. It was also brave from Canonical to enable it for LTS, without going through a testing cycle in a non-LTS release.
I'm in Wayland, I see the option in the display settings. "Fractional Scaling" but toggling it does nothing other than making the screen flash black for a second.
Probably. It might have been a good call in that regard; as with everything, there are compromises.
With a hindsight, the remote desktop/screen sharing solutions caught up faster (except the closed source ones - they have no motivation when ubuntu works, so why bother) than figuring out how to handle several displays with different dpis under X11 so that legacy apps not using modern Gtk/Qt work.
> Ubuntu 20.04 (Gnome) is the first version of Ubuntu that's ever been able to scale different density monitors to different scales.
You can do it on pretty much any modern X on linux using xrandr, FYI, it's just not easily done in a settings app. I've been doing this with xfce for a while.
Pretty sure xrandr is just for X. Am on debian with Xfce, so not using wayland at present. AFAICT Wayland is the default option for Gnome sessions on debian, but I fell out with gnome around the 2->3 transition and have never looked back.
My xrandr line is not that easy to read but effectively, after I've set xfce hidpi support to double the size of screen elements, I increase the view window of the smaller screen by a factor of 1.8, and of the larger screen by a factor of 1.2, and put them next to each other -
Wayland does that out of the box; unfortunately most people do not run Wayland, either because they prefer WM/DE that is X11 only (xfce, etc), or just because.
On X11, scaling of entire framebuffer (i.e. scaling macOS style) is a standard xrandr functionality, but it was never exposed to UI. It has some drawbacks that macOS never had to solve (how it behaves over remote x11/vnc/etc, or memory requirements for framebuffer, for example), that make it unsuitable as a general solution. It is basically one of the hacks complained in this threads.
I'm not sure what "Wayland does that out of the box" means; I ran 18.04 with Wayland since launch, it never gave me different scaling per monitor (not in the Gnome UI anyway).
Are you saying it would have worked had I used xrandr?
I'm sure so far as when I login I select "Ubuntu on Wayland" and when I search through the output of top for "wayland" it's there. I'm not sure how else I prove I'm running Wayland. The machine I'm sending this from now is still running 18.04 on "Wayland" and I cannot set the DPI independently for each monitor, if I select my external monitor and set 200% and click "Done", I get 200% on all displays.
You don't have to prove anything (but informatively, the way to detect wayland session is to check for XDG_SESSION_TYPE env variable). Also, just for curiosity, what GPU are you using?
It is quite possible that 18.04 has some bugs. I don't have 18.04 machine with hidpi monitor at hand, so I can't have a look myself, so I chalk it up that there is something weird happening.
I've had trouble with bluetooth for the past 5 or so years since I started using Linux as my main OS but lately I've had very little problems, I can't remember a missed connection; only problem I still sometimes have is that the audio goes into low quality mode which is solved by a quick reconnect.
I own a pair of Master Dynamic MW07 and a UE BOOM speaker. As for my laptop, a Dell 7470 with Ubuntu 18.04.4
Interesting. Did you need to use Blueman or tweak anything?
I've found that without Blueman installed my earbuds will pair but are not even detected as being an audio device. I dislike having Blueman installed/running so I'd like to get it working without.
I'm running Ubuntu 20.04 upgraded from Ubuntu 19.10 on an XPS 13 (it has worked on neither). I'm tempted to test on my Ubuntu 18.04 laptop (XPS 15) to see if perhaps it was broken recently.
One thing of note perhaps, is that the XPS range use the horrid "Killer Wireless" card from the Alienware/Gaming range, their Linux driver performance has been generally horrid in the half a dozen of them I've experienced.
So I tested this on my XPS 15 with Ubuntu 18.04. The earbuds paired perfectly, and after selecting them in sound I have output. If I put them back in their case, the sound switches back to the laptop speakers, and if I pull them out again, they reconnect and sound switches to them.
I must therefore conclude that something has been broken since 18.04 as it neither worked for me on 19.10 nor now on 20.04.
Usual job description require you to be a full stack engineer, and devops engineer, and hardcore c/c++ engineer and a whole bunch of other things for the price of one intern.
I don't know if OP has actually fully noted the requirements, but the point of this job is to work on improving gestures in Linux and that's all. If these requirements are all that's needed then that's it.
Interesting, does this mean that a macbook's "superior" touchpad is actually software driven? I always thought it was a hardware issue vs software issue.
A mix of both. MacOS's multitouch privateframework has a number of states to cover when a finger is just landing, ellipsoid data, palm rejection / resting thumb states. The ability to provide this data is presumably done by their touch hardware.
I encourage looking at the earlier discussions since much has been talked about this before.
Pretty much it. Oh, and also I had patched libinput to be able to drag with three fingers, a gesture which I have on macOS.
3 and 4 are more like a tie.
On macOS, when I move the cursor with the trackpad, it’s almost intuitive for me where the cursor is going to end up. With Linux, it’s almost always an uphill struggle. Like the acceleration curve adopted by Apple is more ergonomic.
The hardware is nice and definitely better than the alternatives, but the real difference is the software.
The acceleration, the low latency and the super smooth animations for the gestures are what really set the mbp apart and make the gestures so natural to use.
Having used Gnome 3 with Wayland and libinput (the best Linux trackpad experience at the moment) until last year, I can say that while the latency and acceleration curve are definitely not there, at least the animations are better implemented than those of Windows 10
It is very much software – all modern trackpads are capacitive touch surfaces.
A MacBook’s trackpad hardware is differentiated because it is covered in glass, larger than most trackpads by a lot, and it clicks using a force sensor + haptics (so it is more reliable / has an even click across its surface).
It's not enough to just say "all trackpads are capacitive surfaces, fix it in software!" when it's actually the controllers attached to all of these capacitive surfaces that are different. The driver can be as intelligent as you like but if the controller only sends limited data in response to touches then you still won't get very far.
Thinking back to older models though, MacBook trackpads were better than any other I tried before they had all those hardware features. It’s obviously been a long time, but I feel that a really old MacBook would still feel nicer than most modern trackpads on other platforms.
It’s the one thing that’s keep me on the Apple platform for almost 2 decades now.
2008 is when Apple's trackpads got full general multitouch support. (Prior to that, they supported 2-finger scrolling.) The 2008 MacBook Pros still had a big bar as the physical button, but later that year they started introducing the unibody MBP with the entire trackpad as a physical button hinged at the top. In 2015 they introduced the Force Touch haptic trackpad. As far as I can recall, all three generations of trackpad have basically the same cursor motion behavior and similar sensitivity.
There’s one thing that’s bothering me about this “project”. How is it supposed to work with the upstream? Is this supposed to be a rivaling fork? How am I supposed to have it on my system?
Also, it rubs me the wrong way that the blog author is seeking a person to do all the dirty work — even for compensation — and then what? Have all the credit? Basically, act as a glorified Forward button?
If I felt up to the task enough, I’d slap a sponsorship button onto my github on my own. And here’s the difference: prior to asking for the money, I’d have something to show to prove I’m not a phony.
The upstream is not without its problem as well. Right now it’s being maintained by Peter Hutterer from Red Hat, and judging by his LinkedIn, it’s pretty much his job description. Recently he did a talk about how overloaded he is with libinput[1], and how someone volunteering to comb through pull requests and issues would easily become his “number two”. Which also is striking me as odd.
libinput, given its importance for Linux ecosystem as such in general, and Red Hat ecosystem in particular (especially since they bet on Wayland as the future, and there libinput is the only choice), is important enough that Red Hat better make sure it’s well maintained. It’s Red Hat/IBM, really, who should be interested in making sure the bus factor of libinput is > 1. Thus the problem should be raised within Red Hat’s management, and they should _hire_ additional people for fair buck to help. Otherwise it looks as if someone who’s paid for X input stack maintenance is seeking free labor to help him.
If I asked someone to help me do my paid job for free, open source or not, I don’t think it would even be ethical.
Having used a Macbook for the last 10 years, I can confirm that the trackpad feels better than trackpads on windows laptops, Chromebooks, and Macbooks with Linux installed (IMO, that I've tried).
However, I think the tracking may change slightly with major MacOs releases. So which version do we prefer..?
The touchpad on my current gen Dell XPS 13 is superb on a stock Ubuntu install. I'd love to know how much of the "bad touchpad" reputation that Linux has is down to low quality hardware versus software support.
Have you tried a Mac touchpad? I use both a Dell XPS13 (Ubuntu from factory) at home, and a MacBook Pro at work. The Mac's touchpad is miles ahead... and that's even after I spent a couple of days messing with libinput settings to make the Dell's touchpad more acceptable (it's fine now, just not really close to the precision of the Mac's touchpad).
Most likely its cursor acceleration. macOS dynamically adjusts the cursor movements based on the user swipe speed which makes it feel both precise and fast.
Last time I used Linux on my MBP, libinput was more... linear.
It's really quite difficult to quantify what's actually different. It feels really precise without being "flicky", using it feels very natural and you sort of forget about the touchpad and just will the cursor on the screen to do as you wish.
I've always struggled to articulate why I prefer the MacBook's trackpad to every other trackpad I've used, and I think you've hit on something with that last sentence. It feels so natural that I really just don't ever think about it, my brain skips straight to the actual interface I'm using it to manipulate.
I get the same feeling with high vs low quality touchscreens (e.g. my phone vs some ATMs), and especially with gaming controllers. With a good, ergonomic controller I sort of forget about the shape and weight of the controller in my hands after a while; my entire sense of it narrows down to the buttons/triggers/joysticks.
I have the XPS 13 9350 and i like the touchpad as well. There‘s always room for a little improvement but during daily use it‘s not that i‘m annoyed by the touchpad. Not at all.
Can people who work on both platform comment on the biggest issues for them?
Nowadays I work mostly at my desk, but for several years I've worked 90% of the time on my laptop keyboard. Synaptics with a bit of customization (Area*Edge size for palm detection, single and double tap timings) worked extremely well, and I consider myself very picky.
Edit: this seems to be about libinput, in which case I understand, as the two times I've used libinput I gave up after a few hours of intense frustration
I use a mac at work and a Thinkpad with Linux (Fedora) at home. Personally I can't notice any difference (on the other hand the Thinkpad keyboard is glorius). I wonder if people refer to gestures, which I don't use.
I don’t think it’s about gestures. I have two MBP (2015 and 2018), Lenovo cirka 2017 (stock Ubuntu), an Asus Zen (PopOS) something from 2018 and a Dell something cirka 2016 (Windows).
Nothing beats a he MBPs trackpads. I’m not sure what it is exactly, but I feel that on Windows the cursor drifts, when I lift my finger.
On Linux I feel the trackpad is very sensitive (I get more cursor jumping around).
Also, on both Windows and Linux it just feels like they are less precise.
I guess it is the ‘it’s hard to explain’ factor that makes it hard to replicate?
It’s about cursor acceleration — macOS uses an acceleration scheme so that you can get from one’s end to the other in one swipe if it’s fast enough — if the swipe is slow, the cursor becomes more precise and slower.
I’m not due how it is in Linux, but last time I tried running Ubuntu on my 2017 MBP, It wasn’t possible to move from edge to edge in one swipe.
> Since I don't regularly use a Linux laptop and haven't in a couple years
I’m in the opposite camp. I’ve been using a Linux laptop at home (by choice, obviously) for the last 5-10 years and have finally been able to setup a Linux-powered workstation at work.
It feels so refreshing and liberating. I can’t imagine ever going back.
It's funny... I have never touched a MacBook. I'm actually very happy with the Linux touchpad drivers. I went to the article hoping to get a clear idea what the author likes about the MacBook drivers that are absent in the Linux drivers... But he doesn't say. Instead there was a poll asking me what I thought was wrong (which is nothing)... The parts about multi-touch were interesting because I really like the way multi-touch works in the current driver. So I think I'm missing something.
So for those of you frustrated with the Linux touchpad driver... what is the problem? Or is it just that it's not the same (which is a completely valid complaint, IMHO)?
I dislike Macs quite badly and go through a lot of hoops in the hopes of not being forced to use a Mac when I start a new job. I hate the keyboard. I hate the touchbar. I hate the MacOS in general. Despite this though, there is one thing I praise a lot and among all peers, and that is its trackpad.
The trackpad is extremely responsive. The "click but it's not a clickpad" feature they have is perfect.
Combine that with the responsive, intuitive and really great gestures that aren't event based, but rather they are smooth gestures that can be turned back and undone. Compared to something like libinput-gestures which captures the gesture and then triggers a shortcut of some sort at the very end.
I find it hard to explain. The trackpad doesn't feel like it's in the way. It feels part of you once you understand and get used to the gestures.
From using Linux on my MacBook, I remember poor palm rejection being one frustration. Also, I think multi-touch - such as scrolling with two fingers - didn't work.
Just all round it wasn't very pleasant to work with. Perhaps if you have been using trackpads on Linux all your life, you are used to moving your hands away from the trackpad when not in use -- and so accidental presses are maybe never an issue for you.
I've only ever used a MB once or twice; usually little more than trolling someone who's left their machine unlocked in the office, but I did find the touchpad intuitive.
As an exclusively Linux user, my only real issue with touch pads is palm rejection, I feel like it has never worked so I end up in all sorts of awkward hand positions trying not to tap it by accident.
As a 6ft4in male (with the large hands to go with it) it becomes painful when trying to do this for any period on my XPS 13. On the XPS 15 it's easier because there are large enough spaces either side of the touchpad to rest my palms.
I have repetitive strain injuries, so I simply cannot use Linux. The way I have to twist my wrists so the touchpad doesn’t mistakenly register a palm print is obnoxious and pain inducing.
It sounds to me like the Linux macbook drivers are worse than the drivers for other hardware. Which is a problem, but on the other hand I don't see a reason anyone would buy Apple's overpriced hardware and put up with glued-in batteries, soldered on SSDs, display cables that disconnect if you open the screen too much, crappy keyboards, thermal throttling, etc., if they weren't married to Mac OS.
Plus, with how the T2 chip is going you might not even be able to boot Linux on a Macbook in a few years.
I use a MacBook most of the time and incidentally Linux/Windows systems, and IMO the problem is not the Linux touchpad drivers are bad as such, but the way the system as a whole reacts to its input.
Since macOS uses GPU-backed windows all interaction animations run highly responsive at 60fps. Scrolling through a webpage or navigating to another windows with 'expose' or just swiping between workspaces is really instantaneous. Also, try swiping 'back' in Safari and you immediately see the current page moving a bit out of the way, exposing the previous page. If you decide you don't want to go back you just let go of the trackpad and the action reverts.
Applications implementing their own rendering (Firefox/Chrome and other non-native toolkits) do not have that quality consistently.
Same hardware with Linux or Windows 10 feels completely different. Windows profits from GPU optimisations, but the UI situation is a mess. Every Linux distribution's GUI (X11 _and_ Wayland) I've worked with has even more noticeable lag between user input and output.
Most likely its cursor acceleration. macOS dynamically adjusts the cursor movements based on the user swipe speed which makes it feel both precise and fast.
Last time I used Linux on my MBP, libinput was more... linear.
I remember when I switched from MacOS to Linux and the mouse drove me crazy. I don’t know what has changed but I’m totally comfortable with it now. I do tend to feel like the mouse is an awkward tool. Maybe some MacOS like improvements could help with this. I hope they find a good dev and some funding for this project!
I was very surprised to find out that XPS 15 touchpad cannot report pressure on Linux, felt so contrary to everything else I can adjust and tinker with under Linux. But touchpad tap is just tap / no tap and there is no middle ground. I'm coming from Linux->Windows->Mac->Linux background, and I can certainly feel the pain coming back to Linux from Mac (2014 models with the sane touchpad size). Palm rejection and tap sensitivity are two major issues, but you learn to live with it. Two-finger browser "back" gesture is something I also miss direly, and no amount of experiments with funky Ruby (!?) based gesture libs could fix that.
I'm sitting here at my dual 24" 1080p monitor, natural keyboard, vertical 5-button mouse, 32GB/500GB Linux (XFCE) desktop and I couldn't be happier.
Fuck touch pads and hidpi monitors. They're honestly dumb. Who wants to work all day on a laptop? People who optimize their equipment for working in meetings or working on the move are doing it wrong.
No wonder Silicon Valley is a bubble of Mac users. They're concerned with all the wrong things, just like the Mac OS UI or any other OS that has been tainted by its influence.
I work 90% of the day on a desktop. That doesn't mean that I want my 10% laptop time to be an exercise in frustration. Linux touchpads are exactly that. (It's the main reason I abandoned my short experiment with a Linuxified Chromebook and reverted to a MacBook.)
Understandable. I was initially confused - moving from Linux to MacBook? But 'touchpad' explains it.
My frustration with MacOs is, mousing around to all four corners of the screen constantly. They've separated everything into the corners. But with a touchpad, less frustrating.
I'm with you, use the largest desktop I can afford. But a contractor we use, young person, spends their day on a touch laptop and is happy as a clam. Turns out top-quality code on a schedule. We raised her rate instantly we saw what she could do.
Maybe other users just have different usages? I work all day on a laptop and couldn't be happier. Switching seamlessly between places during the day (standing desk, sofa, coffee shop, train, ...) depending on the task (development, email, support, meeting) is great for my productivity. Also less back pain.
Good luck bringing your desktop with you on a business trip or if you want to take a break from your office and go work in a coffee shop or a coworking place.
How many touchpads expose the raw touch data (ie. A bitmap of capacitance data) necessary to replicate macos gestures? Things like palm detection absolutely require that.
Is the project worth it if it only works on one model of hardware?
Microsoft "enforces" nowadays a generic touchpad interface they call Precision Touchpad. When your notebook has one of these, the Windows generic driver kicks in and the experience is MUCH better. I never owned a MacBook but I never again will accept a Windows laptop without a precision Touchpad.
So, I have good hope that Linux users will enjoy this experience also one day. Microsoft forces the vendors in it.
I have an HP laptop that supports the Precision Touchpad drivers, but it takes considerable effort to use them. By default, Synaptics drivers will be downloaded by Windows Update and override the Windows built-in drivers. It doesn't make much difference to the cursor motion that I have noticed, but the Synaptics configuration UI is just as bad as it was 20+ years ago and doesn't seem to offer the same range of options as the Windows settings page it disables.
With big OEMs like Dell and Lenovo finally offering laptops with Linux preinstalled, is there any chance one of them could put in the investment required to solve this once and for all?
My XPS 13 has a wonderful touchpad out-of-the-box, one config line and natural scroll works (think you can enable it in settings on a stock Ubuntu install though).
Thinkpad is also adequate for me for basic pointing and two-finger scrolling. But I still miss the pinch to zoom feature. Also, natural scroll is nice, but it turns on for everything and it shouldn't imho. For example with natural scrolling enabled the gnome speaker icon requires scrolling up to decrease volume and down to increase, which doesn't really make sense to me.
Does Linux offer tap to click? Of all the many things I love about trackpads on the Mac, tap to click is very close to the top. Such a tremendous reduction of friction.
In the dawn of time when Cirque [1] launched the glidepoint - the mother of all touchpads - I used touch to click on Linux and OS/2. To give an idea of how long ago this is, the thing was connected to the PC through a 9-pin serial interface, just like the mouse which it was meant to replace. I still have the device, it still works although the plastic shell and the buttons have undergone quite a few repairs.
Touch to click is more or less as old as the idea of a touchpad.
Ah yes the three-finger drag is still hidden away in accessibility. It is one of the few options I enable there, such a great option I am kind of surprised it isn't the default as once you use it it becomes so natural.
One of the problems in inertia scrolling is that in Linux, it’s implemented in the driver level — which means that while scrolling by inertia, if I close the window, the window below will scroll. This is basically a hack because of backwards compatibility with the legacy APIs that only concern mouse events.
The proper way to do this (which is implemented in macOS) is to do this inertia scrolling in the GUI toolkit, which in macOS is AppKit. (macOS implements this in NSScrollView.)
Fixing this in Linux will be hard, since it needs coordinated effort between at least GTK, Qt, libinput, and the harware vendors — it’s an artifact of the fragmented ecosystem of Linux.