GNOME Bugzilla – Bug 737226
Plymouth splash screen is briefly displayed after logging in
Last modified: 2015-06-25 12:11:51 UTC
After entering my password to log into my new Fedora 21 Alpha Workstation install, the plymouth bootsplash (Fedora logo) flashes briefly on the screen. It's gone very quickly, but long enough to be highly noticeable. I have no clue what component is at fault, guessing gdm. This is a regression from F20/3.10. gdm-1:3.13.91-2.fc21 gnome-shell-3.13.91-1.fc21 plymouth-0.8.9-7.2013.08.14.fc21
The component at fault is SNA.
*** Bug 734173 has been marked as a duplicate of this bug. ***
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 736856 ***
I am going to reopen this bug as I do not believe it to be the same one as the SNA bug, or it is but the issue is actually something other than SNA. There isn't any way my system is running SNA at all, it is definitely using UXA.
Nevermind, I guess I can't unmark a bug as a duplicate
Sorry above, wrong bug, ignore me
*** Bug 743881 has been marked as a duplicate of this bug. ***
So this bug appears for me too on fedora 21. My PC is the Acer Chromebook C720P (inter graphic card).
The issue is that the copy from the CompositeOverlayWindow onto the root window that is expected to be performed when gdm exits (and as the last composite client causing the X server to clean up the composite overlay) is skipped at the window is already unrealized at the point at which compRestoreWindow() is performed (via compUnrealizeWindow()).
With Present there is another fail path:
+ Trace 234622
(In reply to comment #10) > The issue is that the copy from the CompositeOverlayWindow onto the root window > that is expected to be performed when gdm exits (and as the last composite > client causing the X server to clean up the composite overlay) is skipped at > the window is already unrealized at the point at which compRestoreWindow() is > performed (via compUnrealizeWindow()). Nope, the bug only presents itself with trace 234622
I'm still sufficiently confused. The COW and root window pixmap are backed by the same pixmap, no? What's the copy here?
That link is broken by Present and the copy here is when Present has to restore the contents from the flip Pixmap back to the original Pixmap.
fwiw, this is fixed by: diff --git a/present/present.c b/present/present.c index 38f24ba..8c50664 100644 --- a/present/present.c +++ b/present/present.c @@ -409,20 +409,20 @@ static void present_unflip(ScreenPtr screen) { present_screen_priv_ptr screen_priv = present_screen_priv(screen); + PixmapPtr pixmap = (*screen->GetScreenPixmap)(screen); assert (!screen_priv->unflip_event_id); assert (!screen_priv->flip_pending); if (screen_priv->flip_window) - present_set_tree_pixmap(screen_priv->flip_window, - (*screen->GetScreenPixmap)(screen)); + present_set_tree_pixmap(screen_priv->flip_window, pixmap); - present_set_tree_pixmap(screen->root, (*screen->GetScreenPixmap)(screen)); + present_set_tree_pixmap(screen->root, pixmap); /* Update the screen pixmap with the current flip pixmap contents */ if (screen_priv->flip_pixmap && screen_priv->flip_window) { - present_copy_region(&screen_priv->flip_window->drawable, + present_copy_region(&pixmap->drawable, screen_priv->flip_pixmap, NULL, 0, 0); }
Has this fix been implemented yet? I still have this issue and was wondering if I can expect this to be fixed in an upcoming gnome release? I am not familiar which package present.c is apart of to look upstream
Yes. It will be in the next X server release. You can see the fix here: http://cgit.freedesktop.org/xorg/xserver/commit/?id=806470b9f623089dc81b985f250f0c3a4e8edbe8
Cool. Let's not leave the bug report open then.