Created attachment 177558 [details] Page 1 is normal calibratoin screen, page 2 is the glitch when the cursor is hovered over SUMMARY In the past 2-6 weeks (possibly coinciding with an update), my Wacom Cintiq 22HD pen/touch tablet has not been functioning properly in KDE Plasma. I boot my Fedora 41 OS in Gnome, and it works properly - but when I boot into the Plasma 6.2.5 environment, there are issues. In Plasma, the pen input does not seem to move the cursor (or if it does, the cursor stays in an invisible corner of the screen and does not move with pen input, therefore it gives the illusion that the cursor is not responding). Moreover, the calibration option in System Settings > Drawing Tablet > Calbrate seems to have a display glitch (attached images) when the cursor is hovered over the window (previously via pen, now via mouse). I've noticed that this glitch seems to disappear transiently when using the print screen function (Spectacle), or by shifting the calibration window to another monitor (windows + shift + left/right arrow); when the window is placed again on the Wacom tablet's display and the cursor hovers over the window, the glitch comes back. For this reason, the attached images had to be taken via phone camera, and not digitally screenshotted. Also, no crash or error code appears when this process is done, so I'm not sure what further information I could provide. STEPS TO REPRODUCE Pen input not working properly 1. On booting in Fedora 41 KDE Plasma (6.2.5), the Wacom pen input simply does not work. It works if botted in Fedora 41 Gnome, but not in KDE Calibration display glitching 1. Boot Fedora 41 KDE Plasma. 2. Enter system settings > drawing tablet > calibrate 3. The calibration window should open on the Wacom tablet display; if on another monitor, move it to the wacom display using (windows + shift + arrow keys). 4. Hover the cursor over the calibration window. Previously done using the pen input, but now done using the mouse input now that the pen input does not seem to move the cursor. Regardless of moving the cursor via pen or mouse, the same display glitch occurs 5. The glitch temporarily goes away when using the print screen function (Spectacle) or moving the calibration window to another screen (windows + shift + left/right arrows). The glitch will return when hovering the cursor over the calibration window. Of note, the calibration window does not respond the pen or mouse clicks (therefore the calibration process is effectively stuck, although the crosshair may light up if hovered over). OBSERVED RESULT Pen input not working properly: The cursor does not seem to move with the pen input Calibration display glitching: the display output on the calibration window has the attached visual glitch and does not proceed with the calibration process (the crosshair may light up if hovered over, but the calibration process does not seem to move forward with mouse clicks). EXPECTED RESULT Pen input not working properly: The cursor should move with the pen input, and also click accordingly. Calibration display glitching: the display output on the calibration window should not have a display glitch and should proceed as intended with pen inputs. SOFTWARE/OS VERSIONS Windows: N/A macOS: N/A (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Fedora 41 / KDE Plasma 6.2.5 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 ADDITIONAL INFORMATION Kernel Version: 6.12.9-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processor: 16 × AMD Ryzen 7 7800X3D 8-Core Processor Memory: 46.1 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT
1) Do you use Gnome and Plasma on the same user account? 2) Does it work correctly on a new user account?
(In reply to duha.bugs from comment #1) > 1) Do you use Gnome and Plasma on the same user account? > 2) Does it work correctly on a new user account? 1) I do use Plasma and Gnome on the same account 2) A new account did not have the same issue. I used Plasma and Gnome on that new account, no problems in either. Moreover, an unrelated microphone issue also seems to have been resolved in the new account. Thank you - what would be the next step in narrowing the cause for the original account?
Update: The tablet calibration (System Settings > Drawing Tablet > Calbrate) seems to still have the same display glitch on the new user account. While the pen input is working on the new user account, the same display glitch (in the original post's attachment) occurs.
Another small update (especially for anyone who also has Wacom Tablet issues after attempting calibration in Plasma): Following https://forum.endeavouros.com/t/reset-pen-tablet-calibration/64464/7, I'm able to determine that Plasma creates a file (~/.config/kcminputrc) whenever the drawing tablet is calibrated; if the file doesn't exist, then it's using the default settings. By deleting this file, logging out, logging back in, and mapping the drawing area only to the tablet display, the tablet is more-or-less working as intended, obviously without the minor adjustments of proper calibration. This also explains the tablet works properly in Gnome (which doesn't use that kcminputrc file) or on a new user account (which isn't calibrated and is using default settings). The problem still arises when I try to calibrate the pen (on both the new or primary user accounts). The same visual glitch happens (as shown above), while, the calibration GUI does not proceed with pen inputs, and if the process is terminated (e.g. closing the settings window), a "~/.config/kcminputrc" file will be made with a calibration matrix that seems incorrectly mapped. Subsequent attempts to calibrate the pen won't work; the tablet seems to be using this screwed-up calibration matrix for inputs instead of the default as the point of reference, making proper pen inputs impossible to perform recalibration. The only remedy I found is as above: delete the kcminputrc file and reboot. Otherwise, here's the calibration matrix after attempting calibration in the Drawing Tablet settings GUI: CalibrationMatrix=9.5367431640625e-07,5.364418029785156e-07,1.9402554649744497e-12,0,1.2715657248918433e-05,7.152557373046875e-06,3.44934280790965e-12,0,0,0,1,0,0,0,0,1 I have limited understanding of matrices and how they're applied, but I think this reflects a heavy amount of x and y-axis compression, which is consistent with how the tablet improperly functioned after calibration. If that's true, it's hard to know if this improper calibration was due to the GUI's visual glitching/unresponsiveness leading to user-input-errors, or if it's a code-side bug. So there some progress on the actual function fo the tablet, but the I still have no idea where that visual glitch comes from or how to fix it.
I'm going to look into it soon, but thanks for all of the information! That glitch is very strange, and you're right that it probably explains why the calibration matrix is wacky. (Note to myself, but I think it would make sense to throw out obviously invalid calibration matrices to prevent this from happening again.)
> Also, no crash or error code appears when this process is done, so I'm not sure what further information I could provide. Can you run `systemsettings` in console to see if it does crash though? It worries me that something bugs out here and doesn't even have the courtesy of crashing :)
(In reply to Joshua Goins from comment #6) > Can you run `systemsettings` in console to see if it does crash though? It > worries me that something bugs out here and doesn't even have the courtesy > of crashing :) Hahaha fair! Sadly, I just tried running systemsettings in console and indeed there were no crashes
Quick update: it seems that as of KDE Plasma version 6.4.0, frameworks 6.15.0, QT 6.9.1, Fedora 42 the issue is resolved. The calibration works without a visual glitch and works as intended :)