GNOME Bugzilla – Bug 644230
Everybody freeze! smooth xrandr transitions
Last modified: 2021-07-05 14:40:09 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?
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?
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_0, > > ORIENTATION_90, > > ORIENTATION_180, > > ORIENTATION_270 > > } Orientation; > > enum { > > ORIENTATION_NOTIFICATION_PRE, > > ORIENTATION_NOTIFICATION_POST > > } 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
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.
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. Comments?
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
[ 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
We still need a pre/post, rather than a single call. And the "failsafe timeout" would be between the pre and post calls.
Created attachment 189494 [details] [review] Ok, I added a D-Bus method to open the curtain.
Created attachment 190330 [details] [review] Also prevent events from being propagated to other actors.
I don't think this is a goal for 3.2 at this point, so moving off the target.
Is this still wanted?
(In reply to comment #11) > Is this still wanted? Until we can get native rotation support in the compositor, yes.
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.
(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?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.