I would like to share a solution to a problem that has bothered my Reform since a little while back: after long (>1h) idle periods while powered on, it would sometimes be completely unresponsive when I return. Instead of showing the swaylock prompt, the screen would stay dark. The power LEDs are still on, and I can reboot the machine via the circle key; but otherwise, I cannot get any response nor see anything indicating an issue in the logs. The latter would simply cease to update at some point (usually there is a lot of noise concerning the wifi connection in there). I monitored the SER1 port to see whether I could see any messages that would help to debug this issue, but even there the messages would simply stop at some point.
I got help and several good suggestions on IRC from josch, vkoskiv violet who helped me find the most likely candidate for this problem: in my sway configuration, I disabled the screen (dpms off) which is apparently under suspicion of causing such hangs. I replaced this with a call to set the brightness to 0 instead and have not seen any hang since then! It has only been a little more than a day of continuous running, but I thought Iād share the progress so far.
The fix in more detail: in your ~/.config/sway/config file, replace the swayidle command line with the following:
This will lock the screen after 300 seconds (5 min). After 600 seconds, the current brightness level is stored, and then set to 0 (no backlight). On a resume, the previous setting will be restored.
For the record: when I still had the setting to ādpms offā, I noticed that whenever I pressed any key to resume the laptop, the serial console would immediately show the following line (which then also appeared in the logs):
reform kernel: imx-dcss 32e00000.display-controller: Pixel clock set to 118800 kHz instead of 162000 kHz.
Could this be an indication as to why the Reform hangs with the dpms off setting?
Hope this helps someone else with similar problems!
Your [solved] in the title actually made me hopeful you found a solution to the problem!
Yes, using brightnessctl is the workaround I use myself. reform-tools should probably stop suggesting to use dpms in the commented out piece of code in its default sway config. I submitted a MR to do that here:
Of course this cannot fix userās configurations as those are not touched when upgrading packages.
Sorry for getting your hopes up! I changed the title now.
I am just so happy that I can let my Reform run unattended and feeling confident that it will still talk to me when I return!
I was worried I might have a hardware issue ā but now I believe it could ājustā be software: I do remember that after suspend had stopped working with a kernel upgrade that I let the Reform simply run occasionally and I do not remember any issues āback thenā. It is really hard to pin-point this problem though as this is not a typical use case for me.
What do you make of that log message concerning the pixel clock: could that be relevant or is that a red herring?
BTW, if you any suggestions for further investigations, let me know! As neither logs nor SER1 provided much useful information, I was quite stuck; but knowing that it relates to the display might help! How can one gather more insights into what is going on?
The ONLY negative I see with this is that the display is still being sent data, instead of just being off. You are effectively still wasting display life like this, and just giving the backlight a break.
Not sure, really, I had not considered that. Is this type of display particularly susceptible to āburning outā? What is the expected life time, do you happen to know?
By the way, you did report earlier that resume from suspend works for you now, right? I just gave that a shot after the kernel upgrade but the Reform would not come back to life ā in a very similar way as with the hangs I observed when using dpms off. So now I am wondering whether the two fault states are relatedā¦
Or was there anything extra needed to make suspend work that I might have missed?
Yes, it is totally working for me. (Suspend) 200+ successful resumes. Big thing for my is that I started with a system v3 from scratch and have been upgrading from there. My particular usage is, nvme for storage, boot from SD.
Like this I have perfect suspend success on 6.5. I mean across every situation that use to trip it up before as well.
This is using a reform suspend script setup as a service with systemd. All of this is part of the system image though. I think there is a script called reform-check which can tell you how your system differs from stock, and what you can do to rectify it. At least I think that is the point. Very awesome little tool.
Hope that helps. The Reform with fully functional suspend is awesome.
Yeah, I used suspend frequently when it was still working for me!
My boot setup differs from yours then, and my nvme is encrypted ā but I do not have changed much else from the v3 I believe. At least reform-check gives me a near-pass, but I have not fixed some details after the last kernel update. Shall do that now!
I am wondering though: do you use dpms off in your swayidle call (if you do use sway)? Does that work reliably for you?
I do use sway and I use dpms off with swayidle. I try to not leave the system like that for more than an hour, which prevents it from causing an issue.
With suspend working well these days, I am barely using my lock key which is would typically trigger the swayidle commands.
If even the dpms commands work well for you then I am wondering whether that is maybe a common issue between display on/off and suspend hangsā¦ I might try booting into a mint v3 image from SD card to try suspend and dpms switching thereā¦
I changed the title now.
