Up to there everythink is fine, the kiosk browser is shown on the display.
But we have the necessity to control programmatically the idle/active status of the display.
We can set an idle timeout througth the weston.ini file and the behaviour is as expected: when timeout is reached the display fades off and wakes-up when is touched.
But we didn’t found a way to wake up the display via software.
On other systems we di that with the use of xset command.
In this case our approach has been to install xset in the kiosk container as it already communicates with the graphical server in the Weston container.
But we didn’t get any result.
Commands like xset dpms force on
return the following message server does not have extension for DPMS option
Commands like xset s activate
doesn’t have any effect.
We also tried wlr_rand but always returns the following message compositor doesn't support wlr-output-management-unstable-v1
Plaese note that other X commands, for example xdotool mousemove 50 50
work properly.
This isn’t the only way to do this, but it is the most independent way that doesn’t rely on Weston or other tools.
What you can do is write to this file: /sys/class/graphics/fb0/blank
If you’re in the container you’ll need to run the container with --privileged to have the right permissions to write to this file. Writing a 1 to this file will effectively blank out your display while writing a 0 will bring it back to normal operations.
Give this approach a try and let me know if it works for your use-case.
Apologies, when I originally tested my solution it was on the Apalis i.MX6. I just re-tested on the i.MX8 and the results is as you said. It seems /sys/class/graphics/fb0/blank behaves differently between i.MX6 and i.MX8. Unfortunately it seems to be that /sys/class/graphics/fb0/blank doesn’t actually affect the state of the display as far as I can tell, on the i.MX8.
There may be a different mechanism to do something similar for i.MX8 but I’d have to check.
Quick question, will an HDMI display be your final solution?
Yes, the HDMI display will be the final solution.
The idea is to show on the display some information about the system. If there is no critical information, the display goes to sleep. The user may wake it up by touch.
When a particular event occurs (i. e. an alarm) the display must activate automatically in order to alert the user.
At present we are unable to develop this latter feature.
Thank you for the information, I understand your use-case here and what you’re trying to achieve. Let me consult with the team internally and see if the i.MX8 has a mechanism to disable/sleep the HDMI interface during runtime.
The commands you suggested actually allow the HDMI display to be turned off and on, but unfortunately there are some limitations.
When I turn off the display with the command echo off > /sys/class/drm/card1-HDMI-A-1/status, it is not possible to wake up the screen with a simple touch.
When I wake up the screen with the command echo on > /sys/class/drm/card1-HDMI-A-1/status, an empty graphical environment appears on the display and not the kiosk environment as expected.
I plan to carry out further tests and will notify you if I have any news.
This method effectively turns off the screen at the DRM level. Which is probably why a touch input doesn’t wake the screen since it’s been basically disabled. You may need to setup some interrupt call such that when a touch interrupt is detected an on is written to status.
There still may be other methods to your use-case here. But these are the most obvious that we know about.
