baskerville / bspwm

A tiling window manager based on binary space partitioning
BSD 2-Clause "Simplified" License
7.74k stars 414 forks source link

Desktops disappearing if external monitors are changed #522

Open vlaci opened 8 years ago

vlaci commented 8 years ago

I am using bspwm 0.9.1-90-gcfe5e42 both remove_disabled_monitors and remove_unplugged_monitors are set to false, I handle monitor removals from a script.

Steps to reproduce

  1. Attach a secondary monitor to output "HDMI" (for example), a new desktop named "Desktop" is created on it
  2. Add a new desktop to it: bspc monitor HDMI -a new
  3. Remove the original "Desktop" desktop: bspc desktop Desktop -r
  4. After that, only "new" desktop should be present on monitor "HDMI"
  5. Remove the monitor (disconnect cable)
  6. Notice, that the "new" desktop disappears and "Desktop" reappears

    Expected behavior

No change should occur, "new" desktop should remain the only desktop on that output. This is the case if I'd used bspc desktop Desktop -n new or bspc monitor HDMI -d new instead of my 'create then remove' approach

Backgound

I am working on a solution to dynamically move desktops between monitors when one is added or removed (notebook user here). I only want to move existing desktops, that's why I delete, not rename the automatically created 1st one after I moved over some from the builtin monitor.

baskerville commented 8 years ago

Unfortunately, I don't have an external monitor, so I won't be able to debug this myself.

What might help is the output of bspc subscribe monitor desktop node during the plugging/unplugging steps.

vlaci commented 8 years ago

In this example DP1-3 output is used. I hope I didn't mess up the which events come after which action...

# monitor plugged in
monitor_geometry 0x00200001 1600x900+0+0
monitor_geometry 0x00200001 1600x900+0+0
monitor_geometry 0x00200001 1600x900+0+0

# xrandr --output DP1-3 --auto --right-of eDP1
monitor_geometry 0x00200001 1600x900+0+0
monitor_add 0x00200016 DP1-3 1920x1080+1600+0
desktop_add 0x00200018 Desktop 0x00200016
monitor_geometry 0x00200001 1600x900+0+0
monitor_geometry 0x00200016 1920x1080+1600+0

# bspc monitor DP1-3 -a new
desktop_add 0x00200011 new 0x0020000E

# bspc desktop Desktop -r
desktop_remove 0x0020000E 0x00200010

# monitor unplugged
monitor_geometry 0x00200001 1600x900+0+0
desktop_add 0x0020001A Desktop 0x00200016
monitor_geometry 0x00200001 1600x900+0+0

# xrandr --output DP1-3 --off 
monitor_geometry 0x00200001 1600x900+0+0
monitor_geometry 0x00200001 1600x900+0+0

# bspc monitor DP1-3 -r
monitor_remove 0x0020000E
desktop_remove 0x0020000E 0x00200012
vlaci commented 8 years ago

For some additional detail, if I add multiple new desktops, both are disappearing after I unplug the monitor

# add new desktops
desktop_add 0x00200024 new1 0x00200021
desktop_add 0x00200025 new2 0x00200021
# remove default one
desktop_remove 0x00200021 0x00200023
# after unplugging
monitor_geometry 0x00200001 1600x900+0+0
desktop_add 0x00200026 Desktop 0x00200021
monitor_geometry 0x00200001 1600x900+0+0
# bspc subscibe after unplugging
WMeDP1:O1:o2:f3:f4:f5:LT:TT:G:mDP1-3:FDesktop:LT
baskerville commented 8 years ago

Is merge_overlapping_monitors set?

It might be worth recording the output of xev -root too.

vlaci commented 8 years ago

merge_overlapping_monitors is not set I've put together a simple repro script that contains xev -root and bspc subscribe outputs too. I only switched the output off via xrandr this time as it was enough to trigger the issue

msteen commented 7 years ago

I tried to reproduce this issue, but was unable to do so. Whether I unplug my external monitor or remove it via xrandr, it has no effect on the state of bspwm, which seems correct to me, you would not want the monitor to be removed from bspwm when you accidentally unplug your monitor cable. If I remove the monitor explicitly via bspc monitor <external_monitor> --remove then indeed its desktops will be removed in the process as well. Maybe a better behavior would be to move those desktops to the previous monitor in the list of monitors? (Edit: It seems that with remove_unplugged_monitors and remove_disabled_monitors set to true, removing a monitor with xrandr already behaves like this). Or maybe make it an option if there are good reasons for the current behavior that I am not seeing. Maybe even have a lastMonitor in the state, so that if the monitor is reintroduced they would move back to that monitor instead of making a default desktop for that monitor. This could alternatively also be scripted by keeping track of the last monitors yourself and moving the desktops over before removing the monitor, but I consider ending up with unmanaged windows after removing a monitor to be a bug. It should at least error like removing a non-empty desktop does.

@vlaci If you still have this issue in the latest version, let me know, maybe I missed something in trying to reproduce it.