Rant: running audio VU-meter increases my CO2 footprint

Martin Cracauer
5 min readMay 27, 2019

--

I mean I have seen some bugs in my life. Even produced some good ones. But this one, I mean, WTF people?

A couple months ago I noticed that the monitor on my workstation never power off anymore. Screensaver would go on, but DPMs (to do the poweroff) never kicked in.

I grovels the output of various tools that display DPMS settings, which as usual in Xorg were useless. Everybody said DPMS is on with a timeout. I even wrote my own C program to use every available Xlib API call and even the xscreensaver library calls. (should make it available) No go, everybody says that DPMs is on, enabled and set on a timeout. Didn’t matter whether I let xscreeensaver do the job or just the X11 server.

After a while I noticed that DPMS actually worked between starting my X11 server and starting all my clients. I have a minimal .xinitrc and start the actual session from a script, that is how I could notice. If I used a regular desktop login I wouldn’t have noticed. A server state bug was much more likely than a client bug.

Needless to say, all those DPMS status discovery tools output precisely the same before (DPMS working) and after (DPMS not working). I used a network controlled powerstrip on a script that grovels the tail of the xscreensaver output. Not a good solution, just better than nothing.

I have 3 monitor taking 200 watts combined. I estimate that I burnt an extra 700 kWh with just the monitors, and air conditioning comes on top, so let’s say a solid 1700 kWh. That means that this bug put a solid ton+ (2000+ lbs) into what is left of our atmosphere.

Actual bug

I only recently had time to debug, so I did a binary search on all the X11 clients that my session contains to see which one would disable DPMS when started. I had a feeling that this is somehow related to how everything now plugs into dbus and maybe generates events that way. That wouldn’t explain why the screensaver (black screen, but on) would activate, but DPMS would not.

So it turns out that the “meterbridge” program that I run my music through is the culprit. It is a pretty regular VU meter connecting to jackd. WTF? How can that be? Again I suspected some dbus interaction, since somebody needlessly hackded up the Debian install of jackd to interact with dbus. And a million things there are trying to go through some other idiotic sound transport indirection, you can even make endless loop of the emulation layers in Debian sound.

I then did a binary search on the source code of Meterbridge to see which section of code would trigger the bug (in the source code just add a long wait between different steps). The problem appeared when it entered the SDL event loop. Initializing SDL was all fine, just the loop was not. Wait, SDL? Why does this VU meter need SDL? Well, it was just a convenient way to get texture display in a window. They didn’t know how hare-brained SDL’s decision-making is.

Well here it is: https://stackoverflow.com/questions/39914670/sdl-pollevent-causes-screen-to-wake-up-after-xset-dpms-force-off

Why does SDL disable my screensaver by default?

Many applications using SDL are games or screensavers or media players where the user is either watching something for an extended period of time or using joystick input which generally does not prevent the screensaver from kicking on.

You can disable this behavior by setting the environment variable:SDL_VIDEO_ALLOW_SCREENSAVER=1 This can be set globally for the user or on a per-application basis in code.

In SDL 2.0.2 this can also be changed by setting the hint SDL_HINT_VIDEO_ALLOW_SCREENSAVER.

Additionally, SDL 2.0 provides the function SDL_EnableScreenSaver().”

OK, let that sink in for a moment. Some idiot thinks that ever program ever using this library should always have the screensaver disabled. It doesn’t occur to him/her that maybe games and video player authors not only know that they have to disable the screensaver in their code (as opposed to relying on some automatic thing in a library). It also doesn’t hit home that games and video players are almost always using multiple APIs, so there will already be a redirecting call in that software.

How braindead is this — exactly? Preface version:

Before I go into why that decision is pure stupidity I want to first point out how inept that whole affair has been conducted.

  • even assuming you actually want to disable the screensaver. They managed to screw that up. The screensaver still comes up and blanks the screen, with this SDL code. It is just that DPMS isn’t working anymore. So they get none of the imagined benefits in the first place.
  • In SDL’s version of reality DPMS was also unconditionally disabled when the program was running at all. Obviously games and video players are expected to re-activate the screensaver while you pause the game or video. I mean, come on. I have many paused videos on my desktop right now. Did the decision maker here ever use a computer?

How braindead — exactly

Okay, just out of the top of my head:

  • people who write games and video players (who have a legitimate need to disable screensaver) already know that they have to manually turn this on and off.
  • existing software already has calls to do that since they have to do that on all other APIs. No other API has ever been so braindead to do this unconditionally in a library displaying a picture.
  • you don’t want to do this in Xorg. Specifically, because all the status debug utilities are useless. Obviously there should also be a display about which programs that are currently running that are disabling screensaver and/or DPMS. Needless to say Xorg does not have that. xscreensaver and its library do, however. Three cheers to Jamie Zawinski, as always when sane X11 work is concerned.
  • finally, an environment variable is a bad way to deal with this. The problem is that the variable persists as programs fork(2) and exec(2) and you can easily end up invoking this option for another process where you didn’t intent to. Of course in this specific situation it’s fine since nobody ever would not want to turn this off. It doesn’t even work in the first place.

--

--

Martin Cracauer

Writing about programmer productivity, teambuilding and enabling a wide variety of different engineering personalities. CTO at www.thirdlaw.tech #lisp #freebsd