New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workspaces not moved when detaching from dock #3487

idevai opened this Issue Oct 30, 2018 · 3 comments


None yet
4 participants

idevai commented Oct 30, 2018

I'm submitting a…

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

Current Behavior

My computer is having an external 3440x1440 display and has a built in 1920x1080 LCD panel. When connected to the docking station, both outputs are on, fully usable, has an i3bar on both. On the external display, I open a single gedit, while on the build-in LCD, I open a terminal and a browser. When removing the notebook from the dock, the gedit (and its workspace) is not moved to the LCD panel output, however the gedit keeps running and with the mouse cursor I can access the virtual area where is stays. However, if I execute an xrandr command to get rid of the virtual portion of the X screen, the workspace which was open on the external display does get moved over to the built-in one.

Expected Behavior

That all workspaces are moved over to the built-in LCD when detached. I'm wondering if the virtual screen area shown in the xrandr output is due to some new xrandr behavior or due to i3?

Reproduction Instructions

These are the instructions I've generated the logfiles with:

  1. open gedit on external display (DP-1-2)
  2. open terminal/browser on internal display (eDP-1)
  3. dump the xrandr config into file "xrandr_before"
  4. in-place-restart i3
  5. Do an i3-msg nop
  6. detach PC from dock
    (this is the point when the bug happens)
  7. Do an i3-msg nop
  8. dump the xrandr config into file "xrandr_after"
  9. execute xrandr command: xrandr -s 1920x1080
  10. Do an i3-msg nop
  11. dump the xrandr config into file "xrandr_after_cmd"

(Note: I've added the NOP's so it's easier to pinpoint the part in the log where the dock detach happens. Just search the log for text "NOP:")


Output of i3 --moreversion 2>&-:

$ i3 --moreversion 2>&- || i3 --version
Binary i3 version:  4.15 (2018-03-10) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.15 (2018-03-10) (pid 7890)o abort…)
Loaded i3 config: /home/user/.config/i3/config (Last modified: Di 30 Okt 2018 12:45:44 CET, 487 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3-with-/i3
Running default i3 config from URL
All 4 files are in the gist:
- Linux Distribution & Version: Ubuntu 18 LTS, kernel 4.19.0-041900-generic #201810221809 SMP Mon Oct 22 22:11:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
- Are you using a compositor (e.g., xcompmgr or compton): yes, 0.1~beta2+20150922-1

@i3 i3 deleted a comment from i3bot Oct 30, 2018


This comment has been minimized.


Airblader commented Oct 30, 2018

That's because when you simply remove it from the dock, thee RandR output isn't actually turned off, but just disconnected. You can verify this by running xrandr --output <output> --off, which will turn it off and then the workspace should move.

This is actually the intended behavior.


This comment has been minimized.

idevai commented Oct 30, 2018

@Airblader I've verified but it did not work the way described in your comment above. After undocking and turning the output off via xrandr, the xrandr has shown everything as it was after undocking (after undocking=disconnected for DP-1-2, after --off=disconnected). The virtual output (see my gist, xrandr_after) also stayed there (which is listed at the very end of the xrandr output, and only disappears if I manually reset the screen size via xrandr -s 1920x1080), as described in the ticket description above.

IMHO the main question is, why that virtual output thing is used at all. In my experience, with Ubuntu 16LTS, it did not work this way (when undocking, the workspaces were moved immediately, without needing a screen resize manually).


This comment has been minimized.

idevai commented Nov 13, 2018

After upgrading to 4.16, the above issue disappeared. Actually I had other issues besides that (eg when re-docking) and those are fixed as well.

@idevai idevai closed this Nov 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment