Date: Wed, 01 May 2024 12:14:55 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 278682] x11/xidle: xidle doesn't trigger when dpms has blanked the screen Message-ID: <bug-278682-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278682 Bug ID: 278682 Summary: x11/xidle: xidle doesn't trigger when dpms has blanked the screen Product: Ports & Packages Version: Latest Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: Individual Port(s) Assignee: novel@FreeBSD.org Reporter: dev@mailcd.com Assignee: novel@FreeBSD.org Flags: maintainer-feedback?(novel@FreeBSD.org) 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 h= ave 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 f= ails to trigger. I believe this is caused by the patch implemented here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275761. 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 susp= end 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 rul= ed 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 workflo= w 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 installati= ons 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! --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278682-7788>