Arch Linux

kousu

Member

Registered: 2022-01-25

Posts: 9

DPMS in Console, at boot

Hello, I hope you're all well

I run X sometimes, but others use my console as a remote mainframe. When I run startx and walk away, "xset dpms" usually kicks in and turns the power off to the monitor by the time I get back. But if I just boot my machine and walk away the screen stays at the blank getty prompt forever. Can I get getty to blank and power down the screen as well?

I found these old (pre-systemd, if that makes a difference) threads which had no final resolution:

• https://bbs.archlinux.org/viewtopic.php?id=66306

• https://bbs.archlinux.org/viewtopic.php?id=214193

The wiki has:

• https://wiki.archlinux.org/title/Displa … th_setterm

I also gathered (from the wiki) that console blanking was disabled, but can be enabled by adding

consoleblank=60

to the kernel command line (60 being in seconds -- i.e. 1 minute).

The wiki, and the 4 year old commit it references, claim

Console blanking alone does not enable DPMS power saving.

However on my laptop it does seem to trigger power saving: my laptop's screen is fully off, and my external monitor says "No Signal" then turns off and sets its power light to orange, and then it takes a few seconds to wake back up, which is its usual behaviour when X suspends the screen.

I would like to understand how this all fits together better, and how to control it.

• is the wiki wrong now? Did consoleblank learn to trigger DPMS? Is setting consoleblank=something sufficient?

• what's the difference between "VESA vsync suspend mode" and "VESA powerdown mode" and "VESA hsync suspend mode"?

• how can I read back my console's current DPMS settings? i.e. what is the analogy to "xset q"?

• can I read it over ssh while the screen is suspended? maybe by reading a logfile? or is there some reason that's impossible?

• are there different DPMS settings *per* each /dev/tty*, or is there a single DPMS setting somewhere?

• how can I write to the DPMS settings at boot without X?

What I've Tried

I gathered, I can write settings using

setterm -blank 1 -powersave powerdown -powerdown 10

which should make the console blank after 1 minute, then DPMS should turn off the power after another 10 minutes. I tried it and it works! When I walk away, after a minute the screen goes blank; when I come back and press a key, it wakes back up.

But setterm doesn't seem to have any way to read back the current terminal settings.

Also, I can only issue this command if I log in and run it from the getty console, which is what I'm trying to avoid. If I run it over ssh, it tries to control my local terminal:

$ setterm --blank 1 --powersave powerdown --powerdown 10
setterm: terminal xterm-256color does not support --blank
setterm: cannot (un)set powersave mode: Inappropriate ioctl for device

and I suspect if I tried this in a boot script I would have the same problem because boot scripts don't have terminals attached. I'm not even sure where I would inject it -- a systemd .target? The old threads I found still talk about using /etc/rc.local.

The wiki also suggests I can get around this by redirecting setterm directly towards the /dev/tty* I want, like

setterm --powerdown 0 >> /dev/tty3

but this doesn't seem to be effective; while the example from the wiki using just --powerdown runs without error:

# setterm --powerdown 1 >> /dev/tty1
# 

it's not clear that it runs successfully; as far as I understand so far, --powerdown needs to be combined with --powersave powerdown to be effective. But that option gives the same error as before (when run over ssh):

# setterm --blank 1 >> /dev/tty1
setterm: terminal xterm-256color does not support --blank
# setterm --powersave powerdown >> /dev/tty1
setterm: cannot (un)set powersave mode: Inappropriate ioctl for device
# setterm --blank 1 --powersave powerdown --powerdown 10 >> /dev/tty1
setterm: terminal xterm-256color does not support --blank
setterm: cannot (un)set powersave mode: Inappropriate ioctl for device

The second thread suggested vbetool instead; I tried it:

# vbetool dpms suspend  # turns screen off, over ssh
# vbetool dpms on           # turns screen on
# vbetool dpms off           # turns screen off

but unlike setterm, this it only controls my laptop's built in display: my external monitor is still powered. Also, when booted with consoleblank=60, the kernel's blanking seems take precedence over "vbetool dpms on".

I poked around /sys and discovered that /sys/class/graphics/fb0/blank behaves like consoleblank:

# echo 0 >> /sys/class/graphics/fb0/blank  # wake the screen up
# echo 1 >> /sys/class/graphics/fb0/blank  # put the screen to sleep

and like consoleblank it controls both the laptop and the external monitor at the same time.

Unfortunately, it neither will let me read back the current value:

# cat /sys/class/graphics/fb0/blank 
#

I'm flailing. Can someone give me some pointers?

Last edited by kousu (2022-01-25 06:28:45)