5 ms·

Maybe tie those systemctl commands to the power button and state, so it restarts the screen every time you blank the screen, or when coming back on use a restar

Maybe tie those systemctl commands to the power button and state, so it restarts the screen every time you blank the screen, or when coming back on use a restart for the service? I have a feeling mainstream phones use all sorts of these ux hacks in the background - it only looks good, under the hood is just as messy and chaotic as any other software/hardware collision.

megous 5y ago
LCD controller is restarted/reinitialized every time you "blank" it. So this would be useless. Likely GPU driver/mesa/compositor crashing. I never have any issues with the screen when using i3wm (with GPU acceleration disabled). These bug reports would be more useful, if the OP did some debugging/log hunting.
spijdar 5y ago
In this case, what's happening (based on what GP says, not personal experience) is the window server (phosh as a wayland compositor or Xorg in sxmo's case) is crashing, possibly (probably?) due to a crash in the Mali driver or some sunxi component managing the physical display output. Restarting the window server here would "reset" the relevant GPU bits, and get the display back. It also will (effectively) restart the whole graphical session, e.g. close all GUI things, so not feasible to do every time you cycle the screen, at least for most people. (some OSes and window servers like the Windows GUI stack can restart the GPU driver without killing the GUI, but Linux isn't ... particularly capable of this, at any part of the stack, AFAIK at least)
- chrismorgan 5y ago
  Sway in sxmo’s case, actually. I’m not sure what exactly is falling over, but the session is all still there, with the compositor (Sway or Phosh) still responding to I/O, and, from my very limited probing, still working perfectly… except that its screen output is dead and it doesn’t realise it. Nothing interesting in the journal or dmesg, for example. If the compositor had crashed, it would have been restarted automatically.
  - spijdar 5y ago
    Ah, interesting, I didn't know they'd built an alternative shell around wlroots, I'd only tried it back when it was a bunch of shell scripts around dwm. If the GPU and window server are still okay, you might get away with forcing a mode-switch. Maybe it's not the GPU itself but some supporting chip that handles the LCD driver, and changing the resolution or something else would reset it without destroying the session. Hmmm...
    - chrismorgan 5y ago
      Hmm, would be nice to be able to get it back on its feet in these cases without killing the session, though I haven’t had it fall over for a couple of weeks because I’ve been barely using it (and possibly because summer is passes on to autumn). Next time it happens I’ll see if a `swaymsg output DSI-1 disable` / `swaymsg output DSI-1 enable` fixes it. Seems to do something, Firefox clearly changes its scaling from 2 to 1 and back to 2 in the process. (If not, I dunno; `swaymsg -t get_outputs` only mentions one mode, 720x1440 @ 60.006 Hz, and --custom doesn’t seem to be working. What’s with that frequency? I know the sordid tale of 59.94 Hz, but I’ve seen these higher frequencies of 30 and a bit and 60 and a bit a few times.))
      - chrismorgan 5y ago
        Successfully triggered it (drained half the battery, plugged it in with a couple of infinite loops going and a bit of hotspot usage), and alas, attempts at mode switching aren’t solving it: `swaymsg output DSI-1 disable && swaymsg output DSI-1 enable`, `swaymsg -- output DIS-1 mode --custom 360x720`, all this kind of stuff causes the screen to turn off and back on again, but not start working again. Actually, though, I’ve found something useful in dmesg, which is making me suspect that the other time I went looking I forgot to look there and only looked at journald. [Mar14 21:17] [drm:lima_sched_timedout_job] *ERROR* lima job timeout [ +3.422897] lima 1c40000.gpu: fail to save task state from sway pid 3227: error task list is full [ +0.000115] lima 1c40000.gpu: gp task error int_state=0 status=0 Then a trace, including pc and lr being inside lima_devfreq_record_idle, which might point towards something about it not happening when the device is in active use. And yeah, lima is GPU driver. Well, it’s something. Hmm, wonder if I can be bothered delving further. It doesn’t bother me as much as it possibly should, I really don’t interact with my phone directly all that much. (Seems to be reported as https://gitlab.freedesktop.org/mesa/mesa/-/issues/6036 https://gitlab.freedesktop.org/mesa/mesa/-/issues/6036.)

megous 5y ago

LCD controller is restarted/reinitialized every time you "blank" it. So this would be useless. Likely GPU driver/mesa/compositor crashing. I never have any issues with the screen when using i3wm (with GPU acceleration disabled). These bug reports would be more useful, if the OP did some debugging/log hunting.

spijdar 5y ago

In this case, what's happening (based on what GP says, not personal experience) is the window server (phosh as a wayland compositor or Xorg in sxmo's case) is crashing, possibly (probably?) due to a crash in the Mali driver or some sunxi component managing the physical display output. Restarting the window server here would "reset" the relevant GPU bits, and get the display back. It also will (effectively) restart the whole graphical session, e.g. close all GUI things, so not feasible to do every time you cycle the screen, at least for most people. (some OSes and window servers like the Windows GUI stack can restart the GPU driver without killing the GUI, but Linux isn't ... particularly capable of this, at any part of the stack, AFAIK at least)

chrismorgan 5y ago
Sway in sxmo’s case, actually. I’m not sure what exactly is falling over, but the session is all still there, with the compositor (Sway or Phosh) still responding to I/O, and, from my very limited probing, still working perfectly… except that its screen output is dead and it doesn’t realise it. Nothing interesting in the journal or dmesg, for example. If the compositor had crashed, it would have been restarted automatically.
- spijdar 5y ago
  Ah, interesting, I didn't know they'd built an alternative shell around wlroots, I'd only tried it back when it was a bunch of shell scripts around dwm. If the GPU and window server are still okay, you might get away with forcing a mode-switch. Maybe it's not the GPU itself but some supporting chip that handles the LCD driver, and changing the resolution or something else would reset it without destroying the session. Hmmm...
  - chrismorgan 5y ago
    Hmm, would be nice to be able to get it back on its feet in these cases without killing the session, though I haven’t had it fall over for a couple of weeks because I’ve been barely using it (and possibly because summer is passes on to autumn). Next time it happens I’ll see if a `swaymsg output DSI-1 disable` / `swaymsg output DSI-1 enable` fixes it. Seems to do something, Firefox clearly changes its scaling from 2 to 1 and back to 2 in the process. (If not, I dunno; `swaymsg -t get_outputs` only mentions one mode, 720x1440 @ 60.006 Hz, and --custom doesn’t seem to be working. What’s with that frequency? I know the sordid tale of 59.94 Hz, but I’ve seen these higher frequencies of 30 and a bit and 60 and a bit a few times.))
    - chrismorgan 5y ago
      Successfully triggered it (drained half the battery, plugged it in with a couple of infinite loops going and a bit of hotspot usage), and alas, attempts at mode switching aren’t solving it: `swaymsg output DSI-1 disable && swaymsg output DSI-1 enable`, `swaymsg -- output DIS-1 mode --custom 360x720`, all this kind of stuff causes the screen to turn off and back on again, but not start working again. Actually, though, I’ve found something useful in dmesg, which is making me suspect that the other time I went looking I forgot to look there and only looked at journald. [Mar14 21:17] [drm:lima_sched_timedout_job] *ERROR* lima job timeout [ +3.422897] lima 1c40000.gpu: fail to save task state from sway pid 3227: error task list is full [ +0.000115] lima 1c40000.gpu: gp task error int_state=0 status=0 Then a trace, including pc and lr being inside lima_devfreq_record_idle, which might point towards something about it not happening when the device is in active use. And yeah, lima is GPU driver. Well, it’s something. Hmm, wonder if I can be bothered delving further. It doesn’t bother me as much as it possibly should, I really don’t interact with my phone directly all that much. (Seems to be reported as https://gitlab.freedesktop.org/mesa/mesa/-/issues/6036 https://gitlab.freedesktop.org/mesa/mesa/-/issues/6036.)