Am trying to get my Pi5 Bookworm Desktop (no GUI as such-- just some fullscreen libdrm apps) to support screen blanking. This has proved far more challenging than anticipated. "setterm" with blanking-aware DRM apps seems like the right approach, but no luck. Here are the steps I used to identify the issues (though am no closer to a solution):

After a fresh boot:

$ sudo bash -c 'setterm --term linux --blank </dev/console'
shows 0: blanking inactive
$ sudo bash -c 'setterm --term linux --blank 1 </dev/console'
never does anything after a minute or hour. neither does adding powerdown and/or powersave to it.
$ sudo bash -c 'setterm --term linux --blank force </dev/console'
blanks the screen
$ exec libdrm application to enumerate the current state
crtc[3]: id=97 fb-id=299 x=0 y=0 w=3440 h=1440 ACTIVE=0 MODE_ID=301 OUT_FENCE_PTR=0 VRR_ENABLE
the ACTIVE=0 is apparently a result of the screen blanking
however-- the screen then unblanks upon process termination (after the DRM-fd is closed)

$ exec libdrm application to enumerate the current state a second time
crtc[3]: id=97 fb-id=299 x=0 y=0 w=3440 h=1440 ACTIVE=0 MODE_ID=301 OUT_FENCE_PTR=0 VRR_ENABLE
correctly reports ACTIVE=1 since screen is now visible

$ sudo bash -c 'setterm --term linux --blank </dev/console'
shows 1: setterm still thinks the screen is blank
$ sudo bash -c 'setterm --term linux --blank force </dev/console'
leaves screen visible because setterm thinks the screen is already blank
$ sudo bash -c 'setterm --term linux --blank poke </dev/console'
no visible change since screen already visible, but ...
$ sudo bash -c 'setterm --term linux --blank </dev/console'
shows 0: setterm now thinks the screen is visible
$ sudo bash -c 'setterm --term linux --blank force </dev/console'
blanks the screen again

$ exec libdrm app that is trying to be "screen blanking aware"
at startup: change CRTC ACTIVE property from 0 to 1 (makes screen visible)
while running: libdrm calls operate normally and screen is fine
at shutdown: change CRTC ACTIVE property from 1 to 0 and close DRM-fd
screen remains visible and does not return to blanking mode

$ sudo bash -c 'setterm --term linux --blank poke </dev/console'
in case state is messed up
$ sudo bash -c 'setterm --term linux --blank force </dev/console'
force screen blanking
$ cat /dev/dri/card1
wait a while to convince that screen is staying blank
press ctrl-c
screen will unblank-- simply closing the DRM-fd unblanks the screen

Summarizing these issues:
1: setterm -blank <timeout> does not work at all
2: setterm is not getting the blanking state from DRM and thus easily gets out of sync
3: closing /dev/dri/card0 or card1 reactivates an inactive CRTC, blanking is lost, setterm is confused

Compounding these issues, my brand new ASUS gaming monitor requires "vc4.force_hotplug=3" to prevent blanking/un-blanking cycling, and even then, the monitor cycles between power-savings mode and signal-missing mode. The same monitor is fine with Ubuntu+KDE-Plasma+RTX3060. Appreciate any thoughts on how to get screen-blanking working in desktop mode with libdrm apps. Thanks!

Last edited by Vraz on Thu Mar 20, 2025 3:01 pm, edited 1 time in total.

Not entirely sure how all the console stuff interacts with DRM to be honest, but by default once your DRM/KMS program terminates, DRM fbdev takes over. Also not 100% sure, but I would imagine it sets ACTIVE back to 1 for the CRTC. To avoid this, I use
This leaves DRM/KMS state unchanged once your program quits. So if you set ACTIVE to 0, the display should remain blank, even if your program quits.

info-beamer hosted - A user and programmer friendly digital signage platform for the Pi: https://info-beamer.com/hosted

dividuum wrote:echo N > /sys/module/drm_kms_helper/parameters/fbdev_emulation

This is great-- was unaware of this setting and verified it solves DRM-exit problem so that is a great step forward!

I dug into the setterm and virtual terminal driver source. As expected, the virtual terminal driver keeps a private "is-blanked" variable. Thus, any blanking updates done elsewhere confuse it and subsequent operations fails. You can make --blank force always work by preceding with a "poke" and --blank poke by preceding with a "force".

The non-working blank timeout is the result of some dubious design in the virtual terminal driver. While most of the blanking, power-savings, power-down is implemented via IOCTL's, blanking timeout must exclusively be passed via escape code. This is dumb and results in an inconsistent calling pattern with predictable results. setterm uses stdin for IOCTL calls and stdout for escape codes (the latter because it has no other option). Running setterm from outside a virtual terminal requires having knowledge of how the internal calls work. (You could redirect both stdin and stdout, but then you lose other setterm output.)

% sudo bash -c 'setterm --term linux --blank 5 >/dev/console'
(this successfully sets a 5 minute console blanking timeout)

The big remaining issue is the power cycling on my monitor. I accidentally left it going for a few hours last night and the monitor was not happy upon my return. Will try and dig into that today as the "/sys/module" fix plus understanding how to set the blank timeout gets me close to success.

Found another post with the same monitor power-down cycling problem viewtopic.php?t=365369. Per their suggestion, updated to the latest stable firmware and that resolved the issue. Unfortunately, my monitor still requires "vc4.force_hotplug" to avoid immediate wakeup from sleep. Given the video driver initiates monitor sleep, seems like the driver could ignoring hotplug pulses for couple seconds and side-step the issue in a less impactful way.

With power savings working, now bypassing setterm and enable 1-minute blanking via:
% sudo sh -c "echo -e '033円[9;1]' >/dev/console"
Then disable fbdev emulation:
% sudo sh -c "echo N >/sys/module/drm_kms_helper/parameters/fbdev_emulation"

Am happy with the results so calling this solved.