Bug 16687

Summary: Desktop corruption when enabling Desktop Effects
Product: Mesa Reporter: Chris Rankin <rankincj>
Component: Drivers/DRI/R100Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium Keywords: NEEDINFO
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
Attachments: Desktop corruption when enabling Desktop Effects.
Xorg configuration file
Xorg log file
Desktop corruption when enabling Desktop Effects.
Xorg log file without AGPMode
Xorg log file without AGPMode and using XAA

Description Chris Rankin 2008-07-12 13:37:31 UTC
Created attachment 17650 [details]
Desktop corruption when enabling Desktop Effects.

I enabled Desktop Effects on Fedora 9, ran glxgears and observed the following effect when dragging the glxgears window around the screen (see attachment).

The icons on the gnome-panel at the bottom of the screen were also corrupt.

I have a Radeon 7000 AGP card, with a 500 MGHz PIII CPU.
Comment 1 Adam K Kirchhoff 2008-07-12 14:14:16 UTC
This is a known issue with DRI and compositing at the same time.  DRI2 resolves this problem, but the radeon driver still has to be updated to it.  See http://bugs.freedesktop.org/show_bug.cgi?id=8732 for more information.
Comment 2 Chris Rankin 2008-07-12 14:28:06 UTC
(In reply to comment #1)
> This is a known issue with DRI and compositing at the same time.

That might explain the glxgears problem, but there is still the corrupt gnome-panel. E.g. the stack of horizontal lines near the System Monitor displays that should be a Volume Control icon.

Mind you, the gnome-panel corruption "went away" once I'd hacked together a SetTexOffset implementation for the R100 driver.
Comment 3 Michel Dänzer 2008-07-13 23:38:34 UTC
As always, please attach the full xorg.conf and Xorg.0.log files.

In particular, if you're using Option "AccelDFS", does the panel corruption persist without it?
Comment 4 Chris Rankin 2008-07-16 12:04:28 UTC
Created attachment 17711 [details]
Xorg configuration file
Comment 5 Chris Rankin 2008-07-16 12:05:06 UTC
Created attachment 17712 [details]
Xorg log file
Comment 6 Chris Rankin 2008-07-16 12:07:58 UTC
Created attachment 17713 [details]
Desktop corruption when enabling Desktop Effects.

This corruption "goes away" now that the R100 driver accelerates GL_EXT_texture_from_pixmap, but I suspect that it's simply avoiding the problem rather than fixing it.
Comment 7 Michel Dänzer 2008-07-16 14:45:24 UTC
Does it also happen without Option "AGPMode"?
Comment 8 Chris Rankin 2008-07-19 11:07:42 UTC
Created attachment 17764 [details]
Xorg log file without AGPMode

Yes, the corruption still happens.
Comment 9 Chris Rankin 2008-07-19 11:12:44 UTC
Created attachment 17765 [details]
Xorg log file without AGPMode and using XAA

Yes, the corruption still happens when I switch to XAA instead of EXA too!

However, I should point out that the corruption is no longer observable if either I don't start X or I leave the computer turned off. This may or may not be significant.

BTW, why is Firefox complaining about invalid security certificates from bugs.freedesktop.org? I've had to create a scary "exception" to login here.
Comment 10 Daniel Stone 2008-07-19 12:20:21 UTC
On Sat, Jul 19, 2008 at 11:12:44AM -0700, bugzilla-daemon@freedesktop.org wrote:
> BTW, why is Firefox complaining about invalid security certificates from
> bugs.freedesktop.org? I've had to create a scary "exception" to login here.

Sadly, Mozilla's opinion is that security comes from paying shitloads of
money to VeriSign.  Hopefully they'll see the sense in publishing the
CACert CA, and we'll have a CACert certificate, which will validate.
Comment 11 ajax at nwnk dot net 2009-08-24 12:30:35 UTC
Mass version move, cvs -> git
Comment 12 almos 2011-05-15 10:54:25 UTC
Is this problem still around? According to comments #6 and #9 it is fixed in the currently preferred codepath (KMS/DRI2/EXA).

> Sadly, Mozilla's opinion is that security comes from paying shitloads of
> money to VeriSign.  Hopefully they'll see the sense in publishing the
> CACert CA, and we'll have a CACert certificate, which will validate.
This is a known design flaw of SSL. See
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
for more information.
Comment 13 almos 2014-05-24 20:48:04 UTC
I got no response in 3 years, I assume this is either fixed or nobody cares about r100 anymore.