Category: laptop

Posted on
by

Systemd version 256 has been rolled out in several distributions recently, including Arch and Debian and variants. It adds a feature where user sessions are frozen when the system enters sleep, but in my case, running Manjaro Linux with KDE on a Gen 1 Lenovo T14, this meant that when the system woke, the screen remained frozen and required a reboot by switching to the command line with Ctrl-Alt-F3.
At first I perhaps unfairly assumed that this was KDE as it affected the desktop but left the mouse working and indeed the system accessible with through the console, but after a bit of digging around in the system journal with journalctl -b-1 -p4 --no-pager (a really useful command that I didn't know before), I found the error Cannot start frozen unit Session 10 of User xxxxx from systemd.
Searching on that brought up the problem and conclusively pointed at the 256 update, and a solution, or at least a fix until the issue is fixed.
The fix is to add an override to the systemd-suspend service. This doesn't actually have a service file in /etc/systemd/system in Manjaro at least, so you need to create the directory /etc/systemd/system/systemd-suspend.service.d and create an override file called disable_freeze_user_session.conf with these contents:

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"

Save this, and restart systemd with systemctl daemon-reload.
This disables user freeze on sleep and for me at least, reverted to the previous behaviour. I found that a lot of the examples mentioned Nvidia video hardware, which I don't have, so it's probably a wider issue than I've found.
I've added a comment to the Github issue.

Posted on
by

(Without disabling everything else)

My main laptop is a Lenovo X1 Yoga 2nd Gen running Manjaro KDE Plasma. Lovely machine and does what I want it to do. As a Yoga device, it has a touchscreen, which I don't use a lot and have often thought of disabling.

The other day, the laptop had the wrong kind of drop, which has cracked the touchscreen in the corner. This hasn't affected the display at all but has messed up the touchscreen input so that it keeps getting random signals that trigger events, which was sufficiently intrusive to need to turn off the touchscreen

The first thing I found was this from the Manjaro Forum. Tl;dr, disable the module that powers the touchscreen with sudo modprobe -r usbhid and make it permanent by creating a blacklist at /etc/modprobe.d/blacklist/wacom that contains the following:

blacklist wacom
blacklist usbhid

and restart.
This worked fine when just on the laptop, but I have a multi-monitor desktop setup that has a USB mouse and keyboard, and when I came to start work this morning, neither worked. Enabling usbhid in the blacklist just brought the spurious touches back.
There was going to be something that creates rules to selectively allow USB devices, and that something is USBGuard.
The Arch Wiki documents it well, but basically install with pacman -Sy usbguard (or your software manager of choice), and create your ruleset as root with usbguard generate-policy > /etc/usbguard/rules.conf.
This lists all your connected devices as allowed, including the touchscreen:

allow id 056a:50b6 serial "" name "Pen and multitouch sensor" hash "B1HYEaAtN9VpnKbIK5GQeZFfg3XN7EAAeQUvTx5zIhk=" parent-hash "jEP/6WzviqdJ5VSeTUY8PatCNBKeaREvo2OqdplND/o=" via-port "1-10" with-interface { 03:00:00 03:00:00 } with-connect-type "not used"

To disable it, change allow to block to stop it being processed, or reject to stop the device being loaded at all. At the moment I have it set to block.
Start USBGuard with systemctl start usbguard and enable it on boot with systemctl enable usbguard.
This stopped the touchscreen responding but kept the USB keyboard and mouse working. I haven't tested it across a reboot yet but I can't see why it won't continue to work.