Bug 36699 - [RV770] Permanently unrendered regions after loading/dismissing context menus
Summary: [RV770] Permanently unrendered regions after loading/dismissing context menus
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2011-04-29 17:25 UTC by Bryce Harrington
Modified: 2011-07-19 12:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Screenshot showing 3 different unrendering regions (582.61 KB, image/png)
2011-04-29 17:27 UTC, Bryce Harrington
no flags Details
dmesg (124.45 KB, text/plain)
2011-04-29 17:28 UTC, Bryce Harrington
no flags Details
Xorg.0.log (669.39 KB, text/plain)
2011-04-29 17:29 UTC, Bryce Harrington
no flags Details

Description Bryce Harrington 2011-04-29 17:25:43 UTC
Rectangular regions of the screen become unpaintable (nothing redraws in that area) after displaying and dismissing a context menu.

The system has RV770 graphics on two heads using metacity (no compositing) and the r600g driver.

The rectangular regions are slightly larger dimensionally than the context menu that had triggered them.  When they pop up they show a snapshot of whatever had been displayed - snippets of web pages typically.  When I hover the mouse cursor over them, the cursor will change shape back to an arrow.  The region also blocks clicks if there is a hyperlink or button behind it.  Regular windows will not paint over these areas, however subsequent context menus will display over the top of them (and can be used normally).

This is an intermittent problem that occurs only once my system has been up for a period of a few days.  Once it starts, I'll generally see it multiple times in short successions.  I have particularly noticed it with the Chromium web browser, although that may just be because that's pretty much the only application I do a lot of right click context menu usage on.  I did notice an inverse effect when I did a context menu on a gnome-terminal window, it restored a portion of one of the regions (see screenshot).

About 50% of the time, I can switch desktops via ctrl-alt-arrow, and with sufficient switching it will sometimes disappear.  The other half of the time the region sticks around persistently until reboot.

If I switch to vt console, the screen is fine (black text console).  On switching back to X, the unrendered regions are back, but instead of displaying old graphics they are just grey.
Comment 1 Bryce Harrington 2011-04-29 17:27:37 UTC
Created attachment 46176 [details]
Screenshot showing 3 different unrendering regions
Comment 2 Bryce Harrington 2011-04-29 17:28:41 UTC
Created attachment 46177 [details]
Comment 3 Bryce Harrington 2011-04-29 17:29:00 UTC
Created attachment 46178 [details]
Comment 4 David Korth 2011-04-29 17:37:04 UTC
I've been having the same problem for a while on my ThinkPad T60p (FireGL V5250; RV530). I've been able to get rid of the garbage by setting a window as Always On Top and dragging it over the misrendered area. Usually, it happens in the top few lines of the Plasma panel (KDE 4.6.2), in which case it shows lines from the desktop wallpaper.

I'll take a screenshot the next time it happens.
Comment 5 Bryce Harrington 2011-04-29 17:50:27 UTC
In my case, setting a window to always on top seems to not make a difference - the unrendered regions remain unrendered (and the window just displays underneath.

Only context menus and the mouse cursor draw over the top of the unrendered regions, and (usually) don't make the regions go away.
Comment 6 Bryce Harrington 2011-04-29 17:56:11 UTC
Logging out and back in is sufficient for eliminating the unrendered regions; in fact they disappear as soon as the logout sequence begins (before many of the windows have actually closed).  (Makes me wonder if it could be something bugged in metacity?)
Comment 7 Michel Dänzer 2011-05-02 04:56:23 UTC
Sounds like bug 22566. At any rate though, this can't really be a driver bug, as the driver isn't actively involved in window management.
Comment 8 Bryce Harrington 2011-07-19 12:54:12 UTC
Resolved in ubuntu.  Metacity bug, like Michael suggested.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.