I’ve noticed that if I allow my DevTerm to go to sleep I am unable to get the device to come back to life afterwards. When I touch a key, the display lights up (backlight) but nothing shows up. Also, the power button LED remains on constantly. If I force the unit to power off by holding the power button down for 10+ seconds, the display goes off and the power button LED dims but doesn’t go off fully. From this point it has been hit or miss if I can get the unit to fully come back up… The 2 times I had issues with it coming back up from that state I had to remove the batteries for a few minutes and then it behaved normally.
Anyone else run into this? I’m thinking about not allowing it to go to sleep (or sleep the display) for now and just let it lower the brightness.
Addendum: In looking through my settings, I believe this is only occurring with display sleep and not system suspend. My suspend setting is set to 1 hour and I am definitely reaching for the device in a shorter interval, so I think this is related to the LCD’s sleep. I’m going to test if the device still responds to ping and SSH while in the seemingly “unresponsive” state as that will confirm if this is specific to the display only. I’ll update when I confirm.
Was able to get it to be in the limbo state and test remote connectivity. The device itself is most definitely awake and responsive, and I’m able to SSH to my heart’s content. So the problem lies somewhere between the display and possibly the GPU or window manager? The panel gets power back as is evident by the backlight coming on, but there is absolutely no image.
Restarting the window manager via SSH (sudo systemctl restart lightdm) brought back visuals, so that’s a workaround.
Yeah for sure display sleep is broken at the moment… Hopefully it gets fixed or we get instructions on how to do so.
I honestly don’t know right now if suspend is working since the above issue was triggering before suspend would have based on my current settings. I might test it here in a few minutes by forcing a shorter suspend interval. Is your DevTerm just not going into suspend, or is it going into suspend and having issues coming back from it?
Okay I just tested this and the result is the exact same behavior when it goes into Suspend as with simply sleeping the screen, probably because suspend programmatically does both a display sleep AND system/CPU sleep state in one sweep, even though I don’t have explicit display sleep enabled.
When I hit the power button to wake the DevTerm back on, the display backlight comes on but nothing on screen. The DevTerm responds to SSH but restarting the window manager does not bring back visuals and requires a reboot.
So both Suspend and display sleep appear to be problematic at the moment.
On tty7 to no avail. I want to be able to pick up and use the device, have it sleep to preserve battery, and ideally have the screen sleep to avoid burn-in but for now it feels like I have to shut it down and cold start every time I want to use it. It’s a shame and it feels like it’s a software issue somewhere since restarting lightdm does bring it back (though again a pain to ssh into the device to do so).
In my system, restarting lightdm doesn’t screen does not appear.
-Restart directly with DevTerm using VNC.
-Execute command via SSH.
Both try didn’t work.
It isn’t a consistent way of fixing it, but it works maybe 80% of the time. I run i3 on top of xfce but get rid of the xfce-panels (this helps with real estate, and also lets me avoid mousing around as much as possible). I don’t think this is a factor. Needless to say, it seems like the three of definitely have this issue overall.
I really wish there was an easy fix but I have yet to stumble on it despite days of off and on Googling and trying many different things.
I’ve been wondering this too. It’s part of the reason I put off assembling my DevTerm. I’d rather know the basic stuff was working before I start using it. Hard to know if the clockworkpi folks are even aware of the issue or have any thoughts on it.
The Rockchip MIPI DSI driver that exists in mainline is a bit buggy but there’s a pending patchset that fixes the display suspend/resume issues. it looks like it’s been accepted into the rockchip tree but doesn’t appear to be in any of the 5.16 or 5.17 trees yet, so may need to wait: [v3,0/4] Fix Rockchip MIPI DSI display init timeouts - Patchwork (kernel.org)
Does that mean you can fix the Devterm hibernation problem?
I’m not familiar with linux. Can you tell me how to deal with it?
I did not understand well even if I searched on google.
This still seems to be a problem. My devterm that I got last week does the same thing. Will put the display to sleep, but can’t get it back from the console. I have to ssh in and restart X or reboot. Really annoying.
I see a software update in my future… I’m running the latest os from clockwork on an A06… I have the same issue won’t come back from sleep. I’ve adjusted the power settings to not go to sleep…just dim the back light…
It seems like it has been figured out at this thread here:
But it was not released in an official OS update. Hopefully it will be eventually, or someone in the community will get it working in the official Armbian release or some other OS that can be maintained.
Has yatli considered putting in PRs for these updates? I’m not a hardware nor linux dev, so don’t know the process; and am curious to see if these will eventually make their way to the mainline in the branch’s current state.
