In today's edition of FDO sabotaging the desktop experience: #libinput spiking a single CPU core to 100% when the mouse is moved and dropping a crapton of events when twitching it in shooter games.
Uninstall the libinput Xorg input driver directly using evdev instead; and lo and behold: No CPU spikes and perfectly smooth input.
Can the whole libinput+Wayland+"modern Linux desktop" fad (that's holding back true progress for 15 years now) now please go collectively go and die in a fire?
libinput now supports LUA plugins. Sounds quite exciting. It makes customization of input devices much more robust, granular and programming friendly (looking at existing evdev events remapping tools).
https://wayland.freedesktop.org/libinput/doc/latest/lua-plugins.html
https://www.phoronix.com/news/libinput-1.30-Released
Darn, looks like there’s nothing comparable to #xinput in #Wayland. Under #X11, I could temporarily disable my Ergoslider bar mouse with `xinput disable "Ergoslider Mouse"`. Under Wayland, I can only list the devices recognized by #libinput with `sudo libinput list-devices` (and yes, it *does* require sudoing!) but that’s that. #Sad, as the orange buffoon is fond of saying. #Linux #FLOSS
Giving GNOME a chance on my new Framework 13 laptop. Last time I tried it was around 7 years ago, and it's much better than I remember.
But some ridiculous things keep popping up — like the fact that I still can’t adjust the touchpad scroll speed. What the heck? libinput has supported this for ages. How is this still not a thing?
#libinput 1.28.901 (1.29 RC1) has been released (#InputDeviceManagement / #EventHandlingLibrary / #Wayland / #WaylandCompositor / #X11 / #XOrg / #FreeDesktop) https://wayland.freedesktop.org/libinput/doc/latest/
(still not entirely happy with the new profile, it feels different from the old one, and I’d prefer to have the old one back, if any #libinput developer reads this)
Thank you, Arch Linux, again!
This time, though, the forum, not the wiki (which is famous even on other distros).
https://bbs.archlinux.org/viewtopic.php?id=231494 helped me to fix the crazily too-fast IBM nipple #TrackPoint on #Debian #trixie compared to Debian bullseye; the values I’ve settled on after a few tries are:
$ cat /etc/X11/xorg.conf.d/50-mouse-acceleration.conf
Section "InputClass"
Identifier "Trackpoint"
MatchProduct "TPPS/2 IBM TrackPoint"
Driver "libinput"
Option "Accel Profile" "flat"
Option "Accel Speed" "0.33"
EndSection
I made a thing:
https://forums.linuxmint.com/viewtopic.php?t=445943
It is a guide to setting up a drag lock on a three button mouse in Linux Mint. V useful if you have limited or no movement in your fingers.
I would appreciate feedback as it is my first attempt at writing a tutorial. I also think that I have made some technical errors.
I also want a pat on the head, but maybe that is obvious
@stefano #touchpad on #FreeBSD can be an issue because FreeBSD's meta-port dependencies still force installation of the xf86 "synaptics" driver. But you can still force using the generic #libinput for touchpads (which then typically works fine) like this:
# cat /usr/local/etc/X11/xorg.conf.d/40-libinput.conf
Section "InputClass"
Identifier "libinput touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
Option "ClickMethod" "clickfinger"
EndSection
#libinput 1.28.1 has been released (#InputDeviceManagement / #EventHandlingLibrary / #Wayland / #WaylandCompositor / #X11 / #XOrg / #FreeDesktop) https://wayland.freedesktop.org/libinput/doc/latest/
Die #libinput-Probleme mit Pinch-/Kneifgesten waren ein Bug und sind mit v1.28.1 behoben worden:
https://github.com/bulletmark/libinput-gestures/issues/378#issuecomment-2769870193
Mit #libinput 1.28.0 von gestern funktioniert mein "pinch clockwise / anticlockwise" in libinput-gestures nicht mehr. Damit maximiere und minimiere ich eigentlich Fenster, bis gestern. Hoffentlich nur API-Umstellung und libinput-gestures bekommt das wieder hin?
The exposure way and calculation method are defined in the "6.2.2.7 Global Items" section of the #USB HID spec 1.11. The general formula is
Resolution = (Logical Maximum – Logical Minimum) / ((Physical Maximum – Physical Minimum) * (10^Unit Exponent))
Unfortunately, I do not have a mouse device that exposes 'Unit Exponent' and 'Unit' for testing. Otherwise, it would be great to write a PR to #systemd or #libinput to add it.
> Devices usually do not advertise their resolution and libinput relies on the udev property MOUSE_DPI for this information.[1]
It seems that #libinput will first try to find the recommended value of the device, and if that fails, will use the hard-coded value, right? No! libinput directly uses the hard-coded value and systemd-udevd only provides fixed MOUSE_DPI. Neither libinput nor #systemd-udevd has the code to read #DPI from the HID Report Descriptor.
