After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644230 - Everybody freeze! smooth xrandr transitions
Everybody freeze! smooth xrandr transitions
Product: gnome-shell
Classification: Core
Component: general
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
Depends on:
Blocks: 648051
Reported: 2011-03-08 18:15 UTC by Owen Taylor
Modified: 2021-07-05 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---

Add a mechanism for smooth xrandr transitions (4.63 KB, patch)
2011-06-07 22:35 UTC, Rui Matos
none Details | Review
Ok, I added a D-Bus method to open the curtain. (4.99 KB, patch)
2011-06-08 18:33 UTC, Rui Matos
none Details | Review
Also prevent events from being propagated to other actors. (5.14 KB, patch)
2011-06-21 01:25 UTC, Rui Matos
needs-work Details | Review

Description Owen Taylor 2011-03-08 18:15:34 UTC
When the monitor configuration changes, we want this to be as atomic as possible - we don't want the old panel layout to get scanned out on the new monitors.

A simple approach to making this work would be:

 g-s-d sends a DBus message to org.gnome.Shell before changing the configuration
  and waits for the response
    gnome-shell makes all output black
 g-s-d reconfigures everything
 g-s-d sends a DBus message to org.gnome.Shell
    gnome-shell processes the new monitor configuration and does new layout
    gnome-shell restores the display

(Or maybe g-s-d turns off the outputs during the transition rather than having gmome-shell do the blanking to black)

Doing better than going to black temporarily would require breaking apart:

  - Swapping the front buffer that clients are rendering two
  - Swapping the scan out buffer going to the display device

And doing those as two separate steps so layout and redraw were done before the scanout buffer is changed. There may be plans for this for xrandr-1.4?
Comment 1 Bastien Nocera 2011-03-10 18:49:43 UTC
Does anyone know the plan for XRandR 1.4? Would support for the above still be needed? If so, I'll open a separate gnome-settings-daemon bug.

What sort of interface would you be looking for, just a callout to org.gnome.Shell?
Comment 2 Bastien Nocera 2011-05-31 16:57:06 UTC
Moving the discussion from bug 650603.

