Summary: | On login, "Toggle Touchpad" shortcut always thinks touchpad is on, even if touchpad is actually off | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | ali.rezayinejad |
Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | akselmo, bugseforuns, nate, pavel23dob |
Priority: | NOR | ||
Version: | 6.1.4 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/a1a77f0dcd5929894d32401ca8d60c2fd257f4c1 | Version Fixed In: | 6.1.5 |
Sentry Crash Report: |
Description
ali.rezayinejad
2024-05-08 04:50:52 UTC
I use a different shortcut to toggle touchpad (Meta+F4), that I've manually set in the system settings, and I can confirm this issue happens to me as well. I am on Fedora 40 with KDE Plasma 6.1. > with the touchpad applet disabled in system tray
When you say "disabled" do you mean "entirely missing"? Because the widget was deleted again for Plasma 6, and even if it wasn't, it's not supposed to be appearing in there at all on Wayland.
Are you using a 3rd-party or custom touchpad toggle widget?
(In reply to Nate Graham from comment #2) > > with the touchpad applet disabled in system tray > > When you say "disabled" do you mean "entirely missing"? Because the widget > was deleted again for Plasma 6, and even if it wasn't, it's not supposed to > be appearing in there at all on Wayland. > > Are you using a 3rd-party or custom touchpad toggle widget? I'm sorry. I didn't realize it was removed from Plasma 6. Also, I am not using any 3rd-party or custom touchpad toggle widgets. Regardless, the inconsistency seems to be independent from the touchpad applet. This should be reproducible on all laptops running Plasma. (As long as they don't have 3rd-party applications managing their touchpad.) My point is that in Plasma 6, there is no touchpad applet. We deleted it. So I'm very curious to know what exactly you're using. Can you attach a screenshot of it? (In reply to Nate Graham from comment #4) > My point is that in Plasma 6, there is no touchpad applet. We deleted it. So > I'm very curious to know what exactly you're using. Can you attach a > screenshot of it? I'm not using anything. I press Fn+F9 to toggle the touchpad, that's all. Got it, no widget involved. I can't reproduce this with current git master. My laptop doesn't have a keyboard key to toggle the touchpad, so I set the Meta+Ctrl+Alt+H shortcut to do it in System Settings > Keyboard and rebooted. The result: touchpad still disabled on login. Can you try setting a custom shortcut for this in System Settings > Keyboard and see if it works? If it works, it means that KDE's code is working properly, and what's broken is actually the built-in feature provided by your laptop's firmware. . I changed the Touchpad Toggle shortcut, same thing. The problem is not that the status of the touchpad doesn't carry over after reboots. If it was enabled before the reboot it remains enabled, if it was disabled it stay disabled. That part works perfectly. Here is the inconsistency in more detail: There are 2 scenarios 1) The touchpad was enabled before the reboot. 2) The touchpad was disabled before the reboot. Now, lets examine the two scenarios after the reboot: 1) The system boots, the user presses the "Touchpad Toggle" keyboard shortcut. The touchpad switches to disabled. Perfect, makes sense. 2) The system boots, the user presses the "Touchpad Toggle" keyboard shortcut. Nothing happens. The user presses the "Touchpad Toggle" keyboard shortcut again. The touchpad switches to enabled. This makes sense as well. but the first time the shortcut was pressed it was ignored. The second scenario is the unexpected behavior. It seems plasma assumes the touchpad is enabled on boot regardless. In the second scenario after the first time the user presses the shortcut it switches to disabled. The system sees that it was already disabled. No change takes place, no popup displays for the status change. But now the assumption matches the true status of the touchpad and everything is back to normal if the uses presses the shortcut again. Thanks, I completely missed that in the original description of the issue, so sorry! I can confirm it. This appears to be because m_touchpadsEnabled gets initialized to true in input.h, and then the actual enablement status is not evaluated before the value of it gets manipulated by using the "Toggle Touchpad" shortcut. I'll look into fixing this at some point in the near future. No problem sir! Thank you for looking into it. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6344 Git commit e910dcb9ed699acc70a6d3983863276cec2b16de by Vlad Zahorodnii, on behalf of Akseli Lahtinen. Committed on 02/09/2024 at 14:23. Pushed by vladz into branch 'master'. input.cpp: initialize m_touchpadsEnabled in addInputDevice m_touchpadsEnabled gets initialized to true in input.h, and the actual status of the device is not evaluated until the toggleTouchpads setting is pressed. This fixes the issue by removing m_touchpadsEnabled and refactoring the toggling method. OSD is handled by their respective enable/disable Touchpads methods. M +46 -16 src/input.cpp M +0 -1 src/input.h https://invent.kde.org/plasma/kwin/-/commit/e910dcb9ed699acc70a6d3983863276cec2b16de Git commit a1a77f0dcd5929894d32401ca8d60c2fd257f4c1 by Vlad Zahorodnii. Committed on 02/09/2024 at 14:40. Pushed by vladz into branch 'Plasma/6.1'. input.cpp: initialize m_touchpadsEnabled in addInputDevice m_touchpadsEnabled gets initialized to true in input.h, and the actual status of the device is not evaluated until the toggleTouchpads setting is pressed. This fixes the issue by removing m_touchpadsEnabled and refactoring the toggling method. OSD is handled by their respective enable/disable Touchpads methods. (cherry picked from commit e910dcb9ed699acc70a6d3983863276cec2b16de) M +46 -16 src/input.cpp M +0 -1 src/input.h https://invent.kde.org/plasma/kwin/-/commit/a1a77f0dcd5929894d32401ca8d60c2fd257f4c1 *** Bug 399186 has been marked as a duplicate of this bug. *** |