https://bugs.kde.org/show_bug.cgi?id=475619
--- Comment #3 from Lily <windboun...@protonmail.com> --- (In reply to Nate Graham from comment #1) > Before you used your pen, was the mouse cursor located in the exact location > on screen that the straight line originated from? I recorded some brush strokes along with the terminal output of `libinput debug-events /dev/input/$tablet` in 240 FPS on my 240 Hz monitor which I think is higher than the tablet’s maximum data output frequency, so every tablet signal should be visible in a separate frame. The video file should be attached. I watched the bugged parts of the strokes frame by frame (in mpv with the , and . bindings) and it looks like the cursor disappears the moment the pen touches the tablet and then reappears a few frames and tablet inputs later, and a straight line is drawn between those two points. There were tablet inputs between those two points that were seemingly ignored. The start of these straight lines is always at 0 pressure, even when the first pressure value is actually 0.53 (out of 1), for example. Sometimes this 0 pressure is even visible in the cursor size for a moment after the pen down event and before the cursor disappears, as it is in the first stroke of the recording. This looks similar to this (likely) unrelated bug https://github.com/OpenTabletDriver/OpenTabletDriver/issues/2960. I and the person in the issue it is a duplicate of used brushes with no pressure in those screenshots but the last input of every stroke that is wrong due to my tablet model’s firmware bug is always at 0 pressure, and you can actually see these bugged last input values in my recording. At the end of every stroke is one input with 0 pressure and coordinates that reverse the previously consistent direction the X and Y coordinates were moving in. But this last input isn’t included in brush strokes in drawing applications and it also doesn’t show up in the input values displayed by the Krita Tablet Tester, so it seems like libinput or some other part of the chain that makes tablets work on Wayland has already included a workaround for this firmware bug. Wayland (both Plasma and GNOME) is the only place where that last bugged input is ignored, it shows up in drawings everywhere else (X11 and Windows). I mentioned that other bug because of its visual similarity (a wrong 0 pressure input at one end of strokes) and to explain why this discrepancy between the last input value of every stroke in my recording and what happens on the canvas is actually a good thing. But it’s probably unrelated to the bugged beginnings of strokes on Plasma Wayland, especially since the beginnings are also bugged for the person in the Krita Forum thread who uses a different tablet model that doesn’t have the firmware causing bugged ends. And most importantly, the input values at the beginning of strokes look fine in the recording. They don’t start at 0 pressure while the strokes somehow do, and there are input values between the start and end of the straight line. So the input values themselves look fine and it should work, as it does on GNOME Wayland. -- You are receiving this mail because: You are watching all bug changes.