(In reply to comment #14)
> > 6. if the orientation changed, g-s-d will send out a signal to the shell before
> > changing the orientation, change it, and send out another signal
> > 
> > enum {
> >   ORIENTATION_180,
> > } Orientation;
> > enum {
> > } OrientationNotification;
> > 
> > void ScreenOrientationChanged (Orientation new_orientation,
> >                                Orientation old_orientation,
> >                                OrientationNotification type);
> - Given this API, how does g-s-d know it's safe to proceed after sending out
> the "PRE" signals?
> - How do you see this differing from a more generic "monitor layout change"?
> Are there specific things that you would expect the shell to do to move windows
> around on orientation change that wouldn't happen if you changed the
> resolution?
> - Does it make sense to try to implement the generic "layout change" at the
> same time?
> - I assume that the long-term desired visual effect is that you turn the table,
> and then the screen atomically updates to a new state. This API would allow us
> to fade/flash to black, then fade/flash back at the shell's convenience  once
> windows are validated, but isn't sufficient for an actual atomic screen update.
> Do we want to future proof against that? Do we have any idea what that would
> involve?
> Roughly speaking, the atomic change seems to involve being able to disconnect
> the selected front buffer being displayed from the front buffer used from
> rendering - i.e., you'd tell xrandr "OK, allocate buffers and redirect drawing
> for this new setup, but keep scanning out the old way" and then at some point
> "change the scanout and discard the old front buffers".
> (Added Adam Jackson to the Cc: of the bug in case he wants to comment)
> Which implies that there is a need for the compositor to say back to g-s-d "OK,
> I'm done redrawing"  .... sort of relating to the first question above - how do
> you know when the "PRE" is done - we seem to also need to know when "POST" is
> done. So, perhaps this shouldn't be signals but rather methods on a compositor
> D-Bus object?

Adam also said on IRC:
<ajax> hadess: i don't really see why that's something the protocol needs to explicitly expose
<ajax> i guess you'd need to paint the scene into the new crtc pixmap first (undoing the coming rotation); send the randr request and enter your animated transition mode, and then once you think apps have stopped repainting for new geometry, crossfade.
<ajax> but i think you can get away with that with the 1.4 atomic modeset and per-crtc.
<ajax> not having per-crtc pixmaps will make modeswitch much more likely since you'll almost certainly need an fb realloc under the covers
Comment 3 Rui Matos 2011-06-07 22:35:28 UTC
Created attachment 189435 [details] [review]
Add a mechanism for smooth xrandr transitions

This can be triggered through a D-Bus method call. Callers should wait for the
method to return before actually doing the xrandr changes.
Comment 4 Rui Matos 2011-06-07 22:42:35 UTC
We need the patches in bug 648651 and blockers to actually return the D-Bus method only after fading to black.

The "curtain" goes away automatically after the xrandr change is done (or after a fail safe timeout) so we don't need a second D-Bus method to clear it.

Comment 5 Rui Matos 2011-06-07 22:43:37 UTC
btw, to test how it looks I'm using the following:

$ gdbus call -e -d org.gnome.Shell -o /org/gnome/Shell -m org.gnome.Shell.CloseCurtain && sleep 0.4 && xrandr --output LVDS-1 --off
Comment 6 Rui Matos 2011-06-07 22:44:47 UTC
[ hit commit too soon ]

and then to get back my second display:

$ gdbus call -e -d org.gnome.Shell -o /org/gnome/Shell -m org.gnome.Shell.CloseCurtain && sleep 0.4 && xrandr --output LVDS-1 --right-of DVI-D-1 --auto
Comment 7 Bastien Nocera 2011-06-07 23:27:42 UTC
We still need a pre/post, rather than a single call. And the "failsafe timeout" would be between the pre and post calls.
Comment 8 Rui Matos 2011-06-08 18:33:30 UTC
Created attachment 189494 [details] [review]
Ok, I added a D-Bus method to open the curtain.
Comment 9 Rui Matos 2011-06-21 01:25:41 UTC
Created attachment 190330 [details] [review]
Also prevent events from being propagated to other actors.
Comment 10 Matthias Clasen 2011-09-02 00:33:56 UTC
I don't think this is a goal for 3.2 at this point, so moving off the target.
Comment 11 Jasper St. Pierre (not reading bugmail) 2013-03-03 21:57:40 UTC
Is this still wanted?
Comment 12 Bastien Nocera 2013-03-04 10:44:42 UTC
(In reply to comment #11)
> Is this still wanted?

Until we can get native rotation support in the compositor, yes.
Comment 13 André Klapper 2015-01-17 02:58:03 UTC
Comment on attachment 190330 [details] [review]
Also prevent events from being propagated to other actors.

$:andre\> patch --no-backup-if-mismatch -p1 < patch 
patching file js/ui/main.js
Hunk #1 succeeded at 40 with fuzz 2 (offset 6 lines).
Hunk #2 FAILED at 127.
Hunk #3 succeeded at 530 with fuzz 2 (offset -18 lines).
Hunk #4 succeeded at 677 with fuzz 2 (offset -233 lines).
1 out of 4 hunks FAILED -- saving rejects to file js/ui/main.js.rej
patching file js/ui/shellDBus.js
Hunk #1 FAILED at 9.
Hunk #2 succeeded at 250 with fuzz 2 (offset 194 lines).
1 out of 2 hunks FAILED -- saving rejects to file js/ui/shellDBus.js.rej

Hence setting 'needs-rework' as patch does not apply cleanly against git master.
Comment 14 Alexandre Franke 2017-04-22 11:52:09 UTC
(In reply to Bastien Nocera from comment #12)
> (In reply to comment #11)
> > Is this still wanted?
> Until we can get native rotation support in the compositor, yes.

Do you have a link to a bug that tracks that?
Comment 15 GNOME Infrastructure Team 2021-07-05 14:40:09 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.