Something is keeping my X awake

Sun Jul 24 07:32:20 UTC 2022

On Sat, 23 Jul 2022 20:10:11 +0200 martin f krafft <madduck at madduck.net> said:

> Regarding the following, written by "Vladimir Dergachev" on 2022-07-21 at
> 17:28 Uhr -0400:
> >If any of such programs were terminated before they could restore 
> >the regular behaviour, the screen won't lock.
> 
> Nah, the problem is different. If I run `xscreensaver-command 
> -lock`, then the screen locks, but every few minutes, the password 
> screen will pop up, and time out, as if someone moves the mouse 
> every few minutes.
> 
> As Carsten suggested, it seems that it's Firefox. I've quit the 
> browser, and now `xset q` reports "Monitor is Off" (logged in over 
> SSH), which it hasn't done in a long time.

This is a recent thing in both chrome and firefox both - whenever they play any
media (video and even audio) they use the xcreensaver extension to keep the
screen alive (that or they use the freedesktop.org screensaver dbus api to ask a
window manager/desktop service to do this instead).

If you have a web page open in a tab somewhere that has a video - even not
playing then this happens. these days advertisements can be videos too... maybe
no audio but these also then keep the screen on if some ad is buried at the
bottom of the web page with a video.

i have had user reports of this now for the past 6+ months and they keep
steadily streaming in as a "your wm has a bug as my screen now doesn't turn
off". It's almost always chrome or firefox doing it. the stream client (and
games) also has an incredibly annoying bug that also disable screen blanking.
it's very persistent at it too. this covers the steam problem:

https://github.com/ValveSoftware/steam-for-linux/issues/5607  people are now
resorting to an LD_PRELOAD to fix it.

now what do the browsers do? they first try use the org.freedesktop.ScreenSaver
dbus api that has Inhibit/Uninhibit calls. I recently implemented this as
browsers have become persistent at this recently. As they prefer to use this it
seems first, then I can provide a UI for the user to override this inhibiting.
the UI is primitive right now but does the job.

But if this dbus service/api is not around... browsers use the XScreenSaver
extension (steam is worse - it literally fiddles with core x
blanking/screensaver etc. settings and can leave them in a mess sometimes). The
use XScreenSaverSuspend() from libXss to ask the xscreensaver to suspend
blanking. This suspension is releases when that client chooses to release it
on their own (browser just decided to - e.g. no more videos on a web page) or
when that client loses its connection to the xserver (you close/kill it). Thus
my very simple "try closing your browsers ... or steam". :)

like the LD_PRELOAD solution for SDL above - an LD_PRELOAD could be used for
libXss too to lock some clients out.

This very very very poor and unsociable behaviour has been irritating me a lot
of late. My move to support the dbus api above allows me now to override it in
both browser/steam cases, but the whole system is still vulnerable to abuse. i
had considered extending the x screensaver extension to have a window manager
like "owner" of the screensaver - e.g. your window manager or some desktop
environment service would at startup take ownership of the whole screensaver
and blanking infrastructure. after that it could do things like disable
suspension of the screensaver even if clients ask. it could also, i would hope,
be able to lock out other clients from messing with screesnaver/dpms etc.
settings (yes - this would make xset useless in  these situations). given
the amount of abuse going on here... it's about time some of this was reigned
in. adding to the Xss extension is the cleaner solution allowing also to reign
in control of core blanking and dpms too. I have also considered that there
might be a need to reign in control of xrandr as well to only allow a single
client control over changing settings. perhaps all of this belongs in xfixes? i
haven't decided. it's an ongoing background thought right now.

> This of course now begs the question: what is the browser doing to 
> keep X awake by jiggling XScreensaver regularly, and worse yet: 
> preventing DPMS shutoff. I am not watching videos, but I do havem 
> plenty open tabs. Is any one of them able to keep my screen busy 
> like this?
> 
> And how can I disable that? I generally keep the browser running, 
> and don't want to have to shut it down every time I want to save 
> energy and screen lifetime during idle periods.
> 
> A [web search](https://search.brave.com/search?q=firefox+dpms) seems 
> to only touch the opposite problem, i.e. people seeking to disable 
> DPMS from Firefox.
> 
> Thanks!
> 
> -- 
> @martinkrafft | https://matrix.to/#/#madduck:madduck.net
>   
> "da haben wir es also: eine kirchliche ordnung mit priesterschaft,
>   theologie, kultus, sakrament;
>   kurz, alles das, was jesus von nazareth bekämpft hatte..."
>                                                   - friedrich nietzsche
>   
> spamtraps: madduck.bogus at madduck.net

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com