gnome-display-properties monitor layout not saved when re-docking (and display port)

[scm]

Binary package hint: gnome-control-center

This happens on Lucid 10.4.02 with gnome-control-center version 1:2.30.1-0ubuntu1

I am not sure this is specifically gnome-control-center, but I figured I'd start with that package and we can move as appropriate.

There appears to be two bugs here, but I wanted to keep the initial report as one issue, in case they're actually related. For what it's worth, I have reproduced this issue on a Lenovo X200 and have users internally who can reproduce this issue on a Lenovo X201 and a T410 on several different types and sizes of external monitor (all attached via display port -> DVI converters).

The two issues are:

- Windows "get lost" when display properties change.
- The display property preferences aren't saved when undocking / re-docking.

Here's how to reproduce:

- Install Lucid Laptop on an X200
- Attach the laptop to a docking station connected by display port -> dvr to a 24" monitor
- Configure (system -> preferences -> monitor) displays to not be mirrored, show monitors in panel checked, drag the monitor to a different orientation, and increase the resolution in the monitor to something other than what the laptop has.
- Open a web browser, put it in the 24" display.
- Open a terminal and a gnome app (I used gnome mine) in the laptop display.
- Detach the laptop (without suspending) to simulate going to a meeting, etc.

At this point the first bug (about windows getting messed up) occurs. Notice that, while the browser window is moved to the laptop display, the gnome mines and original terminal disappeared. If I open a new terminal and run ps, I can see they're still running, but they're not on any of my visible/accessible displays.

- Re-attach the laptop to the docking station

At this point, the second bug is reproduced. The monitor configuration has reverted to "mirrored displays." When I reset my preferences to what I want, the original browser window (as well as the preferences window) moves to the 24" monitor, but my gnome mines are still missing, as well as the original terminal (the new terminal I opened in the laptop while detached in order to check for the disappeared window's pids is moved to the new monitor).

[Evan Broder (broder)]

By default, GNOME runs with 4 virtual workspaces. For your first bug, I suspect that the windows you are "losing" are actually on a different virtual workspace. Try pressing Ctrl-Alt-Right arrow and see if your windows are there. Your window manager is responsible for reconfiguring windows when the monitor layout changes. This is a distinct bug from the other behavior you described, so it would be helpful if you could split that issue out to a different bug report. It should be filed against either the compiz package (if you have visual effects turned on) or the metacity package (if you have visual effects off).

As for the monitor layout issue, I see a few strange things going on, so let's start by gathering some more information:

 - Do you have a ~/.config/monitors.xml file? Can you attach it?

 - Run `touch ~/gsd-debug-randr`. If you then repeat your test cases above, you should get a ~/gsd-debug-randr.log file. Can you upload that as well?

[scm (scm)]

I reported Bug #733603 for the missing windows issues. I am not entirely sure it's unrelated still, given that it only happens when detaching, and not when manually switching between mirrored and unmirrored displays. There are screenshots there which I can upload here if you think it would be valuable.

In any case, I have a generated monitors.xml file, attached. This file does not change while detached.

