macsmc-input: poll MSLD for lid state, fix spurious s2idle wake

[areofyl]

SMC lid events (0x7203) show up in the SMC firmware syslog but never actually get delivered to Linux via RTKit notifications. So lid open/close is completely invisible to userspace and logind never knows to suspend.

This switches to polling the MSLD key every second with a delayed_work and reporting SW_LID changes to the input subsystem. Added a 2-poll debounce because MSLD bounces during DP disconnect events.

Also fixes the spurious wake issue. The SMC fires a fake BTN_TOUCHID press+release within ~1ms of entering s2idle (this started happening after plugging in an external monitor, presumably changes some internal SMC state). The original upstream code passes that straight to pm_wakeup_dev_event which wakes the system instantly. Fixed by skipping the first 2 button events after pm_prepare, real presses after that go through normally.

Other stuff:

• Added a remove callback, the old driver had none so unloading left a dangling notifier and a running delayed_work
• pm_complete now cancels and reschedules lid_work so polling survives suspend/resume cycles
• Exposed MSLD as a sysfs attribute (msld_state) for debugging
• Initialized pending_lid_state from the actual MSLD read at probe so the first poll doesn't report a phantom state change

Tested on M1 MacBook Air (J313), fairydust 6.18.10. Lid close/open, suspend, power button wake all working.

[oliverbestmann]

With this patch, my m1pro does not wake up automatically if i open the lid (with no external screen connected). It did that before. I then need to press the power button for ~1 second for it to turn on again. Previously a short tap on the power button was enough.

[areofyl]

With this patch, my m1pro does not wake up automatically if i open the lid (with no external screen connected). It did that before. I then need to press the power button for ~1 second for it to turn on again. Previously a short tap on the power button was enough.

Yeah I'm sorry about that. Lid wake is a known limitation of s2idle on Apple Silicon. Workqueues are frozen during suspend so the kernel can't poll the lid sensor. If it seemed to work before, it was likely a coincidence (the SMC fires spurious events that can wake the system around the same time). There's no clean fix for this without upstream changes to how the SMC delivers lid events.

[jannau]

On which device are you seeing this? I've never noticed this before and just tested this with uart and no_console_suspend on M1 Macbook Air and 14-inch Macbook Pro without seeing any issues. There is a single lid close event when closing the lid which results in s2idle (if configured so). Then nothing happens until the lid is opened which results in a single lid open event.

Please provide a description on how you noticed the issue and how your device behaves ideally with relevant kernel logs around suspend / lid events. I assume you added a log statement in macsmc_input_event(). Please provide the patch as well.

[areofyl]

This is on an M1 MacBook Air (t8103) running Gentoo with the fairydust kernel. I don't have UART set up so my logs are from journalctl, but I can try to get better captures.

The issue I hit was the SMC firing a spurious BTN_TOUCHID press+release about 1ms after entering s2idle, which would immediately wake the system back up. The ignore counter in my patch skips those first 2 events so the system stays asleep.

I didn't realize lid events were being delivered reliably via notifications on other machines. On mine they seemed inconsistent, which is why I added MSLD polling. If lid wake works fine through the existing event path on MBA and 14-inch MBP, this polling approach is probably wrong and I should narrow the fix to just the spurious button handling.

I'll try to get proper logs with the stock kernel showing the spurious wake and post them here.