Monitor priority not respected after 'awakening' from hibernation

[promitheas17j]

I have two montiors vertically stacked. Desktops 1, 2, 3, and 4 are on the bottom monitor (which I consider to be main), and 5, 6, 7, and 8 are on the top monitor. In my bspwmrc I have the following lines:

bspc monitor HDMI-A-0 -d I II III IV

if [[ $(xrandr -q | grep "HDMI-A-1 connected") ]];
then
    xrandr --output HDMI-A-0 --primary --mode 1920x1080 --pos 0x0 --rotate normal
    xrandr --output HDMI-A-1 --mode 1920x1080 --rotate inverted --above HDMI-A-0
    bspc monitor HDMI-A-0 -d 1 2 3 4
    bspc monitor HDMI-A-1 -d 5 6 7 8

    bspc wm -o HDMI-A-0 HDMI-A-1
fi

however, on login or on awakening from hibernation/sleep, if I am to press super + 2/3/4 instead of switching the desktops on the bottom monitor it switches the desktops on the top one. Note that the displayed numbers are correct. For example on the top monitor if desktop number 5 is the currently active one, and I hit super+2 it will switch to desktop number 6 on the top monitor.

I can reset this by hitting super+alt+r to restart bspwm. Then the expected behaviour is valid until the next wake from sleep/hibernation.

Expected behaviour: Having desktops 1, 2, 3, 4 on the bottom monitor, and 5,6,7,8 on the top monitor, hitting the combination super+<number> will switch to the correct desktop on the correct monitor.

[promitheas17j]

I think I solved it. I had to actually do it from sxhkdrc and change the way the workspaces are referenced (not by index but by name).

Here is the solution for anyone else wondering:

In sxhkdrc, instead of referencing the index of the workspace by doing:

super + {_,shift + }{1-9, 0}
  bspc {desktop -f, node -d} '^{1-9,10}'

Switch to the workspace based on its name. This means that if the names are set correctly in bspwmrc to the correct monitors, then it will always find the correct one.

# Focus given desktop
super + {0-9}
    bspc desktop {0-9} -f

# Send to the given desktop
super + shift + {0-9}
    bspc node -d {0-9}

Here is the issue that sent me on the right path: #1375