I cannot disable screen blanking with MagicMirrorOS

smegbadger

Hi

I am running MM via MagicMirrorOS on a RPi4B with an RPi monitor in portrait. I use MMM-Universal-Pir to turn the screen on and off during the day (with wlr-randr commands) which works great but the screen switches off for good overnight, the PIR cannot wake it up. I have disabled Screen Blanking with raspi-config but that makes no difference.

If I run wlr-randr in the labwc container (access via docker exec -it labwc bash) I normally get (some resolutions removed for brevity):

HDMI-A-1 "Raspberry PI RPI MON156 81005568472 (HDMI-A-1)"
  Make: Raspberry PI
  Model: RPI MON156
  Serial: xxxxxxxxxxxx
  Physical size: 350x190 mm
  Enabled: yes
  Modes:
    1920x1080 px, 60.000000 Hz (preferred, current)
...
    640x480 px, 59.939999 Hz
  Position: 0,0
  Transform: 90
  Scale: 1.000000
  Adaptive Sync: disabled

However, once the display has gone to sleep that same wlr-randr command gives

failed to connect to display

this make me feel it is something in the docker set up but i see nothing in the docker logs

Note that I also have RANDR_PARAMS="--output HDMI-A-1 --transform 90" in the .env file to rotate the display at boot.

Cheers
Steve

sdetweil

@smegbadger have you turned off screen blanking on the docker host? ubuntu or whatever owns the actual display?

smegbadger

Hi

I don’t know where that would be. The RPi boots to a login prompt. Then docker takes over and launches MM in electron. There is no GUI for me to fiddle with

Steve

sdetweil

@smegbadger @karsten13 will have to advise

karsten13

@sdetweil

the setup is “Raspberry Pi OS Lite” with the normal docker setup and an additional labwc container

@smegbadger

I have no idea what is happening. Sounds like the monitor totally cuts the connection to the pi after a while.

Maybe this post contains something helpful.

What is your wlr-randr command for waking up?

sdetweil

@smegbadger if you stop mmos does the screen still turn off overnight?

smegbadger

@sdetweil I stopped docker at 9:30 last night with docker compose down leaving the screen at the magicmirror login prompt. This morning the screen was still showing the login prompt . MM was reinstated perfectly with docker compose up -d --force-recreate. @karsten13 I notice there are now four objects that start:

[+] Running 4/4
 ✔ Network magicmirror_default  Created                                                                            0.1s
 ✔ Container mm                 Started                                                                            0.9s
 ✔ Container init               Started                                                                            1.0s
 ✔ Container labwc              Started                                                                            1.0s

Steve

karsten13

@smegbadger

the 4 objects are o.k., one network and 3 containers (init is only for setting correct permissions in the mount folders, it runs for a very short time, you can disable it in the .env file if wanted).

Question: When the failed to connect to display occurs, how do you get the screen back working? Is a docker rm -f labwc && docker compose up -d sufficient or a docker compose up -d --force-recreate? Or do you have do reboot? Or do you switch the monitor off and on?

Other idea is to implement a wlr-randr call every 30min. in the labwc container.

smegbadger

@karsten13 i have disabled the init container as suggested.

When the display fails I can get it back with docker rm -f labwc && docker compose up -d (docker compose up -d --force-recreate also works but docker compose up -d on it’s own doesn’t). I am running it today with the MMM-Universal-Pir module disabled as another test (although when sitting at a login prompt it never went off).

Note that the display fails after a few hours of no PIR trigger, it doesn’t have to be overnight.

Steve

karsten13

@smegbadger said in I cannot disable screen blanking with MagicMirrorOS:

I can get it back with docker rm -f labwc && docker compose up -d

so restarting only the labwc container solves the problem …

I will try to build a labwc container which executes wlr-randr e.g. every 30min. so we can see if this helps.