Open kode54 opened 6 months ago
I'll try to log some WAYLAND_DEBUG logs for the relevant services tonight, if I can get anything useful out of it. Both of the panels are Wayland apps, so it should be fairly easy to WAYLAND_DEBUG either of them and coax some display output recovery attempts.
Logs attached to bug report.
This honestly sounds like a bug in wf-panel and sfwbar, I can't imagine what wayfire would do so that you don't see any panels there. Do the output(s) work fine otherwise after the dpms cycle?
Probably is a bug for those panels, but it doesn't happen on labwc. The outputs are otherwise usable after the output recovery. Maybe output recovery isn't recovering layer shell windows?
You hopefully shouldn't lose the bar on monitor disconnect with the latest git version of sfwbar. There seems to have been a change in behaviour in gtk/gtk-layer-shell/wlroots interaction over the last few months. Previously, we could watch for output destruction and graciously unmap the bar on the event. Now the bar surface gets unmapped before we're notified of the output destruction and we need to handle the "delete" event on the bar sent by gtk-layer-shell.
I’m sorry I didn’t report these directly to your repository, I had initially thought they were compositor problems. I’ll try to remember reporting application/compositor interactions to both ends where possible.
edit: and thanks for catching this post.
Describe the bug Several applications annoyingly don't recover on the output recovery cycle. Notably, wf-panel and sfwbar both randomly either get stuck at scale 1.0 on my scale 2.0 monitor when recovered, or sometimes even lose their status bars on the hotplugged output altogether.
To Reproduce Steps to reproduce the behavior:
Expected behavior The status bars should recover more readily onto the restored display.
Screenshots or stacktrace Supplying logs of sfwbar and wf-panel reacting to output power states: sfwbar_output_wldebug.log.txt wfpanel_output_wldebug.log.txt
Wayfire version wayfire-git 0.8.1.r302.g5b4f9b94-1