BOOSTS NEEDED, HELP WANTED:
I came across a very odd issue that I thought was Krita specific, but turns out it's not.

https://krita-artists.org/t/edit-pressure-input-is-capped-only-when-using-rubber-key-on-stylus/185000/10?u=wakocima

I have no idea how to troubleshoot this. I'm not experienced with
#wayland and #libinput . To clarify, I am using a 2-in-1 MSI Summit, together with Renaisser 520C. Things have worked fine before, and suddenly broke down -- I have no idea where to pinpoint the time things broke, but I did not do any system upgrades -- I did one AFTER encountering the issue.
EDIT: Pressure input is capped only when using "rubber" key on stylus

Tiniest of updates; I have to assume it’s something to do with wayland reading MPP input. No clue how to change that one, or how to even check for a possible error, so it’s time to dig into wayland’s docs 🫠 I’m just baffled as to what could have changed when things were perfectly fine before. Oh well, it is what it is, time to spend time learning. 🥴 EDIT: Still no clue on the fix, but libinput DOES register the lower button as “eraser”, which automatically hampers the ...

Krita Artists

:(

It's pretty fundamental to use of mouse that when you are clicking a mouse button, your hand moves the mouse and this may register in the sensor, causing a drag event to register. The higher quality sensor (high DPI), the more likely this is.

There used to be a "drag start distance" setting in Linux desktop environments, but now it's missing (specifically #KDE Plasma 6 but probably elsewhere too).

#libinput is the backend of mouse handling with #Wayland, I couldn't find this setting in it.

Related: does anyone know if there's a way to make palm rejection work under #GNOME? The #libinput documentation (https://wayland.freedesktop.org/libinput/doc/latest/palm-detection.html) claims that it can do palm rejection, but it doesn't say anything about how I can influence it as a user. On this laptop, there's seemingly no attempt what so ever at rejecting accidental input from the palm

#linux #wayland

Palm detection — libinput 1.31.0 documentation

I've already assumed that my touch pad was broken (or the driver was buggy) because after a tap-and-drag action, the mouse button was not released when releasing the finger from the touch pad.

It was "sticky", e.g. after marking multiple lines of text.

Just found out that this was introduced a while ago in Sway (to follow libinput recommendations):

https://github.com/swaywm/sway/commit/bbadf9b8b10d171a6d5196da7716ea50ee7a6062

Setting "drag_lock disabled" in the touch pad's config fixes this. 😌

#sway #libinput #linux #touchpad #laptop

Add support for LIBINPUT_CONFIG_DRAG_LOCK_ENABLED_STICKY · swaywm/sway@bbadf9b

Use it as the default, as recommended by the libinput release notes: https://lists.freedesktop.org/archives/wayland-devel/2024-November/043860.html

GitHub

The recent updates also included a new version of #libinput. However, #bash is still reporting: Command not found.

This is no fun at all…

#Linux #Arch #ArchLinux

Mit den gerade durchgeführten Updates kam auch eine neue Version für #libinput. Doch immer noch meldet #bash: Kommando nicht gefunden.

Das macht alles keinen Spaß…

#Linux #Arch #ArchLinux

I'm mildly sad because recent updates to Linux Mint mean that my computer no longer connects to the Bluetooth adapter I plugged into my stereo, my clever hack to make my middle button a drag lock no longer works and my start menu became tiny. I'm sure that all the issues are solvable, if you have more skills than me, but I wish that things didn't break when they updated.

I am sure that keeping everything working across a vast space of configurations is a hard, hard problem, so no criticism is meant. I would like it to work though.

#LinuxMint, #Bluetooth, #Xinput, #Libinput, #Moan, #WhyIsMyStartMenuTeenyTiny

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

#libinput #linux #lua

Lua Plugins — libinput 1.30.0 documentation

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