3 ms·

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

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

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