Summary: | Straight lines at the beginnings of strokes with a Wacom Intuos on Plasma Wayland | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Lily <link-riolu> |
Component: | libinput | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | dimin21590, nate, nicolas.fella |
Priority: | NOR | Keywords: | wayland |
Version: | 5.27.8 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
A screenshot showing brush strokes in Krita that all start with a straight line.
Screen recording of the straight beginnings along with libinput values Example of the strange behaviour of tablet brush strokes |
Description
Lily
2023-10-14 18:17:12 UTC
Before you used your pen, was the mouse cursor located in the exact location on screen that the straight line originated from? Created attachment 162376 [details]
Screen recording of the straight beginnings along with libinput values
(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. Created attachment 162403 [details] Example of the strange behaviour of tablet brush strokes (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? It doesn't seem to be related to where the mouse pointer was originally. In this attachment I mark the place where the mouse pointer was left at. However when the tablet brush strokes start, and the straight lines appear and they seem to point to a completely unrelated location to where the mouse cursor was. I would like to report experiencing the same issue with Krita version 5.2.3 from flatpak, under wayland but not x11. It also doesn't appear to happen in native wayland applications like rnote and xournal++ (as per xwininfo). And indeed drawing in the tablet tester in Krita does not have this issue. I don't think the mouse cursor has anything to do with this (at least from my testing in Krita). What seems to happen is that the preview showing where the pen is hovering is slightly delayed behind the actual cursor position and when the pen hits the screen a line is drawn between the last point of the preview and the location of where the pen touched the screen. This issue is masked when you move the cursor slower and exaggerated when trying to do quick strokes. |