I have a deployment of a couple hundred raspberry pi devices that drive one of two different sizes of touchscreens connected to its HDMI port. Consider the deployment as a kind of kiosk setup, but with some specialized hardware with which the pi communicates.
We are using Raspbian, as derived from Debian GNU/Linux 11 (bullseye).
I released an update to our own software (not to Raspbian, so this isn't a matter of updated drivers). We use chromium to display a webpage served by a service on the system. The update simply attempts to change the meta tag 'viewport' to include a 'maximum-scale=1.0' statement in an attempt to prevent people from pinching/zooming the screen. Nothing much more than that. Certainly nothing that I could imagine would result in the problem we saw.
Since this update, three or four of the devices' touch-screens went black (in one case, well after the update).
We have a way to view the device remotely, via dwservice, and it displays the openbox desktop we set up.
Running tvservice -s, I can see that the pi still sees the HDMI screen. I can also from the raw Xorg.0.log file that it successfully retrieves the EDID block from the screen, further ensuring that it's communicating properly with the HDMI screen. Yet, our customer cannot see the screen. The touch sensors on the screen also continue to work... if they could only see the screen, they could work with it.
Replacing the screen resolves the problem. The customer can then work with the device as intended.
I have not received one of the 'bad' screens yet to study it.
It is a difficult sell to my boss that this wasn't caused by the software update, due to the coincidental nature of this problem coinciding with an update... but I cannot figure out what one could possibly do in software to cause a result like this.
These screens worked just fine... then they stopped. And I haven't seen a case where it stopped before we updated... only afterwards.
Where in this operating system should I look? And is it possible to resolve this with some kind of software fix?
(Note: already tried tvservice -p, but that didn't work... nor is this an accidental case of tvservice -o turning it off, because after testing that, the remote service eventually can't see the desktop, either).
We are using Raspbian, as derived from Debian GNU/Linux 11 (bullseye).
I released an update to our own software (not to Raspbian, so this isn't a matter of updated drivers). We use chromium to display a webpage served by a service on the system. The update simply attempts to change the meta tag 'viewport' to include a 'maximum-scale=1.0' statement in an attempt to prevent people from pinching/zooming the screen. Nothing much more than that. Certainly nothing that I could imagine would result in the problem we saw.
Since this update, three or four of the devices' touch-screens went black (in one case, well after the update).
We have a way to view the device remotely, via dwservice, and it displays the openbox desktop we set up.
Running tvservice -s, I can see that the pi still sees the HDMI screen. I can also from the raw Xorg.0.log file that it successfully retrieves the EDID block from the screen, further ensuring that it's communicating properly with the HDMI screen. Yet, our customer cannot see the screen. The touch sensors on the screen also continue to work... if they could only see the screen, they could work with it.
Replacing the screen resolves the problem. The customer can then work with the device as intended.
I have not received one of the 'bad' screens yet to study it.
It is a difficult sell to my boss that this wasn't caused by the software update, due to the coincidental nature of this problem coinciding with an update... but I cannot figure out what one could possibly do in software to cause a result like this.
These screens worked just fine... then they stopped. And I haven't seen a case where it stopped before we updated... only afterwards.
Where in this operating system should I look? And is it possible to resolve this with some kind of software fix?
(Note: already tried tvservice -p, but that didn't work... nor is this an accidental case of tvservice -o turning it off, because after testing that, the remote service eventually can't see the desktop, either).
Statistics: Posted by vanriper.trey — Tue Apr 15, 2025 5:32 pm