GNOME Bugzilla – Bug 677116
Bright blue clutter stage appearing on primary screen when attempting to unlock screensaver
Last modified: 2021-07-05 13:43:46 UTC
I have a fresh (completely fresh, full format and reinstall and no /home backup) of Fedora 17 that is 3 days old at this point. I have a Lenovo x220 laptop on a docking station connected to an external monitor that is located to the right of the laptop+docking station. My laptop is configured to *not* suspend while docked so suspend never comes into play here. I locked my screen via the user menu in the upper right of gnome shell "Lock screen" via my primary screen (the x220 LCD) and went to lunch. When I came back, both my x220 LCD And my external monitor were in power save mode. I tapped the keyboard to wake up my screen. The x220's screen (Again this is the primary screen and where I left my mouse when I locked the screen) was a super bright blue. Jasper and Ray think it is the same color as the clutter stage background. My right external monitor had the 'fake' gnome shell panel drawn by gnome-screensaver on the top, and a black background (no wallpaper.) WORKAROUND We figured out a workaround. If you move the mouse to the external display where the fake shell panel is displayed and hit Esc, gnome screensaver will move the password unlock dialog which will display properly to the external monitor. then you can unlock the screen. Jasper and Ray had a lot of theories involving window unredirection or redirection or background actors not getting painted because of clutter window groups or only redirecting one window instead of both.... I couldn't really follow the discussion but hopefully the above is enough to help you figure out what might be going on. We set the display power off in the screen settings down to 1 min and tried to reproduce the issue a couple of times and could not reproduce it, so it may be some kind of weird timing bug maybe? I do the same thing every day at lunch time, and this is my second day at work with this version of GNOME, so if it happens again I can comment on this ticket if it's helpful. mutter-3.4.1-3.fc17.x86_64
jasper and I did some debugging on this, and came up sort of empty. The problem seems to be that global.window_group isn't drawing. Though, it's visible, has full opacity, get_skip_paint() == False, etc, so we don't know why it isn't drawing. Still, we set_skip_paint(false) on all of the chrome, forcefully broke the screensaver grab, and then were able to go into the overview fine. Upon leaving the overview, it would return to a blue stage. Maybe some sort of driver bug? (Maybe from texture memory pressure?)
The window group isn't a tracked actor either, so our initial start with the blatant if (this._screenSaverActive) visible = false; code in layout.js was a false lead.
btw, video is intel (sandybridge)
(In reply to comment #1) > jasper and I did some debugging on this, and came up sort of empty. > > The problem seems to be that global.window_group isn't drawing. Though, it's > visible, has full opacity, get_skip_paint() == False, etc, so we don't know why > it isn't drawing. Did you verify the paint volume as well? Does disabling clipped redraws and/or culling help? > Still, we set_skip_paint(false) on all of the chrome, forcefully broke the > screensaver grab, and then were able to go into the overview fine. Upon leaving > the overview, it would return to a blue stage. > > Maybe some sort of driver bug? (Maybe from texture memory pressure?) Maybe we had something similar in the past does disabling FBC help?
we didn't check paint volume, but the background actor isn't painted either, and it's paint volume is fixed. Would be interesting to step through meta_window_group_paint and see how it flows.
Hi, just a note that I still hit this bug at -least- weekly and I hit it just now. Same version of mutter. I couldn't get to the phantom password dialog, and I really needed to get back to my work. So I pulled the monitor cable out from my docking station. This resulted in my laptop LCD remaining the bright blue color. I then switched TTYs back and forth and a proper unlock dialog appeared. Of course, I lost all of my window placements from my second monitor which had to be reset once I got the screen unlocked and plugged the monitor back in.
With the new screen shield, we won't hit the unredirect code path. Maybe this will help.
I have another laptop that has the 3.55 release via jhbuild on it. If you leave the system overnight and try to unlock it via the shield the next morning, it doesn't give you a box to type your password in. (I didn't bother filing a bug since it's a development release.) That's a two-screen situation, but without a docking station.
I sometimes see the same bug. Any errors in ~/.xsession-errors ?
I don't think there were (although it's not there anymore! it's hidden under .cache/gdm-something) but at one point I think Ray was able to partially recover the system when it got into this state by screwing with the TTYs, but the system was unstable afterwards and had to be rebooted.
So i read through meta_window_group_paint today and see this: if (info->unredirected_window != NULL)• {• meta_window_actor_get_shape_bounds (META_WINDOW_ACTOR (info->unredirected_window), &unredirected_rect);• unredirected_window_region = cairo_region_create_rectangle (&unredirected_rect);• }• … clutter_stage_get_redraw_clip_bounds (CLUTTER_STAGE (stage),• &visible_rect);• • visible_region = cairo_region_create_rectangle (&visible_rect);• • if (unredirected_window_region)• cairo_region_subtract (visible_region, unredirected_window_region);• but meta_window_actor_get_shape_bounds returns window->priv->bounding_region which comes from meta_window_actor_update_bounding_region_and_borders. Note x and y: meta_frame_calc_borders (priv->window->frame, &borders);• • bounding_rectangle.x = borders.invisible.left;• bounding_rectangle.y = borders.invisible.top;• left and top are going to be 0 in this case since there is no window frame. So, as far as I can tell, we're subtracting a region that's in window coordinates from a region that's in stage coordinates. That might be related.
I gave Mo a scratch build with an untested change to potentially address comment 11. Will report back whether it works or is off base.
Created attachment 222791 [details] [review] compositer: subtract unredirected window region in correct coordinate space meta_window_group_paint tries to carefully figure out which parts of the scene it can avoid painting. One area it avoids painting is the region of the screen occupied by an unredirected window (if there's one present). In subtracting that region, it gets the coordinate spaces confused, and ends up subtracting the area at the wrong offset. This commit translates the region to the correct offset before subtracting.
(not super confident with attachment 222791 [details] [review] so would appreciate review)
Review of attachment 222791 [details] [review]: Good catch.
I'm going to wait a day with the scratch packages installed on some of the people's machines around the office hitting this before committing to make sure it actually makes the problem go away.
(In reply to comment #16) > I'm going to wait a day with the scratch packages installed on some of the > people's machines around the office hitting this before committing to make sure > it actually makes the problem go away. Well visible_region is in stage coordinates and unredirected_window_region is in window coordinates. So the change looks correct to me. From a quick testing it does not seem to cause any breakage but I don't mind some extra testing.
A quick local patch I have removes unredirected_window_region altogether, by just using subtract_rectangle directly.
and do you unredirected_rect.x += x; unredirected_rect.y += y; or so before subtract rectangle ?
I didn't actually fix this bug locally, but yeah, it's a relatively easy thing to do. I was going to attach the patch to this bug, but just forgot.
meh, 6 of one, half a baker's dozen of another. If we add that optimization, should probably add it as a separate commit to prevent the extra code churn in the diff.
Created attachment 222812 [details] [review] window-group: Don't create a region when we have an unredirected window We don't do anything with it otherthan modify an existing region.
Created attachment 222813 [details] [review] window-group: Subtract the unredirected window in stage space meta_window_group_paint tries to carefully figure out which parts of the scene it can avoid painting. One area it avoids painting is the region of the screen occupied by an unredirected window (if there's one present). In subtracting that region, it gets the coordinate spaces confused, and ends up subtracting the area at the wrong offset. This commit translates the region to the correct offset before subtracting.
Review of attachment 222812 [details] [review]: missing a space in your description. Otherwise, patch seems right to me.
Review of attachment 222813 [details] [review]: ::: src/compositor/meta-window-group.c @@ +237,3 @@ if (info->unredirected_window != NULL) { + int x, y; the declaration could be moved in a block. @@ +247,3 @@ + unredirected_rect.y += y; + cairo_region_subtract_rectangle (visible_region, &unredirected_rect); + } seems right, though a few questions that I never answered (and are part of the reason i've been unsure about this fix and the earlier variant) 1) actor_is_untransformed will always be TRUE for unredirected windows right? if so, should we throw a warning if it fails? If not, are we doing the right thing when it fails? 2) We iterate over children of the window group below. Is the unredirected actor one of those children? If so, should we be skipping it below? are we already?
Created attachment 222818 [details] [review] window-group: Don't create a region when we have an unredirected window We don't do anything with it other than modify an existing region.
Created attachment 222819 [details] [review] window-group: Skip the unredirected window We shouldn't need to process it here.
Created attachment 222820 [details] [review] window-group: Subtract the unredirected window in stage space meta_window_group_paint tries to carefully figure out which parts of the scene it can avoid painting. One area it avoids painting is the region of the screen occupied by an unredirected window (if there's one present). In subtracting that region, it gets the coordinate spaces confused, and ends up subtracting the area at the wrong offset. This commit translates the region to the correct offset before subtracting.
(irc discussion) <magcius> halfline, "the declaration could be moved in a block." ? <magcius> halfline, technically, we shouldn't be using the actor's position. I'm not even sure if we keep the actor in sync when a window is unredirected <halfline> "the declaration could be moved in a block." => i just mean you can move it down under the next if statement <magcius> I can't. * halfline looks again <magcius> Because the if statement uses x and y in the call :) <halfline> oh heh <halfline> of course <halfline> nevermind <halfline> magcius: so we should probalby just make meta_window_get_outer_rect public <magcius> It is public. <halfline> then we should probably just use that <halfline> and make the shape function private again <halfline> drago01: sound right? <magcius> I don't know why we need to make that private again. <magcius> I've been trying to make more and more things public. <halfline> *shrug* <halfline> nothing uses it <halfline> but whatever <magcius> Extensions might. <halfline> i don't think it's available to extensions <halfline> it's declared in meta-window-actor-private.h <magcius> Ah. <magcius> So it's already private. <drago01> halfline: yes, we do use outer_rect in meta_shape_cow_for_window as well <magcius> And all throughout the shell, for that matter. <halfline> well when i said private i meant private to meta-window-actor.c <halfline> ie static <halfline> drago01: k
Review of attachment 222818 [details] [review]: right
Review of attachment 222819 [details] [review]: ::: src/compositor/meta-window-group.c @@ +248,3 @@ + if (l->data == info->unredirected_window) + continue; I guess that's right. Did you confirm it's not getting removed when it gets unredirected? (or hidden so already handled in the IS_VISIBLE check above ?)
Review of attachment 222820 [details] [review]: this commit message should be reworked to reflect what the patch does now, otherwise looks right.
(just to follow up to comment 16, no one in the office has seen this problem today with the scratch package)
Attachment 222818 [details] pushed as dfe8979 - window-group: Don't create a region when we have an unredirected window Attachment 222819 [details] pushed as fbcddbc - window-group: Skip the unredirected window Attachment 222820 [details] pushed as bc96a14 - window-group: Subtract the unredirected window in stage space Pushed with fixed commit message.
Ryan (one of the people seeing this in the office) hit issues this morning. He now occasionally sees a gray box where the unlock screen should be. The widgets are there based on mouse cursor changes, but they don't get drawn.
If we hit escape to dismiss the unlock dialog, the gray box remains (but the mouse cursor which is situated over the invisible entry changes from an I to a pointer). So I think what's happening is: 1) The window is unredirected 2) We aren't cutting a hole in the overlay window right to let it show through But I guess it could also be: 1) The window is redirected 2) We aren't processing damage events from the window
also see bug 673370
Hi, I never uninstalled the scratch package but I'm now running mutter-3.4.1-4.fc17.x86_64 (I don't know if it overwrote the scratch package as part of an update or if it's the same thing) but I got the blue screen again on trying unlock my screen. Also, there was no phantom password dialog window this time, it wouldn't let me type my password to unlock at all. In case this hits somebody else, to get around it I did the following on Fedora 17: - go to a tty (ctrl-alt-F2 works) - login - type 'export DISPLAY=:0' - type 'gnome-shell --replace' - go to tty1 (ctrl-alt-F1)
Happened again today. Plugged suspended laptop into dock, opened up lid, unsuspended... got a bright blue screen on the laptop screen and a black screen with the gnome shell bar up top on the external monitor. No place, not even the phantom hidden one, to type a password. Only way around it was to kill the shell.
The bug in the last comment sounds like something similar to https://bugzilla.gnome.org/show_bug.cgi?id=739178 . I'm going to be naive and conclude that so is the case. Please reopen I'm wrong.
Jonas, Im reopening this because it cant be 739178 - x220 has an intel card and uve never used nvidia blob.
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/mutter/-/issues/ Thank you for your understanding and your help.