4 ms·

As an example of the flakiness: if I use my PinePhone heavily, the screen tends to stop working spontaneously, so that if on at the time of failure, it ceases t

As an example of the flakiness: if I use my PinePhone heavily, the screen tends to stop working spontaneously, so that if on at the time of failure, it ceases to update, and when turned off and on again it will be black. Touch input still works. Restarting the graphical session (e.g. ssh in and run `systemctl restart phosh` for phosh or `systemctl restart tinydm` for sxmo) fixes it. “Heavily” tends to mean at least three of (a) heavy hotspot usage, (b) heavy CPU usage, (c) plugged in/charging, and (d) screen on, but if I’m physically using it it seems less likely to happen. Note that this is mostly with ambient temperatures of 25–30°C; come winter, I suspect it will happen less often. Plus there’s also the screen flickering thing, that sometimes, mostly when it’s been being used heavily but sometimes when it’s been idle and barely even warm, the screen is all flickery and ghosty when you turn it on one time, in which case it will normally stay like that for quite some time. That I observed right from the very start, under whatever the default OS was (Alpine, I think?, with Plasma; I subsequently switched to DanctNIX Arch with Phosh, and more recently from Phosh to sxmo). I have no idea if these things are typical or not, or if there are known solutions. I haven’t looked. They don’t tend to bother me much, I don’t really depend on a phone except for my internet supply.

robbedpeter 5y ago
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.))
jcelerier 5y ago
The "phone stuck with black screen" thing happened to me on every android phone I ever had though (and here I can't restart the x session, I have to reboot it or take off the physical battery when things go really bad), so maybe it's more of a kernel level issue ?
- OJFord 5y ago
  Yeah I was about to say I have a very similar problem with my Nokia 3.4. I can usually hold power to reboot though, which I think after long enough it does itself. Sometimes I'm only aware of it (not currently using it, certainly not heavily) because it suddenly reboots itself.

robbedpeter 5y ago

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

jcelerier 5y ago

The "phone stuck with black screen" thing happened to me on every android phone I ever had though (and here I can't restart the x session, I have to reboot it or take off the physical battery when things go really bad), so maybe it's more of a kernel level issue ?

OJFord 5y ago
Yeah I was about to say I have a very similar problem with my Nokia 3.4. I can usually hold power to reboot though, which I think after long enough it does itself. Sometimes I'm only aware of it (not currently using it, certainly not heavily) because it suddenly reboots itself.