| Summary: | Multiple Plasma services report segfault crashes upon login | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kded | Reporter: | Kyle B. <ArcangelZero7> |
| Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | DaydreamerKite, kdelibs-bugs, nicolas.fella |
| Priority: | NOR | Keywords: | drkonqi, qt6, wayland |
| Version: | 6.7.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | https://crash-reports.kde.org/organizations/kde/issues/82332/events/255a875e2e6c450c809a50ec4bce079b/ | ||
|
Description
Kyle B.
2024-10-20 20:01:19 UTC
Attempting to uninstall wacomtablet-kcm6 did not resolve the issue. Affected services are: kded6, xdg-desktop-portal-kde, kactivitymanagerd, KDE Power Management System. They all report "closing unexpectedly" on every startup. The Plasma desktop environment still seems to load and operate normally otherwise, however. I have the exact same issue with the exact same tablet: the XP-Pen Deco Pro MW. If I have the XP-Pen drivers installed from the official site, I encounter the crashes as soon as I log in to my KDE session. If I don't have them installed and just rely on the default drivers that come with Fedora, log in will work fine. However, unplugging the tablet will cause the same crashes to suddenly occur. If I had to guess, KDE isn't liking this specific tablet getting disconnected. The official XP-Pen driver software hooking into the tablet might be counting as a tablet disconnect. There's so many KDE services crashing that I don't really know what or how to send debugging info for this. Operating System: Fedora Linux 41 KDE Plasma Version: 6.2.3 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.6-300.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7A38 System Version: 7.0 I'm glad you found my report, and thank you for adding your experience! You're right, I think our issue is specifically with: [KCrash Handler] #4 0x00007ff2563aa497 in QtWayland::zwp_tablet_pad_v2::handle_removed I suspect the same as you do: That somehow upon initializing the tablet, it counts as a "removal" first, and triggers this bug. The WEIRD thing is that simply logging out the user (not shutting down) and logging back in, will have a normal startup as expected. I tried removing the tablet's USB dongle before booting, and everything booted up normally as well. Weirdly, I did not encounter this bug when pulling the dongle during a running session. As a workaround, you can try either logging out and back in before starting your session, or maybe try removing the dongle first on first boot? I had to restart the proprietary driver when I did this too. Either way, it's a bit of a pain. :( Using XP-Pen's 3.4.9 driver at the moment. Maybe there's a way to reach out to them as well. (As one of my pen buttons does nothing, too lol.) But something definitely isn't playing right with QT! This seems like a reproducible bug with a consistent source, so I apologize if I'm doing this in error, but I'm going to set this bug as "CONFIRMED." (In reply to DaydreamerKite from comment #2) I'm able to start my session without crashes now! Pardon my poor reporting skills but one of several solutions may have fixed it: 1. I ran "zypper in -f plasma6-desktop libQt6WaylandClient6 libqt5-qtwayland libQt6Xdg*" to force reinstall those components. 2. I put the tablet's wireless dongle into a different USB port. It was in a USB 3.2 slot, now it's in a 3.0 slot? But I'm not sure if that made a difference. 3. I installed the .RPM version of XP-PEN's latest drivers, instead of the general purpose shell-script version they had previously. I sincerely hope any of this is helpful! (In reply to Kyle B. from comment #4) Thank you for looking into solutions and workarounds for the problem. Unfortunately, I don't think any of them prevent the problem from happening for me or at least get rid of the login crashes. 1. I had this problem with a relatively fresh install of Fedora 41 (all I did was updates and enabling rpmfusion before I installed the xp-pen driver), which is how I narrowed down that the tablet was involved on my end. Also, apparently DNF's way of doing a package reinstall is to basically do a same version upgrade, so it's hard for me to test if a true package reinstall would do anything. 2. I tried using different ports on my PC and still encountered the issue. However, I only have USB 3.1 ports and USB 2.0 ports. 3. I tried the RPM version of the driver (I was also initially using the install script) and still got the login crashes. I should probably mention that I'm using the wired connection instead of the dongle on my end. I think this might be what is causing a slight bit of differing behavior here since I can consistently (and multiple times per the same session) cause the crash by unplugging the tablet. I actually just discovered that I can also cause SDDM to crash by unplugging the tablet, but I can't be 100% sure if it's the same bug causing that. Again, thanks for looking into it further! So I finally had time to explore this more thoroughly and I managed to find a solid workaround that allows me to use the official XP-Pen driver without startup crashing.
I basically had to add a udev rule to make libinput ignore the tablet.
In /etc/udev/rules.d/99-ignore-my-device.rules, I used the following rule:
ACTION!="remove", KERNEL=="event[0-9]*", ATTRS{id/vendor}=="28bd", ATTRS{id/product}=="0934", ENV{LIBINPUT_IGNORE_DEVICE}="1"
For anyone having this problem and wanting to use the above workaround, you may want to find the device in "libinput list-devices" then check "udevadm info --attribute-walk --name=/dev/input/eventwhatever" to make sure the vendor and product attrs are the same. The same rule seems to have worked for both the dongle and the wired connection for me.
Figuring out this workaround led me to some interesting oddities regarding how the tablet is initially identified, though.
When the tablet is initialized normally, it will first show up as 3 devices: Hanvon Ugee Deco Pro MW Mouse, Hanvon Ugee Deco Pro MW Pen, and Hanvon Ugee Deco Pro MW Pad. (Hanvon Ugee is the parent company of XP-Pen).
Once the XP-Pen driver takes over, these 3 devices are disabled (if they are not already disabled by a udev rule) and some new devices are added: XP-Pen Pen, XP-Pen Mouse, and XP-Pen Eraser. These devices have a different product (0002), but have the same vendor.
Hope this helps.
Also, if there's any way for me to add debugging info for the original KDE Plasma crashing problem that still happens with the initial Hanvon Ugee device, please let me know.
(In reply to DaydreamerKite from comment #6) I realized I wasn't super clear on what the udev rule was disabling and I dunno if it's possible to edit comments. Oops. :( The udev rule is disabling the "Hanvon Ugee Deco Pro MW" devices that appear before the XP-Pen driver takes over. So if you currently have the XP-pen driver installed and you are checking for the vendor and product with udevadm info, make sure you are NOT looking at the "XP-Pen" devices. Sorry for any confusion there. *** This bug has been marked as a duplicate of bug 496048 *** |