Bug 486763

Summary: On login, "Toggle Touchpad" shortcut always thinks touchpad is on, even if touchpad is actually off
Product: [Plasma] kwin Reporter: ali.rezayinejad
Component: inputAssignee: 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: Version Fixed In: 6.1.5
Sentry Crash Report:

Description ali.rezayinejad 2024-05-08 04:50:52 UTC
***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
(On Wayland, with the touchpad applet disabled in system tray. Using the "Touchpad Toggle" keyboard shortcut (Fn+F9) to disable the touchpad.)
After a reboot with the touchpad being disabled from a previous session, pressing the "Touchpad Toggle" keyboard shortcut to enable it does not work initially. Pressing it for a second time enables the touchpad and from then on everything works as expected.

My guess is that after booting, the system expects the touchpad to be enabled, hence the first time "Touchpad Toggle" is pressed, the message to disable it is broadcasted regardless of its actual state, resulting in no change in the touchpad status.

STEPS TO REPRODUCE
1. Use the "Touchpad Toggle" keyboard shortcut to disable the touchpad.
2. Reboot.
3. Press the "Touchpad Toggle" keyboard shortcut once to enable the touchpad.

OBSERVED RESULT
No changes in touchpad status.

EXPECTED RESULT
Touchpad should be enabled with the first button press.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Arch
(available in About System)
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Pavel Dobiáš 2024-06-27 13:15:25 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.
Comment 2 Nate Graham 2024-07-30 17:30:24 UTC
> 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?
Comment 3 ali.rezayinejad 2024-08-01 04:20:31 UTC
(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.)
Comment 4 Nate Graham 2024-08-01 15:39:44 UTC
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?
Comment 5 ali.rezayinejad 2024-08-06 20:10:05 UTC
(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.
Comment 6 Nate Graham 2024-08-07 19:05:50 UTC
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.
Comment 7 Nate Graham 2024-08-07 19:06:39 UTC
.
Comment 8 ali.rezayinejad 2024-08-10 07:47:08 UTC
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.
Comment 9 Nate Graham 2024-08-14 22:40:31 UTC
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.
Comment 10 Nate Graham 2024-08-14 22:40:47 UTC
I'll look into fixing this at some point in the near future.
Comment 11 ali.rezayinejad 2024-08-18 11:02:32 UTC
No problem sir! Thank you for looking into it.
Comment 12 Bug Janitor Service 2024-09-02 11:07:06 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6344
Comment 13 Vlad Zahorodnii 2024-09-02 14:24:04 UTC
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
Comment 14 Vlad Zahorodnii 2024-09-02 14:40:44 UTC
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
Comment 15 Nate Graham 2024-09-16 23:08:48 UTC
*** Bug 399186 has been marked as a duplicate of this bug. ***