I’m booting to Console to save CPU on a Raspberry Pi 4B for the Patchbox Modules, but when attached to a monitor I would prefer it to display sleep. It’s using a secondary input on that monitor (primary is a Mac’s 3rd monitor) and when the main input is asleep it shows the Pi. While I can disconnect the HDMI plug (obviously) this isn’t the approach I would like, and since I can’t simply install xscreensaver as with the desktop I’m looking for simple options.
Also note that I’m using modep right now, which means most of the use of the Pi is via browser, and I can ssh in via remote console just fine, but would prefer to keep it attached via HDMI as well for troubleshooting purposes.
I’ve tried adding hdmi_blanking=1 to /boot/config.txt as I once did for my old raspberry Pi 3B running OLA (Open Lighting Assoc. which is a DMX/OSC/Artnet routing environment) when I ran that headless. However that was a few years ago and things seem to have changed. Plus, I don’t recall if this supported full display sleep, or if i did it just to reduce power usage when headless.
So I turned to xset, which is the other utility I’m familiar with on linux console desktops. xset returns unable to open display “” for all relevant commands (xset q, xset s blank, xset -s on, xset -dpms, etc). Obviously the screen isn’t defined in a way that xset is able to control.
Full display sleep is what I’m after, basically. I would prefer something supported in deb bullseye/Patchbox OS so that I don’t have to maintain a script as OS updates (and patchbox updates) roll out.
Thank you, I don’t want to perm disable I just want the display to sleep on that input. That way the Mac works as normal on the other input, and the display sleeps at night without manually powering it off.
The RPi needs to be placed where it isn’t conveniently located (so I can route audio to & from the USB soundcard attached) hence the reason for not wanting to just manually pull HDMI. SSH works fine until there’s a reason it doesn’t…so need a nice installed solution for ease of troubleshooting.
patch@patchbox:~ $ tvservice
tvservice is not supported when using the vc4-kms-v3d driver.
Similar features are available with standard linux tools
such as kmsprint from kms++-utils
Note kms++ utils simply allows querying the display information via kmsprint. kmstest and the other commands that come with those utils don’t line up with what I’m asking here, so will ignore more detail on that error message.
Support for DPMS power states and screen blanking would be much more elegant, say if i lose wifi connection to the unit or etc. I have a bluetooth keyboard assigned to it on one of it’s three selectors, so I could simply turn that on and type a key (and switch the monitor input if the Mac is also live at that time).
Most of this seems related to changes since debian stretch, which was the era that I used OLA on a RPi 3B.
Obviously most of the issues here are due to there being no xsession, as we are booted to CLI. this is evident by also checking with xrandr and getting the same “Can’t open display”. Simply defining a display=:0 or display=0 won’t help as there’s still no xwindows to handle that. However the default raspbian OS image boots to a default state in CLI mode that supports DPMS and console blanking fine (first powers down, second protects screen burn-in, obviously). So I’ll continue working on this as there should be support available, I just need to determine what is missing in the Patchbox OS to support it.
Checking the current setting of consoleblank per kernel parameter shows:
Last login: Thu Feb 22 01:27:54 2024 from 192.168.0.35 patch@patchbox:~ $ cat /sys/module/kernel/parameters/consoleblank 300
However checking to see if DPMS is working and clearly it’s not. Attempting to install the utils used by xset and xrandr shows the following output:
sudo apt install xfce4-power-managerpatch@patchbox:~ $ sudo apt install xfce4-power-manager Reading package lists… Done Building dependency tree… Done Reading state information… Done The following additional packages will be installed:
libupower-glib3 libxfce4panel-2.0-4 libxfce4ui-2-0 libxfce4ui-common upower xfce4-power-manager-data xfce4-power-manager-plugins* Suggested packages:
** devhelp** The following NEW packages will be installed:
** libupower-glib3 libxfce4panel-2.0-4 libxfce4ui-2-0 libxfce4ui-common upower xfce4-power-manager xfce4-power-manager-data xfce4-power-manager-plugins** 0 upgraded, 8 newly installed, 0 to remove and 1 not upgraded. Need to get 2,017 kB of archives. After this operation, 7,465 kB of additional disk space will be used. Do you want to continue? [Y/n] n Abort. patch@patchbox:~ $
My guess is that power management might be removed entirely to support better operation of the realtime kernel, which would need to periodically poll the device. I am considering a kvm solution until I have time to research the implications this may have on high cpu bound audio use cases on the RPi.
Feel free to comment if anyone has anything to add.
It’s not what you asked for, but one thing I like doing for raspberry pi CLI, is rather than attaching it to a monitor, I use it with a usb HDMI video capture dongle plugged into my PC, I just use a camera app or similar when I need to use it for debug or whatever.
Doesn’t hog a monitor that way.
Just the cheapy $10ish ones do the trick, and they are a pretty useful device for various things.
Yes, I have it attached to an inexpensive 7" monitor now, as I didn’t want it hogging the main monitor. Yet I did have success having it sleep so it’s not distracting has helped. I managed to get xfce4 power manager installed and it’s working fine. Even with hdmi blanking off in config.txt it sleeps the monitor now.
I had to raise my buffer to 512 afterwards, so I am thinking it doesn’t play well with the realtime kernel (or I need a soundcard that works in USB class compliant mode better than this one).
Once I have better conclusions on how to properly set it up for other users, certainly. That will likely require at least another free weekend to dig in on the issue(s).
I did a fresh install before starting this thread (as the original install was about 2 years old) and it was working at 128samples for quite some time, perhaps that was anomalous. I’ll report back further on the power management when I have time.