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 677116 - Bright blue clutter stage appearing on primary screen when attempting to unlock screensaver
Bright blue clutter stage appearing on primary screen when attempting to unlo...
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2012-05-30 17:45 UTC by Máirín Duffy
Modified: 2021-07-05 13:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
compositer: subtract unredirected window region in correct coordinate space (1.87 KB, patch)
2012-08-29 14:41 UTC, Ray Strode [halfline]
accepted-commit_now Details | Review
window-group: Don't create a region when we have an unredirected window (2.58 KB, patch)
2012-08-29 17:54 UTC, Jasper St. Pierre (not reading bugmail)
accepted-commit_now Details | Review
window-group: Subtract the unredirected window in stage space (1.84 KB, patch)
2012-08-29 17:54 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review
window-group: Don't create a region when we have an unredirected window (2.58 KB, patch)
2012-08-29 18:23 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
window-group: Skip the unredirected window (1023 bytes, patch)
2012-08-29 18:23 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
window-group: Subtract the unredirected window in stage space (1.52 KB, patch)
2012-08-29 18:23 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review

Description Máirín Duffy 2012-05-30 17:45:53 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
Comment 1 Ray Strode [halfline] 2012-05-30 20:38:04 UTC
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?)
Comment 2 Jasper St. Pierre (not reading bugmail) 2012-05-30 20:49:13 UTC
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.
Comment 3 Ray Strode [halfline] 2012-05-30 20:54:32 UTC
btw, video is intel (sandybridge)
Comment 4 drago01 2012-05-30 20:59:01 UTC
(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?
Comment 5 Ray Strode [halfline] 2012-05-30 21:03:19 UTC
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.
Comment 6 Máirín Duffy 2012-08-20 18:54:25 UTC
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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-08-20 18:58:36 UTC
With the new screen shield, we won't hit the unredirect code path. Maybe this will help.
Comment 8 Máirín Duffy 2012-08-20 19:02:41 UTC
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.
Comment 9 Jasper St. Pierre (not reading bugmail) 2012-08-20 19:05:02 UTC
I sometimes see the same bug. Any errors in ~/.xsession-errors ?
Comment 10 Máirín Duffy 2012-08-20 19:09:22 UTC
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.
Comment 11 Ray Strode [halfline] 2012-08-28 21:38:20 UTC
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.
Comment 12 Ray Strode [halfline] 2012-08-28 22:24:35 UTC
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.
Comment 13 Ray Strode [halfline] 2012-08-29 14:41:39 UTC
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.
Comment 14 Ray Strode [halfline] 2012-08-29 14:43:13 UTC
(not super confident with attachment 222791 [details] [review] so would appreciate review)
Comment 15 drago01 2012-08-29 14:45:25 UTC
Review of attachment 222791 [details] [review]:

Good catch.
Comment 16 Ray Strode [halfline] 2012-08-29 14:50:46 UTC
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.
Comment 17 drago01 2012-08-29 15:08:32 UTC
(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.
Comment 18 Jasper St. Pierre (not reading bugmail) 2012-08-29 17:04:13 UTC
A quick local patch I have removes unredirected_window_region altogether, by just using subtract_rectangle directly.
Comment 19 Ray Strode [halfline] 2012-08-29 17:35:42 UTC
and do you

unredirected_rect.x += x;
unredirected_rect.y += y; 

or so before subtract rectangle ?
Comment 20 Jasper St. Pierre (not reading bugmail) 2012-08-29 17:47:46 UTC
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.
Comment 21 Ray Strode [halfline] 2012-08-29 17:52:37 UTC
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.
Comment 22 Jasper St. Pierre (not reading bugmail) 2012-08-29 17:54:07 UTC
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.
Comment 23 Jasper St. Pierre (not reading bugmail) 2012-08-29 17:54:10 UTC
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.
Comment 24 Ray Strode [halfline] 2012-08-29 18:03:50 UTC
Review of attachment 222812 [details] [review]:

missing a space in your description. Otherwise, patch seems right to me.
Comment 25 Ray Strode [halfline] 2012-08-29 18:12:26 UTC
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?
Comment 26 Jasper St. Pierre (not reading bugmail) 2012-08-29 18:23:18 UTC
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.
Comment 27 Jasper St. Pierre (not reading bugmail) 2012-08-29 18:23:27 UTC
Created attachment 222819 [details] [review]
window-group: Skip the unredirected window

We shouldn't need to process it here.
Comment 28 Jasper St. Pierre (not reading bugmail) 2012-08-29 18:23:32 UTC
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.
Comment 29 Ray Strode [halfline] 2012-08-29 18:25:11 UTC
(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
Comment 30 Ray Strode [halfline] 2012-08-29 18:26:31 UTC
Review of attachment 222818 [details] [review]:

right
Comment 31 Ray Strode [halfline] 2012-08-29 18:27:45 UTC
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 ?)
Comment 32 Ray Strode [halfline] 2012-08-29 18:29:29 UTC
Review of attachment 222820 [details] [review]:

this commit message should be reworked to reflect what the patch does now, otherwise looks right.
Comment 33 Ray Strode [halfline] 2012-08-29 18:33:52 UTC
(just to follow up to comment 16, no one in the office has seen this problem today with the scratch package)
Comment 34 Jasper St. Pierre (not reading bugmail) 2012-08-29 18:40:35 UTC
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.
Comment 35 Ray Strode [halfline] 2012-08-30 14:04:49 UTC
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.
Comment 36 Ray Strode [halfline] 2012-08-30 14:08:10 UTC
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
Comment 37 Ray Strode [halfline] 2012-10-19 15:29:49 UTC
also see bug 673370
Comment 38 Máirín Duffy 2013-02-05 17:22:01 UTC
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)
Comment 39 Máirín Duffy 2013-02-12 15:00:05 UTC
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.
Comment 40 Jonas Ådahl 2018-02-05 09:42:19 UTC
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.
Comment 41 Máirín Duffy 2018-02-05 13:17:31 UTC
Jonas, Im reopening this because it cant be 739178 - x220 has an intel card and uve never used nvidia blob.
Comment 42 GNOME Infrastructure Team 2021-07-05 13:43:46 UTC
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.