helgeerbe/picframe

picframe on Bookworm (current RPI OS) - screen/display on/off control -> possible solution

Opened this issue · 4 comments

Not a picframe issue as such, rather due to major changes in Bookworm and depreciation of vcgencmd display_power. However, control of display on/off is a major issue for many using picframe.

The wlr-randr --output HDMI-A-1 --on (or off) command are used to control display on/off. However, I found when wlr-randr --output HDMI-A-1 --on is used when picframe is already running, I just got a blank screen - no pictures.
I think I have worked out a solution.
My solution at present is to shutdown picframe when turning the display off, and start picframe again when turning the display on.
My photo frame is on for set hours - this solution may not be suitable for those using motion detection etc.

I did modify ./start_picframe.sh (from https://github.com/helgeerbe/picframe/wiki/Setup-guide-Bookworm-and-Wayland) by adding lines export WAYLAND_DISPLAY=wayland-1 export XDG_RUNTIME_DIR=/run/user/1000. This seemed to get auto-start on boot working correctly for me.

./start_picframe.sh

#!/bin/bash
wlr-randr --output HDMI-A-1 --off
export SDL_VIDEODRIVER=wayland # sdl has to use wayland
source /home/openhabian/venv_picframe/bin/activate # activate phyton virtual env
export WAYLAND_DISPLAY=wayland-1
export XDG_RUNTIME_DIR=/run/user/1000
picframe &  #start picframe
wlr-randr --output HDMI-A-1 --on

Then chmod +x ./start_picframe.sh

nano ./stop_picframe.sh

#!/bin/bash
export WAYLAND_DISPLAY=wayland-1
export XDG_RUNTIME_DIR=/run/user/1000
/usr/bin/wlr-randr --output HDMI-A-1 --off
pkill -x picframe #kill all instances of picframe, as we need to start picframe again when we turn the display on and would end up with multiple picframe processes running

Then chmod +x ./stop_picframe.sh

Then crontab -e
And something like:

# For more information see the manual pages of crontab(5) and cron(8)
#  +---------------- minute (0 - 59)
#  |  +------------- hour (0 - 23)
#  |  |  +---------- day of month (1 - 31)
#  |  |  |  +------- month (1 - 12)
#  |  |  |  |  +---- day of week (0 - 6) (Sunday=0 or 7)
#  |  |  |  |  |
#  *  *  *  *  *  command to be executed
#
# m h  dom mon dow   command

#Turn on display at 6.30am Mon-Fri
30 6 * * 1-5  ./start_picframe.sh

#Turn off display at 9am M-F
0 9 * * 1-5 ./stop_picframe.sh

#Turn on display at 3pm M-F
0 15 * * 1-5 ./start_picframe.sh

#Turn on display at 8am Sun
0 8 * * 0 ./start_picframe.sh

#Turn on display at 8am Sat
0 8 * * 6 ./start_picframe.sh

#Turn off display at 9pm every day
0 21 * * * ./stop_picframe.sh

Smarter minds than I can probably work out why using wlr-randr --output HDMI-A-1 --on after picframe is already running, and wlr-randr --output HDMI-A-1 --off has been used, results in a blank screen.

I had half concluded that stopping picframe then restarting it was the only way round the Wayland problem. One issue is that the image sequence would be lost each time it happened, and I thought of saving a sequence number so it could continue. The issue as it stands is that we use a sqlite randomiser that has no option to seed in order to give a reproducible random sequence so we would need to switch to a python randomised list system. Quite doable, I'll put it on the list ...

5 days in -> no issues with display off/on using my above solution.

No idea if it messes with the sequence -> I don't mind what sequence (so long as some degree of change / randomness)

Here is the revised long-form article based on Helge's instructions: https://www.thedigitalpictureframe.com/how-to-build-the-best-raspberry-pi-digital-picture-frame-with-bookworm-and-pi3d-picframe-2024-edition/ where screen on/off works like a charm.

Isn't there a problem with 100% CPU usage in the new solution?