I went ahead and copied the monitors.xml file during several points while reproducing the issue, to see if the file contents changed (basically, they didn't).

$ diff -ddu monitors.xml.back-to-disabled monitors.xml.whiledetached
$

There are changes between the original I made when I set up my display configuration, and the new one I made when I manually reset the configuration after reproducing the issue, but those differences are those that come from me resetting it slightly differently:

$ diff -ddu monitors.xml.back-to-disabled monitors.xml.mirroringdisabled
--- monitors.xml.back-to-disabled 2011-03-11 15:21:19.000000000 -0800
+++ monitors.xml.mirroringdisabled 2011-03-11 15:15:23.000000000 -0800
@@ -9,8 +9,8 @@
           <serial>0x00000000</serial>
           <width>1024</width>
           <height>768</height>
- <rate>85</rate>
- <x>414</x>
+ <rate>60</rate>
+ <x>402</x>
           <y>1200</y>
           <rotation>normal</rotation>
           <reflect_x>no</reflect_x>

I did try touching the file you indicated, but did not get any debug logs. Any other steps I can take to generate the debugging?

[Martin Pool (mbp)]

So this bug is now specifically about the fact that after reconnecting the external display, your monitors go back to mirrored mode, rather than resuming the configuration you had last time you are docked? (Since scm split out the other bug perhaps we should trim the description of this one.)

I can't reproduce that specific problem on natty: when I reconnect, the monitors resume their previous configuration. istr this was not working in previous Ubuntu releases.

[Martin Pitt (pitti)]

I tried this on the current lucid daily build, i. e. what soon will become 10.04.3. I used the exact same steps as in the bug description.

 * I do not get any lost windows, so I cannot reproduce this part.

 * I confirm that the screen configuration does not get restored when docking back, it goes to clone mode.

 * After reboot, the original side-by-side configuration is activated again.

[Martin Pitt (pitti)]

Reassigning to correct package. So it seems Martin Pool confirms that this is fixed in natty?

[Martin Pitt (pitti)]

I can still reproduce the bug in oneiric.

[Torsten Spindler (tspindler)]

I can reproduce this problem on a Lenovo T61 with a docking station, the monitor layout setting is not used. However, when I call
ApplyConfiguration via dbus, then the correct setting is applied:

dbus-send --type="method_call" --print-reply --session --dest=org.gnome.SettingsDaemon /org/gnome/SettingsDaemon/XRANDR org.gnome.SettingsDaemon.XRANDR.ApplyConfiguration

[Torsten Spindler (tspindler)]

Calling "gsd_xrandr_manager_apply_configuration (mgr, error);" unconditionally from plugins/xrandr/gsd-xrandr-manager.c handle_fn_f7 will restore the existing configuration as well. But fn-f7 cycling through display modes stops working, as the existing configuration will always take precedence.

Unfortunately I don't think gnome-settings-daemon has any idea that the system is being docked. So only conditionally calling apply_configuration from gsd-xrandr-manager.c handle_fn_f7 will most likely not work.

Is there any other place in the system that is run only when a system is being docked? From there we could call ApplyConfiguration via dbus.

Alternatively the fn-f7 modes should contain the saved configuration, the configurations are generated upon docking in
generate_fn_f7_configs:

        g_ptr_array_add (array, gnome_rr_config_new_current (screen));
        g_ptr_array_add (array, make_clone_setup (screen));
        g_ptr_array_add (array, make_xinerama_setup (screen));
        g_ptr_array_add (array, make_laptop_setup (screen));
        g_ptr_array_add (array, make_other_setup (screen));
        g_ptr_array_add (array, gnome_rr_config_new_stored (screen, NULL)); /* NULL-GError - if this can't read the stored config, no big deal */

[Torsten Spindler (tspindler)]

I followed the path of calling ApplyConfiguration from a script upon docking, and while it is not pretty, it basically works:

# cat /etc/udev/rules.d/80-thinkpad-T61.rules
KERNEL=="dock.0", ATTR{docked}=="1", RUN+="/usr/local/bin/dock.sh 1"
KERNEL=="dock.0", ATTR{docked}=="0", RUN+="/usr/local/bin/dock.sh 0"

# cat /usr/local/bin/dock.sh
#!/bin/sh

LOG=/tmp/dock.$$

echo "Called dock.sh with $@, proceeding" > ${LOG}

if [ $1 -eq 1 ]; then
  DISPLAY=:0.0
  export DISPLAY
  sudo -u ubuntu dbus-send --type="method_call" --print-reply --session --dest=org.gnome.SettingsDaemon /org/gnome/SettingsDaemon/XRANDR org.gnome.SettingsDaemon.XRANDR.ApplyConfiguration 2>&1 >> ${LOG}
fi

echo "Done docking" >> ${LOG}

Is this path worth pursuing or is this approach out of question for fixing the problem?

[Martin Pitt (pitti)]

Torsten Spindler [2011-09-15 11:58 -0000]:
> Is there any other place in the system that is run only when a system is
> being docked?

We don't have that, but current upower has a property for this, and
libupower-glib exports it. So you can hook a callback to that signal
to run somethign whenever the docking status fails.

[Torsten Spindler (tspindler)]

Unfortunately upower 0.9.1 on Ubuntu 10.04 LTS does not have up_client_get_is_docked. The earliest upower that has it is in Natty. Backporting this to Lucid seems like a task, due to dependencies:

dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 8) libusb-1.0-0-dev (>= 1.0.0) libimobiledevice-dev (>= 0.9.7) libgirepository1.0-dev (>= 0.9.12) gobject-introspection (>= 0.9.12-4~) gir1.2-glib-2.0

[Evan Broder (broder)]

gnome-settings-daemon listens for drm udev events to trigger automatic
layout updates. As it turns out, upower's current definition for "is
this machine docked" is "does this machine have more than one output
connected", and it...also listens for udev events - specifically from
drm, not dock devices - to trigger updating its internal value.

(upower doesn't use any of the actual ACPI dock detection mechanisms
because most modern docks don't actually register as ACPI docking
stations, so they don't show up at all in ACPI)

So in this particular case, upower doesn't know anything that g-s-d doesn't.

[Torsten Spindler (tspindler)]

The attached python script utilizes pyudev (available from Natty onward) to wait for docking events and then calls gnome-settings-daemon ApplyConfiguration method. It's a slight improvement over the udev rules hackery before. Would be interesting to hear if this approach resolves the original issue or not.

[hepaly (hurezi)]

This bug is present in Ubuntu 12.10. If I undocking the laptop from docking station, and after that re docking it, and press any key on keyboard, then the display setting goes to mirror mode by automatically. If I do not use the docking station, and disconnect/connect the 2nd monitor to laptop directly, this problem does not occur.
HW: Dell Latitude E6520
Sorry for my bad english :)

[strattonbrazil (strattonbrazil)]

This is still happening for me on Ubuntu 14.04 on a Thinkpad 440S. When I undock and redock the external monitor physically on the left side is configured to be on the right and the activities bar remains on the laptop. If I reset the machine while docked it returns to the correct state.