Overview: In order to lock and suspend my session, I was using a combination of the xss-lock and xidle utilities. xss-lock is used to lock my session and xidle is used to suspend my session. The reason for multiple utilities is so I can have independent timers - xss-lock will lock according to dpms screen blanking, and the session will fully suspend after a separate timer expires on xidle. When dpms blanks my screen and the session is locked with xss-lock, xidle fails to trigger. I believe this is caused by the patch implemented here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275761. I have not had a chance to test the workflow with an unpatched version of xidle, but the behavior seems consistent with limiting the scope of XScreenSaverNotifyEvent->state in the patch. My hardware: Thinkpad T480 - non-dGPU model FreeBSD 14 - using LATEST packages My setup: xss-lock would trigger i3lock to lock my session based on dpms settings set in my .xinitrc. xss-lock is triggered with the following command: xss-lock --transfer-sleep-lock -- i3lock --nofork My dpms settings in my .xinitrc are: xset s 1800 1800 xset dpms 1800 1800 1800 And finally my xidle command is initiated with: xidle -program "/usr/local/bin/sudo /usr/sbin/zzz" -timeout 3600 This effectively blanks my monitor after 30 minutes which will trigger xss-lock to lock the session with i3lock. After another 30 minutes xidle is supposed to initiate the /usr/sbin/zzz command, but it never fires. Testing: A simple test can confirm this bug by setting your dpms settings to a short timeout with something like the following in your .xinitrc: xset s 5 5 xset dpms 5 5 5 And then in a terminal running in your X session, setup xidle with the following command: xidle -program "/usr/local/bin/sudo /usr/sbin/zzz" -timeout 10 You can also pick a different program to trigger from xidle if suspending is too cumbersome for testing. Workaround: Prior to using xidle I was using xautolock with the -detectsleep flag from previous Linux installations. xautolock's -detectsleep with sysctemctl suspend had no issues when resuming, but on FreeBSD the -detectsleep flag appeared to fail and the machine would suspend twice (once right after resuming). I ruled out a hardware/apm/acpi issue since suspend works perfectly when triggered by xidle or manually. This led me to search for alternatives which is where I discovered xidle. With the current issue with xidle I have revised my locking/suspend workflow to use the following commands: xautolock -time 45 -locker "i3lock -n" -detectsleep This will lock the session with i3lock after 45 minutes. Given my previous tests, I doubt the -detectsleep flag is working, but leaving it in makes the configuration portable with Linux installations. To suspend, I use xidle like so: xidle -program "/usr/local/bin/sudo /usr/sbin/zzz" -timeout 3600 This will suspend the machine after 1 hour. Closing thoughts: My current workaround is satisfactory for the moment, but I do prefer to let xss-lock listen to dpms events as it is more portable with Linux installations making my previous workflow cross-compatible (since xss-lock also listens to systemd events). If there is any additional information I can provide please let me know! Thanks!