11 ms·
I recently tried switching to Linux with a few different distro's (Ubuntu, Elementary OS, etc.) and use Wayland. The thing that sticks out like a sore thumb to
by emidoots 4y ago
I recently tried switching to Linux with a few different distro's (Ubuntu, Elementary OS, etc.) and use Wayland.
The thing that sticks out like a sore thumb to me, and which I've been unable to solve, is that apparently it's not possible to configure trackpad scroll speed. At all.
From what I was able to gather, Wayland/libinput say they shouldn't be responsible for handling it and instead window managers should[0][1], meanwhile gnome says wayland/libinput should handle it[2] and ultimately - several years later - it's still not possible to in pretty much any Linux distro that uses Wayland(?)
When I switch to my Linux laptop to test things, my trackpad is bonkers and I have to move my finger in like 1mm increments because otherwise I'd scroll like 10 pages in Firefox. It's infuriatingly frustrating.
[0] https://gitlab.freedesktop.org/libinput/libinput/-/issues/185 https://gitlab.freedesktop.org/libinput/libinput/-/issues/18...
[1] https://gitlab.freedesktop.org/wayland/wayland/-/issues/87 https://gitlab.freedesktop.org/wayland/wayland/-/issues/87
[2] https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/379 https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues...
- treffer 4y agoHuh, I am on Ubuntu 22.10 (current dev) and changed the track pad speed yesterday. I think it was part of the regular mouse settings in gnome.
- mort96 4y agoScroll speed, not cursor speed.
- commoner 4y agoI'm able to set the trackpad speed in both GNOME and KDE on Wayland with libinput. In GNOME, it is under Settings > Mouse & Touchpad > Touchpad Speed. In KDE, it is under Settings > Input Devices > Touchpad > Pointer speed. Do these settings not show up for you?
- mort96 4y agoThey're talking about scroll speed, not cursor speed. When using those high precision touchpads where you can scroll pixel by pixel (so not line by line scroll wheel emulation), it's impossible to configure the speed of that scrolling in GNOME, and on a whole lot of systems, it's insanely sensitive.
- commoner 4y agoOk, I see the problem. I had expected the scroll and cursor speeds to be linked, but they apparently are not. For users who prefer slower scroll speeds, I understand how this can be frustrating.
- ColonelPhantom 4y agoI have a slider for touchpad scroll speed on my KDE Plasma Wayland laptop. Also, in my experience XWayland programs seem to exhibit overly sensitive scrolling, while native Wayland is fine (noticed this mainly on Firefox). Perhaps X scrolls by line, while Wayland natively supports pixel-based scrolling?
- deleted 4y ago[deleted]
- rvz 4y agoI just don't bother with all of that, since it has been years without any improvement and with confusion of alternatives of alternative system components that are not working together and decide to fight against the OS as you have already explained this inconsistency. At that point, I just use macOS to just get work done without fiddling or googling cryptic errors for just using the trackpad or hunting down and googling why either GNOME, Wayland, LightDM, Dbus and LibInput and the video driver(s) decided to have a fight and crash the desktop.
- xani_ 4y agoFor me X11 got to the level where everything I want "just works" out of the box. The most I did is to tweak which input goes where on arand It can only go down from here. I'm not touching Wayland with 100ft pole
- lewantmontreal 4y agoSimilar to mouse wheel scroll speed being a single line and not easy to change. Firefox does have a config setting for it but chrome doesnt. Even Chrome OS scrolls a single line at a time. It feels so wrong…
- wooque 4y agoWayland is not GNOME, what you describe is not Wayland problem, but GNOME problem. It's possible in both KDE and Sway. GNOME is probably worst DE imaginable. After 20 years, they still don't have thumbnails in filepicker and even dropped preview side pane in GTK4. I can't even.
- slimsag 4y agoWith X11, I can change scroll speed using the `imwheel` tool. Years ago with Ubuntu and ElementaryOS, I could change it in the system settings GUI. Today, with Wayland now default, I can't change it at all when running Ubuntu or ElementaryOS. You can say this is a GNOME problem, or a distro problem, or whatever. But at the end of the day, I installed two of the most popular Linux distro's out there and my scrolling is literally unusable - and I can't fix it without apparently installing an entirely different desktop environment or a patched version of libinput.
- eddyb 4y agoGNOME has kind of always been on the opposite end of the configurability spectrum from KDE, IME. But also I'm not super clear on how libinput fits into the picture, I think there used to be some Synaptics-specific integration in certain places that I never went back to, to confirm the differences (switched to libinput several years before, and I've completely forgotten since what I was trying to solve back then). Anyway, I ended up writing a mostly-personal-anecdote below, that would likely not help, so you can probably skip it (if you do want to try anything, KUbuntu and https://neon.kde.org https://neon.kde.org are both on top of Ubuntu, and there's other distros, but I've not kept up with any distro I might recommend) --- I tried Ubuntu (w/ the GNOME default) once (back in KDE 4 times IIRC) and the lack of almost any flexibility felt like I was stuck in a sandbox (a literal one, like from when we were kids, not that it's easy to remember that far back). The only other time I felt like that was when a friend gave me their old iPhone (6 IIRC?) "to see what it's like" and I had to give up trying it out because both the OS, and the few apps I could find (for its max supported iOS version), had random chunks of features missing (tbh I should've jailbroken it, then it'd just be one more piece of hardware I have no immediate use for - but I digress) KDE is far from perfect (switched to Wayland recently, and been tracking a few QoL leaps in the next couple releases), but I can at least try to tweak it - same goes for using NixOS or ZFS tbh (not going to even defend those, but I have done both Gentoo-like shenanigans, and randomly RAIDed a dual-SSD laptop, respectively, quite painlessly despite not preparing for it from the start, and the weirdness budget is personally paid for a thousandfold). Meanwhile I run into e.g. GNOME apps using libadwaita nowadays needing environment variables (that appear deprecated?) to apply the KDE gtk integration theme so they don't stick out like a desaturated winamp skin. I've never felt like "power user" applied well to myself, like I'm not doing the equivalent of weight-lifting for computers, never want to be doing sysadmin if I can avoid it, I just want to have enough control to make things seamlessly neat for myself. Opinionated defaults are great in the same way you'd set up a house for a marketing reel, but if I actually buy it, why would I have to deal with a landlord telling me I can't paint the walls or move/replace some furniture to maximize my comfort? The "personal" in "personal computing" is supposed to be the same as the one in "personal property", and so I'd have similar expectations of "can screw with it without asking for permision" for both (modulo real estate being seen as an investment, and building codes, etc. - should've picked a smaller example than a house, oh well). To stretch the house analogy further, just like I have leased (some corporation's) private property as office spaces, I would be fine to doing the same (also for business reasons) with e.g. a cloud platform (most likely through GHA, whenever they announce the paid tiers) - tho be fair to everyone, this applies far more to walled gardens than opensource software like GNOME. Also, to be clear about the "sandbox" thing: sandboxes (and/or ideally more objcap systems) are great, and I think that the XDG Portal work is incredible for what it allows: the apps are getting sandboxed, the user getting more power over them. Even without Flatpak (which I keep meaning to try out), I was happy to see e.g. the KDE Wayland screenshare dialog outright has an option for "create virtual screen" (which can further be configured in the KDE settings, and e.g. partially overlapped with a physical monitor, etc.). If the app was in charge, they would barely enumerate some of the windows correctly, let alone provide new virtual screens.
- twblalock 4y agoI noticed the same thing and it was hard to believe that such a basic thing is actually unsupported in 2022. It's really just not supported by Gnome or KDE when using Wayland.
- llimllib 4y agoHere's me, 3 years ago, complaining about the exact same bug: https://news.ycombinator.com/item?id=21248799 https://news.ycombinator.com/item?id=21248799 pretty sad to see that absolutely nothing has changed.
- gw99 4y agoNo one fixes the bugs because they’re not interesting. It’s why I’m now a mac user.
- jagged-chisel 4y agoI think “not interesting” is an understatement. Making changes in OS project can be downright abysmal - lack of coherent structure, little to guidance, or even hostility toward contributions… It’s certainly not entirely because of the attractiveness of the problem itself.
- gw99 4y agoYeah I didn’t want to write a couple of pages of rant on here.
- LtWorf 4y agolibinput maintainer refuses patches because he doesn't want more settings to be allowed.
- moffkalast 4y agoNothing says Linux like maintainers of a fragmented ecosystem pointing at each other saying it's not up to them to fix something.
- llimllib 4y agoTo me the interesting/sad bit is that individually, I can see all of their points; the system is set up in such a way that there is nobody whose job it is to cut through the nonsense and keep the user in mind.
- lvass 4y ago>in Firefox ScrollAnywhere. It's much better UX than even the best scroll wheels.
- kelnos 4y agoI would think that's a toolkit (GTK, Qt, etc.) issue, not a window manager (well, in Wayland parlance, compositor) issue. The apps just get the scroll events from libinput, and it's up to them to decide how much/how fast to scroll based on what it sees. It's the same argument that the libinput author makes about why libinput doesn't implement kinetic scrolling, and that it's the job of the toolkit. Only the toolkit knows what's appropriate there. For reference, the kinetic scrolling rationale goes like this: say you start a scroll movement in one app, and then it continues scrolling after you lift your finger off the touchpad. Then you alt-tab to another app. If libinput implements kinetic scrolling, then scrolling will start happening in the newly-focused app, until the kinetic scroll decays down to zero. That's definitely not what you want, and libinput can't fix that problem, because it doesn't know anything about windows or focus. Granted, scroll speed isn't exactly the same thing, but I could imagine that a toolkit/application could want different scrolling speed in different contexts, which libinput would have no understanding of.
- flohofwoe 4y ago> because it doesn't know anything about windows or focus But that's exactly the problem with the Wayland architecture, isn't it? Input handling, window management and composition are so closely entangled that it shouldn't be spread over several unrelated libraries.
- simiones 4y agoAnd yet, in every other OS, scroll speed is a global setting, potentially with per-app overrides. No user in their right mind will configure a different scrolling speed in each and every app they use - they will have a preferred scrolling speed, and at most a handful of apps where they want custom behavior (e.g. scrolling in a game will probably require completely different precision than day-to-day, or perhaps a CAD tool).
- perihelions 4y ago- "When I switch to my Linux laptop to test things, my trackpad is bonkers and I have to move my finger in like 1mm increments because otherwise I'd scroll like 10 pages in Firefox. It's infuriatingly frustrating." The scroll behavior is highly configurable on Firefox' side: check out some of these about:config flags (if this is still of interest), mousewheel.acceleration.factor mousewheel.default.delta_multiplier_x mousewheel.default.delta_multiplier_y mousewheel.default.delta_multiplier_z mousewheel.min_line_scroll_amount
- deleted 4y ago[deleted]
- sbdncuvh 4y agoAh yes. Configuring my scroll wheel sensitivity per app just like hidpi. Just what I want...
- chrismorgan 4y agoI’m puzzled by your comment because I observe precisely the opposite: in Sway (Wayland) I have `input * scroll_factor 0.35`, but in i3 (X) I can’t reduce the scroll speed.
- eptcyka 4y agoBut you can though - https://i.imgur.com/YFiG2kx.png https://i.imgur.com/YFiG2kx.png
- 0dayz 4y agoThat's mouse speed not scroll speed.
- cqz 4y agoUse the scroll-factor setting of libinput-config[0] to configure this on DEs that do not provide their own tool (i.e., GNOME). [0] https://gitlab.com/warningnonpotablewater/libinput-config https://gitlab.com/warningnonpotablewater/libinput-config
- sandreas 4y agoYou sir, deserve a cookie! I can't thank you enough for pointing this out. Now (finally) my scrolling is acceptable on Fedora 36. See https://www.reddit.com/r/Fedora/comments/qn0o9w/adjust_touchpad_scroll_speed_enable_mouse_wheel/ https://www.reddit.com/r/Fedora/comments/qn0o9w/adjust_touch... for some further fedora specific instructions, but also read the instructions of the repository. Do you also know a possibility to stop inertial/kinetic scrolling on two-finger-tap / rightclick? (left click works, but since I scroll with two fingers, it would feel much more natural on rightclick)
- cqz 4y agoNo worries. That one is a little harder. My understanding is that libinput doesn't handle kinetic scrolling at all[0], it is now implemented at the toolkit level. For Firefox, the "hold" gesture to stop kinetic scrolling is blocked on either the required event being backported to GTK3 or Firefox being ported to GTK4[1]. My only suggestion for the time being is to try scrolling back a tiny bit in the opposite direction rather than tapping. Works for me, lol. [0] https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#kinetic-scrolling-does-not-work https://wayland.freedesktop.org/libinput/doc/latest/faqs.htm... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1568722 https://bugzilla.mozilla.org/show_bug.cgi?id=1568722
- sandreas 4y agoOk, well, at least the beast mode scrolling is now off :-) Thank you for pointing this out - lets wait some years until this works like expected ;-) But for now the ONLY thing that bugged me on fedora is (partially) fixed, I'm so happy.
- tomxor 4y agoWith X11 it's quite simple to change all possible trackpad options through a single text file with libinput e.g. cat > /etc/X11/xorg.conf.d/40-libinput.conf << EOF Section "InputClass" Identifier "Touchpad Settings" MatchDriver "libinput" MatchIsTouchpad "on" Option "NaturalScrolling" "true" Option "Tapping" "true" Option "TappingDrag" "true" Option "TappingDragLock" "true" EndSection EOF For a full listing of options: man libinput The same driver is used for wayland but I don't know how you configure it there, it will no doubt be possible to do something similar with a single text file config. I think the problem is that most UI tools like gnome settings do not expose the full range of possibilities because it's too much effort. [EDIT] Ouch, so i'm wrong, there is no equivalend in wayland. I know wayland has no concept of a display server but this really sucks for configurability [0]: > For Wayland, there is no libinput configuration file. The configurable options depend on the progress of your desktop environment's support for them; see #Graphical tools. This means there is no built in way to configure libinput without your DE/WM supporting it or other tools like libinput-config as the sibling comment points out. [0] https://wiki.archlinux.org/title/Libinput#Configuration https://wiki.archlinux.org/title/Libinput#Configuration
- TobTobXX 4y agoIIRC, that's a GTK issue. A fix is already merged [0], but getting that downstream will be a slow process. [0]: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4508 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4508