Created attachment 164920 [details] Input issue under XWayland (tested with Xournal++) I'm experiencing input issues with certain applications that accept stylus input when run under XWayland. For example, running Xournal++ on XWayland to work around bug 424485 results in streaking that is quite noticeable my current writing speed (see attachment: black is XWayland; green is native Wayland). Steps to reproduce 1. Run 'GDK_BACKEND=x11 whatever (ex.: xournalpp)' in terminal 2. Start writing with stylus Excepted behavior: Strokes are clean and without streaking Observed behavior: New strokes have streaking at the start Notes: The issue does not present itself if XWayland applications are launched from a GNOME session; Krita under XWayland seems to be immune to this problem for some reason, even if launched from a Plasma session Specs: KDE Plasma: 5.24.7 under Wayland KDE Foundation Libraries: 5.92.0 Qt version: 5.15.3 OS: Ubuntu 22.04.3 Linux kernel: 6.5.0-14-generic (64-bit) CPU: Intel Celeron N4100 (4x @1.10GHz) GPU: Intel UHD Graphics 600 (Mesa) RAM: 5,6 GB
Thank you for the bug report! However Plasma 5.24.7 is no longer eligible for support or maintenance from KDE; supported versions are 5.27, and 5.27 or newer. Please upgrade to a supported version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one. If you need support for Plasma 5.24.7, please contact your distribution, who bears the responsibility of providing support for older releases that are no longer supported by KDE. If you can reproduce the issue after upgrading to a supported version, feel free to re-open this bug report.
I upgraded to Plasma 5.27.10 to reproduce the issue... still getting streaking in Xournal++. UPDATED SPECS: KDE Plasma: 5.27.10 under Wayland KDE Foundation Libraries: 5.104.0 Qt version: 5.15.3 OS: Ubuntu 22.04.3 Linux kernel: 6.5.0-14-generic (64-bit) CPU: Intel Celeron N4100 (4x @1.10GHz) GPU: Intel UHD Graphics 600 (Mesa) RAM: 5,6 GB
Created attachment 173878 [details] The input issue in question (demonstrated with Xournal++)
The issue is still present as of version 5.27.11. Also, Krita, an X11-only application, turned out to be affected in contradiction to previous observations.
(In reply to petra_m_ from comment #3) > Created attachment 173878 [details] > The input issue in question (demonstrated with Xournal++) I'm confused by the video. Does the issue happen randomly?
(In reply to Vlad Zahorodnii from comment #5) > (In reply to petra_m_ from comment #3) > > Created attachment 173878 [details] > > The input issue in question (demonstrated with Xournal++) > > I'm confused by the video. Does the issue happen randomly? The first instance shown is native Wayland while the second is XWayland. I have a global menu applet running on the panel at the top with which GTK Wayland apps don't cooperate with. If you see the menu bar, that means you're looking at the XWayland instance. Rest assured, there is nothing in the video indicating that the issue pops up randomly; it is consistent and rather annoying.
Changed affected version to 6.1.5 as it is also affected by the bug (tested with a KDE Neon live session). It should be added that only tablet PCs are affected by the issue; title has been edited to reflect that fact
Changed affected version to 5.2.6 (tested on a KDE Neon live session)
My apologies for the typo; the actual latest affected version is 6.2.5
Created attachment 177625 [details] Additional demonstration of the issue using Krita Added an additional demonstration of the issue using Krita, a Qt/KF-based and (as of yet) X-only application, to prove the issue affects every XWayland application. Two brushes were used for testing, one with and one without a pressure curve respectively.
After seeking input from users it was found out that the bug only affects tablet PCs using the Microsoft Pen Protocol (MPP) as users with Wacom-compatible devices weren't able to reproduce the issue.
I can reproduce with my HP convertible (Envy x360 15-ey0xxx; uses MPP2). Xournal++ has an option to ignore the first n stylus events under Stylus -> Artifact Workaround. For me, setting that to 1 fixes it.
Confirmed on the today's neon-unstable and Lenovo Yoga C940's embedded tablet. In Krita and `WAYLAND_DISPLAY= kolourpaint` the result is like on the reporter's image When kolourpaint is run in Wayland mode, the result is correct. The aritfacts look like some part of XWayland protocol tries to emulate long-press-right-button and hence drops a bunch of tablet events in the beginning of the stroke. These events never reach the application.
It should be reiterated that the issue is not present under other Wayland compositors such as mutter and labwc.
(In reply to Dmitry Kazakov from comment #13) > The aritfacts look like some part of XWayland protocol tries to emulate > long-press-right-button and hence drops a bunch of tablet events in the > beginning of the stroke. These events never reach the application. Do you know whether the emulation code runs depending on the device capabilities? Maybe kwin doesn't send some information about the tablet, which results in that behavior? Not sure what else it can be without being to reproduce the issue myself.
(In reply to Vlad Zahorodnii from comment #15) > (In reply to Dmitry Kazakov from comment #13) > > The aritfacts look like some part of XWayland protocol tries to emulate > > long-press-right-button and hence drops a bunch of tablet events in the > > beginning of the stroke. These events never reach the application. > > Do you know whether the emulation code runs depending on the device > capabilities? Maybe kwin doesn't send some information about the tablet, > which results in that behavior? Not sure what else it can be without being > to reproduce the issue myself. From what I was able to gather the XWayland component doesn't appear to handle tablet events separately from mouse events. There is a common pointerButton function which accepts KWin::PointerButtonEvent as its argument. I might be just searching in the dark here, though a lack of tablet-specific code in the XWayland bridge is not to be entirely ruled out as a culprit.
Created attachment 182271 [details] Demonstration of the dynamics-dependence of the bug using Gimp So far I've tried removing emulation code from input.cpp, putting guarding mechanisms on motion and pressure events as well as pressure reporting and preventing pointer events from being emitted as long as the stylus is in use but to no avail. However, I discovered that the issue is dependent on the presence of pressure dynamics (see attachment). Enabling pressure dynamics suppresses the bug, indicating a possible fallback mechanism, even in the absence of the aforementioned emulation code, that misbehaves on XWayland and is triggered unconditionally on Xournal++, hence the presence of both pressure dynamics and "ink leak".
Addendum to the previous comment: I found this out after accidentally breaking pressure reporting and experimenting with it later on. Breaking pressure reporting results in no strokes but only if the application requests pressure. Strokes will be accepted as long as pressure dynamics are disabled/not supported but will have ink leak, hence the conclusion that a - possibly undocumented - stylus input mechanism may exist.
Git commit dc7f670af3a08d1c26803dd435807854c99dceca by Vlad Zahorodnii. Committed on 23/06/2025 at 06:58. Pushed by vladz into branch 'Plasma/6.4'. Split tablet tool tip event data in two frames Xwayland processes tablet tool tip events immediately instead of waiting for the frame event. It can result in the corresponding down events having the wrong position or pressure. See also https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2032. Co-authored-by: Petra Mogyorósi <petra_m_@outlook.com> M +12 -4 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/dc7f670af3a08d1c26803dd435807854c99dceca