I have had my Touchscreen for about 1 year and it had been fine on my RiPi2 with a 2015 version of Raspian.
I have just bought a RiPi3 and did a clean install of the very latest version of Raspian.
Downloaded 13/12/16 and 25/11/2016 version
Kernal 4.4.34 -V7 #930
Now at first everything seemed fine, touchscreen worked, woke up fine etc.
However if I let it sleep for a long time probably >30mins it refuses to wake up.
The only solution is to power off and on again - a sure way to corrupt the SD Card!
I read the forums and I see this is a known issue with later versions of Raspian BUT it is supposed to be fixed in the very latest version.
I have tried an apt-get update and apt-get upgrade
But the issue is still there.
I left it powered up, asleep and unresponsive for about 6 hours taping it intermittantly to see if it would “wake up” which it would not.
Suddenly after 7 hours it responded and “woke up”.
I have a touch screen setup on my desk for regular development work, and I think you might finally have explained what’s going on with it. I often leave it for long periods of time without touching the screen, it goes to sleep, and twice recently it’s not woken up again. I figured the Pi had crashed due to me scattering things that could cause a short to the far corners of my desk, but this seems like a more likely explanation.
I’m not sure where to start with diagnosing it, but I know who to ask.
Where it it mentioned that the problem is fixed? It may not be in a released kernel yet.
Thanks for the reply.
From what I have read the Pi has NOT crashed when the screen sleeps and refuses to wake up.
People with remote access can access their “sleeping” Pi OK.
This is a link where they said it has been fixed but since I last read it there has been further comments that it is still not fixed.
I have carried out the instructions and I still have the problem.
The fact that it is intermittant mine “woke up” after refusing for 6 hours to wake up will make it very difficult to trace.
yes, have experienced this in the last forthnight or so too. I usually shut down my Pi over ssh though so it could have been there for a little while more than that.
Interestingly something similar also happened on our lab Pis, hooked up to lapdocks, when I’ve been running
apt-get upgrade for the last few weeks, and I reckon it’s related to something in
raspberrypi-sys-mods, though that’s a wild guess with nothing more to some vague value to it.
Still, if that is the culprit, rather than something in the kernel, it might be possible to figure out what it is by going through the last few weeks of commits:
… that said, it’s quite possible that I’m completely off the mark here, but I don’t believe the problem is specific to the touchscreen and lies outside the kernel.
OK, just to test my theory, I went back to a fresh Raspbian version 25/11/2016 and upgraded all packages except
When I finally upgraded
raspberrypi-sys-mods the screen went black… whether that issue is separate or related is to be determined but at least I wanted to be sure I wasn’t pointing the finger at something that behaved as expected.
I will file an issue for Simon on their github and continue looking into how those issues may or may not be related, but right now my gut feeling tells me there is a connection, if potentially tenuous.
right, I am sort of getting somewhere:
my current theory is that leaving the system idle long enough will switch runlevel and trigger the service to stop. It seems that subsequently starting the service back up does not bring the backlight back to life.
… I’m personally going to do away with the service for a while and see if the Pi ‘wake up’ issue goes away - if I was a betting man, I’d give it good odds!
sudo systemctl disable rpi-display-backlight
… obviously the backlight will remain active upon shutdown, but I can live with that, at least for a few days while I test the theory.
Nope, unfortunately it makes no difference whether that service is active or not, I found the Pi left on overnight stuck with no way to wake it up using touchscreen or mouse/keyboard.
Writing to /sys/class/backlight/rpi_backlight/ made no difference either, only a reboot brought the display back to life.