i3: since 4.19, workspaces don't move to configured output when it gets available

I’m submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

example config: workspace 1 output DisplayPort-0

When DisplayPort-0 is not connected, workspace 1 displays on a different output. When DisplayPort-0 gets connected, workspace 1 doesn’t move to output DisplayPort-0 like it did pre 4.19.

Expected Behavior

When the configured output gets available, the workspace should move to the output like in pre 4.19 versions.

Reproduction Instructions

Environment

Output of i3 --moreversion 2>&-:

i3 version:  4.19
- Linux Distribution & Version: Arch Linux
- Are you using a compositor (e.g., xcompmgr or compton): xcompmgr

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 6
  • Comments: 16 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Hello.

Having the same issue I did a bisect and the issue is caused by 0d5a7eeff8e95277256fb191f80112296e0aba6f.

In this commit, instead of iterating over assignation rules, we iterate over the workspaces directly. The issue seem to be caused by the fact that since we may move the workspace into another output (by calling the workspace_move_to_output function), we modify the list we are iterating on. The example scenario works as follow: init_ws_for_output is called with “OUTPUT-2” We iterate over the workspaces of “OUTPUT-1”, when we found workspace “w” that should be on “OUTPUT-2”, we do the required change but then we continue to iterate over “OUTPUT-2”. We iterate again over the workspases of “OUTPUT-2”. END. In the end only the first found workspace is correctly assigned to the display.

However I don’t know how to fix this in a clean way because I didn’t find a way to iterate over list while being modified.

@orestisfl scenario:

  • start i3
  • open termite on workspace f1 on output DVI-D-0 and workspace 1&2 on output DisplayPort-0
  • workspace 2 focused on output DisplayPort-0
  • switch off output DisplayPort-0 via mode $mode_display:
    • bindsym h exec --no-startup-id $HOME/.screenlayout/hostmode.sh (xrandr --output DVI-D-0 --primary --mode 1920x1080 --pos 0x0 --rotate normal --output DisplayPort-0 --off --output HDMI-A-0 --off)
    • bindsym Escape mode "default", restart
  • switch on output DisplayPort-0 via mode $mode_display:
    • bindsym d exec --no-startup-id $HOME/.screenlayout/monitor.sh (xrandr --output DVI-D-0 --mode 1920x1080 --primary --pos 0x0 --rotate normal --output HDMI-A-0 --off --output DisplayPort-0 --mode 1920x1080 --rate 240 --pos 1920x0 --rotate normal)
    • bindsym Escape mode "default", restart

see config in logs.

https://logs.i3wm.org/logs/5632642737242112.bz2 4.18.3 https://logs.i3wm.org/logs/5769834260332544.bz2 4.19

Workaround. I put this on the end of my monitor enabling script:

i3-msg -t run_command 'workspace "5"; move workspace to output DisplayPort-1;'
i3-msg -t run_command 'workspace "6"; move workspace to output DisplayPort-1;'
i3-msg -t run_command 'workspace "7"; move workspace to output DisplayPort-1;'
i3-msg -t run_command 'workspace "8"; move workspace to output DisplayPort-1;'
i3-msg -t run_command 'workspace "9"; move workspace to output DisplayPort-1;'
i3-msg -t run_command 'workspace "10"; move workspace to output DisplayPort-1;'

(of course, edit for your own workspaces and display ports)

I will do it tomorrow.