Here we are using Apalis iMX8QM V1.1B/Ixora V1.2 hardware connected to a HDMI touch screen display (Future Design ELI70-CR)
On the iMX8 we run a Torizon (BSP 5.3.0) image with your Weston vivante and kiosk containers started from your docker-compose file (torizon-samples/docker-compose.arm64.yml at bullseye · toradex/torizon-samples · GitHub).
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
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.
xset dpms force on
return the following message
server does not have extension for DPMS option
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
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:
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.
Thanks for your prompt reply!
I have tried just now the solution you proposed.
My problem is that the solution only works when the weston container is not active.
Could it be that weston takes precedence over the
Am I missing something?
Thank you again
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.
I’ve learned of how to control the HDMI display on i.MX8. To do so you instead write the following files:
echo off > /sys/class/drm/card1-HDMI-A-1/status
echo on > /sys/class/drm/card1-HDMI-A-1/status
This will disable/enable the HDMI display accordingly. Please give this a try and let me know if it suits your needs.
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
There still may be other methods to your use-case here. But these are the most obvious that we know about.