XPS 13: keyboard and touchpad dead after closing the lid

Closed the lid of my Dell XPS 13 (7390) to let it suspend, opened it back up later and could log in fine: screen came back, lock screen and everything. But then… nothing. Keyboard didn’t type, touchpad didn’t move the cursor. The machine looked perfectly alive, it just wouldn’t take any input. Only way out was a hard reset.

Digging into the logs

Since it happened again, I checked what the previous boot’s journal had to say about the suspend/resume cycle:

journalctl -b -1 --no-pager | grep -inE "suspend|resume|freeze"

The interesting part:

Jul 09 11:15:12 kernel: PM: suspend entry (s2idle)
Jul 09 11:15:13 kernel: Freezing user space processes
Jul 09 12:56:38 kernel: Freezing user space processes completed (elapsed 0.002 seconds)
Jul 09 12:56:38 kernel: PM: suspend exit
Jul 09 12:56:38 systemd-logind[1344]: Lid opened.
Jul 09 12:56:38 NetworkManager[1392]: device (wlp2s0): state change: ... -> activated

So the resume itself was completely clean, kernel says suspend exited fine, GNOME Shell came back, WiFi reconnected, everything kept logging normally for another couple of minutes. Then the log just… stops. No panic, no OOM killer, no shutdown sequence. Just silence until the hard reset. That matched what I saw: a system that resumed everywhere except in the one place I needed it to: input.

The culprit: s2idle

cat /sys/power/mem_sleep
# [s2idle] deep

Modern Dell XPS laptops default to s2idle (“Modern Standby”) instead of real S3 deep sleep. s2idle depends on every single driver correctly tearing down and reinitializing its hardware on resume — there’s no hard power cut to reset things. My touchpad is an I2C-HID device sitting behind i2c_designware, and the keyboard goes through the ancient i8042 PS/2 controller:

N: Name="AT Translated Set 2 keyboard"
S: Sysfs=/devices/platform/i8042/serio0/input/input3

N: Name="CUST0001:00 06CB:76AF Touchpad"
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/...

Both are well-known weak points for this exact bug on XPS 13 9370/9380/7390 — after a longer suspend, the I2C-HID or i8042 controller comes back without a working interrupt line, so input just silently dies while the rest of the system looks totally normal. It’s a widely reported issue, e.g. Ubuntu bug #1808957.

The fix

Turns out the hardware supports real S3 deep sleep too, it’s just not the default ([s2idle] deep — deep is listed as available). So instead of patching drivers or writing resume hooks, I just switched the default sleep state:

sudo vi /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"

sudo update-grub
sudo reboot

After reboot:

cat /proc/cmdline
# ... mem_sleep_default=deep

cat /sys/power/mem_sleep
# s2idle [deep]

Deep sleep does an actual hardware-level suspend rather than relying on every driver’s runtime PM code path being bug-free, so it’s a much more reliable resume, at the cost of a very slightly higher power draw while suspended. Worth the trade-off compared to hard-resetting a frozen laptop.

If forcing deep sleep ever caused other regressions on this hardware (some XPS owners report WiFi hiccups), the fallback would be to keep s2idle and add a systemd/system-sleep hook that reloads i2c_hid_acpi and resets i8042 right after resume. But so far, deep sleep alone has done the trick.