wf-shell icon indicating copy to clipboard operation
wf-shell copied to clipboard

LG monitor hotplug on DPMS wake causes several apps to either crash or lose their windows on output recovery

Open kode54 opened this issue 1 year ago • 6 comments

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:

  1. Enable output recovery
  2. DPMS cycle the monitors, causing LG 24UD58-B to disconnect for just a moment on DPMS "on" setting.
  3. sfwbar or wf-panel are lost from the restored display.

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

kode54 avatar May 23 '24 04:05 kode54

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.

kode54 avatar May 23 '24 21:05 kode54

Logs attached to bug report.

kode54 avatar May 24 '24 02:05 kode54

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?

ammen99 avatar Jun 11 '24 15:06 ammen99

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?

kode54 avatar Jun 12 '24 04:06 kode54

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.

LBCrion avatar Jun 13 '24 07:06 LBCrion

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.

kode54 avatar Jun 13 '24 07:06 kode54