search

WayfireWM / wf-shell

A GTK3-based panel for wayfire
https://wayfire.org/
MIT License
137 stars 35 forks source link

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

Open kode54 opened 5 months ago

kode54 commented 5 months ago

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 commented 5 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.

kode54 commented 5 months ago

Logs attached to bug report.

ammen99 commented 4 months ago

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?

kode54 commented 4 months ago

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?

LBCrion commented 4 months ago

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.

kode54 commented 4 months ago

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.