unity-settings-daemon can deadlock if a modeset fails

[Aaron Plattner]

The system I used to reproduce this bug was a laptop with two display devices (one DisplayPort, one DVI) connected to a docking station.

Dock the laptop. unity-settings-manager triggers a display change to extended mode. Then, undock the laptop. The following sequence of events triggers a deadlock:

1. The system generates an ACPI event that video.ko turns into a display change hotkey press.
2. Something sees the display change hotkey event and calls unity-settings-manager via dbus.
3. The X driver sees the DVI monitor go away and updates the RandR configuration.
4. unity-settings-manager enters handle_fn_f7() and calls gnome_rr_screen_refresh().
5. gnome_rr_screen_refresh() sees that the configuration changed and calls the callbacks.
6. The X driver sees the DP monitor go away and updates the RandR configuration.
7. on_randr_event() tries to reconfigure the desktop with the DVI monitor disabled and the DP monitor enabled.
8. The RandR SetCrtcConfig call fails because it's trying to set a mode on a disconnected output.
9. apply_configuration() calls error_message(), which tries to pop up a dialog box.

Step #9 deadlocks because gnome_rr_screen_refresh() called XGrabServer() in step #5.

Upstream gnome-settings-daemon fixed this with commit 0f7cbfed5e5e76824e057ce9c570fad66ba001c6.
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=0f7cbfed5e5e76824e057ce9c570fad66ba001c6

This change cherry-picks cleanly to unity-settings-daemon.

(as an aside, the video.ko display change hotkey events are entirely pointless and probably deserve their own bug)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.