display-on.sh wakes monitor up to wrong tty

[peterrus1]

I have the following cronjobs:

At 18:30 display-off.sh
At 03:00 sudo reboot (I want a nightly reboot to make sure everything keeps running smoothly)
At 03:10 display-off.sh (because we just rebooted)
At 08:30 display-on.sh

Every morning I see that the kiosks are booted into the raspi-config tty instead of Xorg (The graphical environment). I have done some debugging and believe this is happening:

If I open a console on the raspi-config tty and run the following:
./display-off.sh; sleep 60; ./display-on.sh

the display turns off and back on after 60 seconds, but on the graphical tty instead of the console tty from which I launched this set of commands.

Then if I go back to that console tty and run:
sleep 10; ./display-off.sh; sleep 60; ./display-on.sh
and quickly switch to the graphical tty before sleep 10 finishes the following happens:

The display turns off and back on after 60 seconds, but this time on the graphical tty instead of the console tty.

This leads me to believe that display-on is not functioning correctly and always switches to the opposite tty that was active when display-on is being executed. So when rebooting at 03:00 AM the graphical tty becomes active. Then at 03:10 the display is turned of, but the graphical tty stays active (without an active monitor of course). Then at 08:30 display-on is being executed but it switches to the console tty, because the graphical tty was active at that time.

I think this might be related to: #30 (comment)

My current workaround is the following:

Turn of display at 18:30
Reboot at 08:30, which also turns on the display and opens the graphical tty by default.

[jareware]

OK, seems like there's definitely something fishy with the scripts, since you're not the only one seeing this!

Let me know if you manage to fix this somehow, and we'll be happy to test & merge upstream!

[jareware]

Did you ever get to the bottom of this @xfakt-pj?

[peterrus1]

No, I'm afraid we just went with the workaround.

[jareware]

OK, I'll try to look into this when preparing the next release.

[peterrus1]

Great, would be much appreciated. I think I can find some time to test that new release ;)

[jareware]

@xfakt-pj there's a new RC available for download!

[jareware]

The v2.1.0 release was thoroughly tested for this, and we were unfortunately unable to reproduce this.

I'm not saying I don't believe you, but I'm saying I don't know what to do about this without a way to reproduce, sorry!

Feel free to reopen if you have more info on this.

[peterrus1]

Sure, no worries. Didn't have the time to test the RC yet. I will get back to this when upgrading the current dashboards.

[peterrus1]

Issue seems to persist after updating to v2.1.0. I have attached my crontab in the hope that it might prove to be useful somewhere down the line.

Considering the workaround I stated in the OP and the fact that you can not reproduce this I currently have no leads as where to start debugging this. But lets keep this here for future reference.

Can we keep the issue open in case somebody else comes across the issue? @jareware

[jendib]

I have the same issue also, the morning "display-on.sh" is opening on the raspi-config tty.
The reboot workaround also works, but it's not super clean :)

[jareware]

Odd. My guess would be that the display-on.sh script cycling the tty misbehave somehow. (They're there because without them some displays would not come back on. HDMI is a mess. 😒)

@xfakt-pj, @jendib, if you want to try something, you can remove the chvt commands from ~/display-on.sh and see if it changes anything.

And please report back if you do! 😃

[matristain]

I just try this solution and works great for mi, see if it works for you.
-Instead of removing signal to the display I send a "stand by" command to TV using CEC.
This are the steps:

Install :
sudo apt-get install cec-utils

TV ON
echo "on 0" | cec-client -s
TV OFF (stand by)
echo "standby 0" | cec-client -s

Also I can "Force" to keep display on specific HDMI ( INPUT 1 ) Input by running this on a cron.

HDMI INPUT 3
echo "tx 4F:82:30:00" | cec-client -s
HDMI InTUP 1
echo "tx 4F:82:10:00" | cec-client -s

*or maybe switch from one to another input every given time also in a cron.

CEC have much more benefits Raspbery can also receive instructions from TV remote control (depending on the TV model)

or maybe with a local "api server" or websocket can even control TV from web.

Any more info or suggestions are welcome.

[jareware]

Great set of tips!

The biggest issue with CEC seems to be that even if something works on one TV, there's 0 guarantees it'll work on another TV, even from the same manufacturer.