DevTerm struggles to come back from display sleep

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.

1 Like

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.

I have also noticed this display sleep issue but the device is otherwise fine and I can ssh into it and reboot it. I actually just asked this question here: Modifier + trackball scrolling and power management questions for a06 users.

It sounds like you could get suspend working - which is amazing, I can’t even get that working right now. How did you configure suspend to work?

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.

Yes, this is the behavior I have seen as well. The system does respond to the suspend command when I do:

sudo systemctl suspend and it does seem to do something when I hit the power button, but yes, then we must being seeing the display waking issue.

1 Like

I’ve tried a few fixes for this including running

xrand —auto

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).

1 Like

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.

Have you changed any settings?

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 think I’ve had some success chasing this down but the prognosis is not good. Executing journalctl led me to this:

Dec 03 14:54:04 clockworkpi-a06 kernel: ------------[ cut here ]------------
Dec 03 14:54:04 clockworkpi-a06 kernel: pclk_mipi_dsi0 already disabled
Dec 03 14:54:04 clockworkpi-a06 kernel: WARNING: CPU: 2 PID: 1800 at drivers/clk/clk.c:952 clk_core_disable+0x26c/0x2a8
Dec 03 14:54:04 clockworkpi-a06 kernel: Modules linked in: xfrm_user xfrm_algo l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunne>
Dec 03 14:54:04 clockworkpi-a06 kernel: CPU: 2 PID: 1800 Comm: Xorg Tainted: G         C        5.10.60-rockchip64 #trunk
Dec 03 14:54:04 clockworkpi-a06 kernel: Hardware name: Clockworkpi A06 (DT)
Dec 03 14:54:04 clockworkpi-a06 kernel: pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
Dec 03 14:54:04 clockworkpi-a06 kernel: pc : clk_core_disable+0x26c/0x2a8
Dec 03 14:54:04 clockworkpi-a06 kernel: lr : clk_core_disable+0x26c/0x2a8
Dec 03 14:54:04 clockworkpi-a06 kernel: sp : ffff8000136c39a0
Dec 03 14:54:04 clockworkpi-a06 kernel: x29: ffff8000136c39a0 x28: ffff800008ff7fd0 
Dec 03 14:54:04 clockworkpi-a06 kernel: x27: 0000000000000028 x26: ffff00002e2ea900 
Dec 03 14:54:04 clockworkpi-a06 kernel: x25: 0000000000000038 x24: ffff800008fa7dc0 
Dec 03 14:54:04 clockworkpi-a06 kernel: x23: ffff000005993800 x22: 0000000000000001 
Dec 03 14:54:04 clockworkpi-a06 kernel: x21: ffff0000231b4680 x20: ffff000000602700 
Dec 03 14:54:04 clockworkpi-a06 kernel: x19: ffff000000602700 x18: ffff8000118eee60 
Dec 03 14:54:04 clockworkpi-a06 kernel: x17: 0000000000000000 x16: 0000000000000000 
Dec 03 14:54:04 clockworkpi-a06 kernel: x15: 0000000000000302 x14: ffff8000136c3660 
Dec 03 14:54:04 clockworkpi-a06 kernel: x13: 00000000ffffffea x12: ffff80001195ee98 
Dec 03 14:54:04 clockworkpi-a06 kernel: x11: 0000000000000003 x10: ffff800011946e58 
Dec 03 14:54:04 clockworkpi-a06 kernel: x9 : ffff800011946eb0 x8 : 0000000000017fe8 
Dec 03 14:54:04 clockworkpi-a06 kernel: x7 : c0000000ffffefff x6 : 0000000000000001 
Dec 03 14:54:04 clockworkpi-a06 kernel: x5 : 0000000000000001 x4 : 0000000000000000 
Dec 03 14:54:04 clockworkpi-a06 kernel: x3 : 0000000000000002 x2 : 0000000000000001 
Dec 03 14:54:04 clockworkpi-a06 kernel: x1 : a256a9315da0ef00 x0 : 0000000000000000 
Dec 03 14:54:04 clockworkpi-a06 kernel: Call trace:
Dec 03 14:54:04 clockworkpi-a06 kernel:  clk_core_disable+0x26c/0x2a8
Dec 03 14:54:04 clockworkpi-a06 kernel:  clk_core_disable_lock+0x24/0x40
Dec 03 14:54:04 clockworkpi-a06 kernel:  clk_disable+0x20/0x30
Dec 03 14:54:04 clockworkpi-a06 kernel:  dw_mipi_dsi_bridge_post_disable+0xc8/0xf0 [dw_mipi_dsi]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_atomic_bridge_chain_post_disable+0x88/0xc8 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_atomic_helper_commit_modeset_disables+0x10c/0x428 [drm_kms_helper]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_atomic_helper_commit_tail_rpm+0x24/0x80 [drm_kms_helper]
Dec 03 14:54:04 clockworkpi-a06 kernel:  commit_tail+0xa4/0x1a0 [drm_kms_helper]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_atomic_helper_commit+0x160/0x388 [drm_kms_helper]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_atomic_commit+0x4c/0x60 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_atomic_connector_commit_dpms+0xec/0x118 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_mode_obj_set_property_ioctl+0x1d0/0x470 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_connector_property_set_ioctl+0x40/0x68 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_ioctl_kernel+0xc0/0x110 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  drm_ioctl+0x250/0x4a8 [drm]
Dec 03 14:54:04 clockworkpi-a06 kernel:  __arm64_sys_ioctl+0xa8/0xe8
Dec 03 14:54:04 clockworkpi-a06 kernel:  el0_svc_common.constprop.3+0x8c/0x1a8
Dec 03 14:54:04 clockworkpi-a06 kernel:  do_el0_svc+0x24/0x90
Dec 03 14:54:04 clockworkpi-a06 kernel:  el0_svc+0x14/0x20
Dec 03 14:54:04 clockworkpi-a06 kernel:  el0_sync_handler+0x90/0xb8
Dec 03 14:54:04 clockworkpi-a06 kernel:  el0_sync+0x160/0x180
Dec 03 14:54:04 clockworkpi-a06 kernel: ---[ end trace ee51f58146eb9d46 ]---

Upon more Googling, I found this thread that discusses a specific issue with how the panel interacts with our chipset and DRM.

Seems like a solvable bug but it is in Linux itself - losing some hope this is an easy fix.

Any news/progress/updates on this topic? Not being able to sleep/suspend is a mote in my eye!

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. :frowning:

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)

found while working on mainline kernel support for Manjaro ARM, and it seems to work well, at least when applied to 5.15

5 Likes

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. :slight_smile: