[Bug 33867] [bisected] Graphics corruption related to pageflip ioctl support in 2.6.38-rc*

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=33867

--- Comment #3 from Dave Witbrodt <dawitbro at sbcglobal.net> 2011-02-05 10:57:03 PST ---
Part 1:  Improving on what I've reported so far


OK, I've spent a couple of days trying to understand my situation with this
bug.  My previous comments here were very preliminary, so I will now try to
improve on the quality of information I have provided so far.  Everything
(kernel DRM, Mesa, X server, Radeon driver) is working so well that it may be a
complete fluke that I noticed this glitch at all.

I begin with some details about the glitch I am seeing.  I am not proficient
enough with screen capture software to grab stills or videos of the glitch on
my system, but I have found some material on the net useful for illustrating
what I am seeing.

Of all the software I use for testing, only one program (so far) reveals this
bug:  a locally-built version of 'prboom-plus'

    http://prboom-plus.sourceforge.net

(I use it with the Ultimate DOOM WAD file which I purchased almost 20 years
ago!)

DOOM used an animated fading/melting transition when starting a new game and
when starting over after being killed.  I'm sure you all are familiar with it;
it looked like this:

    http://doom.wikia.com/wiki/File:Screen_melt.gif

The 'prboom' and 'prboom-plus' programs attempt to clone such effects.  Before
my latest kernel upgrades, these fades/melts worked correctly.

When I decided to try out the latest Radeon DRM bits (from
drm-airlied/drm-fixes) I found everything to be working great -- games, web
browsing, no desktop glitches, etc. -- until I tested 'prboom-plus'.  That game
worked fine, except a specific fade/melt transition (not the one when the game
first starts, but the one after your player is killed and you restart on the
same level)
was all black on the melting part of the screen.  This 7-second YouTube clip
looks a lot like my bug -- I'm _only_ talking about the first half second of
the clip:

    http://www.youtube.com/watch?v=gDaSE8U7oEo

Since only the kernel had changed when I first noticed this all-black animation
regression, I blamed it on the kernel.  I am no longer certain that the kernel
is to blame; new information (see later comments) makes me wonder whether it is
a bug in xf86-video-ati.

At this point I began bisecting the kernel I was using:  I had created a git
branch from v2.6.37 and had cherry-picked the new commits that seemed relevant
to my hardware, as described above in my original report here, and in Comment
2.

I ended Comment 2 as I was about to begin bisecting directly from the drm-fixes
tree, in case I had botched my cherry-picks; my next comment here will pick up
after that.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.