SUMMARY Whenever my Logitech Anywhere MX mouse (connected via its own receiver, that is, USB) gets suspended, it gets disconnected and the following error is being logged into the system log: [code] org_kde_powerdevil[1269]: qt.core.qobject.connect: QObject::disconnect: Unexpected nullptr parameter [/code] STEPS TO REPRODUCE 1. Have a battery powered USB mouse connected 2. Make sure that no udev rules are disabling the autosuspend and that the usbcore.autosuspend kernel parameter is not being set on -1. 3. Start using the mouse OBSERVED RESULT Apparently at random times the mouse will get disconnected because of the above error. EXPECTED RESULT SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux x64 kernel 6.9.2-arch1-1 (available in About System) KDE Plasma Version: Plasma 6.1 KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Pretty sure the warning is a consequence, not the reason. I've seen this before, so I'll mark the bug report as confirmed.
My findings so far: Regardless whether a mouse was disconnected from within an operating system (e.g. by clicking Disconnect button in the applet) or externally (such as falling asleep on its own, or flipping a physical switch OFF), whenever Solid::DeviceNotifier::deviceRemoved signal is emitted, the corresponding (by its UDI) Solid device's backend object has already been destroyed; so that Core::onDeviceRemoved handler attempts to disconnect from a null pointer which produces a warning in qobject.cpp. Given that setBackendObject(nullptr) literally deletes the backend object, trying to disconnect is pointless. I'll remove those two lines.
Actually, I didn't even need to borrow a bluetooth mouse. Same code path is taken when disconnecting an Android phone, which is just as capable of reporting its battery levels.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/371
Git commit d78ecf012f8b15e6470445251a0b319368222fff by ivan tkachenko. Committed on 01/06/2024 at 17:44. Pushed by ratijas into branch 'master'. daemon: Don't disconnect from a null object Regardless whether a Bluetooth device with a battery was disconnected from within an operating system (e.g. by clicking Disconnect button in the applet) or externally (such as falling asleep on its own, or flipping a physical switch OFF), whenever the Solid::DeviceNotifier::deviceRemoved signal is emitted, the corresponding Solid::Device's backend object has already been destroyed; so that Core::onDeviceRemoved handler attempted to disconnect from a null pointer which produces a warning. Given that right before emitting the deviceRemoved() signal, the setBackendObject(nullptr) is called which literally deletes the device's backend object, there is no need to disconnect. M +3 -4 daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/d78ecf012f8b15e6470445251a0b319368222fff
Git commit b73b7dc317713d63aa4f230cb05b2bc16814bc1b by ivan tkachenko. Committed on 02/06/2024 at 14:54. Pushed by ratijas into branch 'Plasma/6.1'. daemon: Don't disconnect from a null object Regardless whether a Bluetooth device with a battery was disconnected from within an operating system (e.g. by clicking Disconnect button in the applet) or externally (such as falling asleep on its own, or flipping a physical switch OFF), whenever the Solid::DeviceNotifier::deviceRemoved signal is emitted, the corresponding Solid::Device's backend object has already been destroyed; so that Core::onDeviceRemoved handler attempted to disconnect from a null pointer which produces a warning. Given that right before emitting the deviceRemoved() signal, the setBackendObject(nullptr) is called which literally deletes the device's backend object, there is no need to disconnect. (cherry picked from commit d78ecf012f8b15e6470445251a0b319368222fff) M +3 -4 daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/b73b7dc317713d63aa4f230cb05b2bc16814bc1b