[Bug]: Pointer clicks stop working after S3 resume on linux-cachyos with KDE Wayland

### Kernel

7.2.4-3-cachyos

### Desktop Environment / Window Manager

KDE Plasma

### CPU

Intel(R) Core(TM) i5-4310U (4) @ 3.00 GHz

### GPU / Driver

GPU: Intel Haswell-ULT Integrated Graphics Controller / Driver: i915

### Description

After S3/deep suspend and resume, pointer movement continues to work but all pointer button clicks stop working in the KDE Plasma Wayland session.

The failure affects both the internal AlpsPS/2 ALPS GlidePoint touchpad and an external USB mouse simultaneously. The pointer can still be moved normally, but left/right/middle clicking stops working.

The issue is currently consistently or nearly consistently reproducible after S3/deep resume on `linux-cachyos 7.2.4-3`. It has also occurred on `linux-cachyos-lts 6.18.50-3`, but much less frequently.

The same failure can occasionally occur immediately after a normal boot, but this is much less frequent than the suspend/resume case.

The behavior strongly suggests a pointer-button handling/routing problem after resume rather than loss of the touchpad device itself.

### Steps to Reproduce

1. Boot CachyOS into a KDE Plasma Wayland session.
2. Use the system normally.
3. Suspend the system using S3/deep suspend.
4. Resume the system.
5. Move the pointer and try clicking with the internal touchpad.
6. Try clicking with an external USB mouse.

On affected resumes, pointer movement continues normally, but pointer clicks stop working on both pointer devices.

The desktop may also behave as if a pointer/drag state is stuck, for example while selecting text.

### Expected Behavior

After S3/deep resume, the touchpad and external mouse should continue to provide normal pointer movement and pointer button clicks without requiring a session restart or device reinitialization.

### Actual Behavior

After resume, pointer movement continues to work, but pointer button clicks stop working system-wide for both the internal ALPS touchpad and the external USB mouse.

The ALPS touchpad remains present as `/dev/input/event13`, KWin reports it as `enabled=true`, and libinput continues to receive `POINTER_MOTION` events.

The problem is immediately recoverable by using KDE's Touchpad Toggle:

Touchpad Off → Touchpad On

After this, clicking works again on both the touchpad and external USB mouse.

Logging out of KDE also restores clicking.

Reloading `psmouse` does not provide a permanent fix.

### Logs / Error Messages

https://paste.cachyos.org/p/dd6c751.log

### Additional Context

Hardware:

* Dell Latitude E5440
* Intel Core i5-4310U (Haswell)
* Internal touchpad: AlpsPS/2 ALPS GlidePoint
* Touchpad interface: i8042/serio1
* External USB mouse is also affected

Software:

* CachyOS
* KDE Plasma Wayland
* Plasma 6.7.5-1.1
* KWin 6.7.5-1.1
* libinput 1.31.3-1.1
* linux-cachyos 7.2.4-3
* linux-cachyos-lts 6.18.50-3

Important observations:

* After a failing resume, the ALPS device remains present as `/dev/input/event13`.
* udev reports the device through `i8042/serio1`.
* KWin reports the ALPS device as `enabled=true`.
* `libinput debug-events --device /dev/input/event13` continues to receive `POINTER_MOTION` events after the failure.
* The external USB mouse loses clicking at the same time, while pointer movement remains usable.
* No obvious `psmouse`, `i8042`, or `serio` reset/timeout/disconnect error was found in the relevant kernel logs.
* KWin logged after an affected resume:
`Libinput: event13 - AlpsPS/2 ALPS GlidePoint: client bug: event processing lagging behind by 3158ms, your system is too slow`
* Similar event-processing lag warnings were logged for the Power Button devices.

Kernel comparison:

* `linux-cachyos 7.2.4-3`: issue is currently highly reproducible after S3 resume.
* `linux-cachyos-lts 6.18.50-3`: issue also occurs, but less frequently.

A related upstream KDE report exists:
https://bugs.kde.org/show_bug.cgi?id=524322

A separate CachyOS/KDE Wayland report describes a very similar symptom: the pointer continues moving but mouse clicks stop reaching the application, and restarting kwin_wayland restores clicking. This appears relevant as corroborating evidence that the failure may be in KWin/Wayland input handling rather than the physical pointing device.

Related report:
https://www.reddit.com/r/cachyos/comments/1wej64s/kde_wayland_mouse_clicks_broken_on_linuxcachyos/

This appears to be an issue in the pointer-button/input handling path after S3 resume, potentially involving the interaction between the kernel resume path and KWin/libinput.

The goal is to identify the underlying cause rather than use a post-resume recovery workaround.

### Additional low-level evidence from the affected S3 resume

I found an additional kernel-level anomaly in the same suspend/resume cycle.

The system entered deep S3 suspend:

PM: suspend entry (deep)

During the resume path, the kernel reported:

[FW BUG] TSC ADJUST differs: CPU0 0 --> 6702761788241. Restoring

The message appeared between:

ACPI: PM: Preparing to enter system sleep state S3

and:

ACPI: PM: Low-level resume complete

The surrounding timestamps were:

[2558.316749] PM: suspend entry (deep)
[2559.192025] ACPI: PM: Preparing to enter system sleep state S3
[2559.196794] Disabling non-boot CPUs ...
[18446744048.959255] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> 6702761788241. Restoring
[2559.205973] ACPI: PM: Low-level resume complete
[2559.213400] ACPI: PM: Waking up from system sleep state S3
...
[2561.431962] PM: suspend exit

The timestamp of the TSC warning is anomalous compared with the surrounding monotonic timestamps, which remain around 2558-2561 seconds.

In the affected session, KWin also reported immediately after resume:

Libinput: event13 - AlpsPS/2 ALPS GlidePoint: client bug: event processing lagging behind by 3158ms, your system is too slow

Similar event-processing lag was reported for the two Power Button input devices.

The pointer-click failure then occurred:

* pointer movement continued
* clicking failed on the internal ALPS touchpad
* clicking also failed on an external USB mouse
* toggling KDE Touchpad Off → On restored clicking system-wide

I am wondering whether the TSC/clocksource anomaly during S3 resume could contribute to the event timing/processing problem observed by KWin/libinput, or otherwise expose a resume-time race in the input stack.

The same click-loss problem also occurs, although less frequently, with linux-cachyos-lts 6.18.50-3, so I am not assuming this is exclusively a 7.2.x kernel regression.

Please consider investigating:

* TSC_ADJUST changes during S3 resume on this Haswell platform
* clocksource/timekeeping behavior across the resume boundary
* whether the anomalous TSC state can affect input event timestamps or libinput/KWin event processing
* interaction between the resume-time clock correction and KWin's pointer-button handling

Start by reproducing the S3 resume sequence and reviewing the linked kernel, KWin, and libinput logs, especially the TSC ADJUST warning and event-processing lag. Compare the affected 7.2.4-3 and 6.18.50-3 kernels with the related KDE report, then trace whether resume-time timing reaches pointer-button handling. Done means the cause is identified and the failure is fixed without the touchpad toggle or logout workaround.

Written by the indexing model from the issue text.