Created attachment 25927 [details]
Xorg.0.log

I can reproduce it on my rv380.

Can you bisect it? I wasn't able to run bisect below bbb1c6f6298fcb1125a8170f22646f326b0ca74c because there was dri version change, and I can't downgrade.

#good 1265e7267e086476d9bae560345fd80f064adfc5
#bad 45435abcb967931c79aba1714ae797a1c5dc075e
#bad 9bbffcced4355ff11e11c5b01c4d0eea6b020119
#won't build e6372853c221a5d64494ce75a6a323c479c55a86
#good bc7d2c4f51c56787b261e6ab6f9a77d39c3493e1
#bad ae5c06b9ce1191afaa95dd784d7315f25ec729ff
#good 6d2e1f6a2cd25107ad9bd88b1decd05fc8000f78
#bad 8217f24f21a0ea9888a18ec7399d2d974a43d1cb
#good b46611633c5da6fa23ee17bce22939fe20ef194e
#bad 5340b6dff73a0a23531ce2a5f28fba8303adab6e
#bad 9c9ba66fbae8089e9423f6b09ad1091cccf9b006 (locks up)

git-bisect picks some commits which I don't understand (there is no configure.ac), so I did it so far manually with git reset --hard. But all the merging of branches confuses me so I don't know if do it the right way. It takes so much time I can not continue on it now.

I have learned to use "git bisect visualize" (and Edit View to only look at src/mesa/drivers/dri/{r300,radeon}) so I will understand better next time I try. 

*** Bug 22538 has been marked as a duplicate of this bug. ***

I committed a fix last week to mesa_7_5_branch that fixes and additional
front-buffer rendering issue.  It might fix this problem as well.

commit 2d86503471cb8691ce266342810237fc1b15a7b2
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Fri Jun 26 13:30:16 2009 -0700

    intel / DRI2: Additional flush of fake front-buffer to real front-buffer

    To maintain correctness, the server will copy the real front-buffer to
    a newly allocated fake front-buffer in DRI2GetBuffersWithFormat.
    However, if the DRI2GetBuffersWithFormat is triggered by glViewport,
    this will copy stale data into the new buffer.  Fix this by flushing
    the current fake front-buffer to the real front-buffer in
    intel_viewport.

    Fixes bug #22288.

Aw crap... ignore that last comment.  A similar fix might work in r300, though.

*** Bug 22720 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> git-bisect picks some commits which I don't understand (there is no
> configure.ac), [...]

Those are probably from topic branches such as a Gallium or Nouveau branch. You can try the commits on master before and after the branch in question was merged.

Thanks. Unfortunately I won't have the chance to do more bisecting the next month.

I just want to add that with DRI2 I don't get any menu appearing at all, and from what I have heard, it is the same for intel cards.

(In reply to comment #10)
> I just want to add that with DRI2 I don't get any menu appearing at all, and
> from what I have heard, it is the same for intel cards.

I can confirm the same problem also with Intel GM31.
I'm using mesa and libdrm from master (revisions from today 16 july 2009) and xf86-video-intel v2.7.99.902, but the blender menus are not rendered and if I force a rendering the rendering window becames black and sits there for the ethernity.

The same problem happen with xf86-video-intel 2.7.99,901 and all the 2.6.x releases. There aren't particular errors or warnings into the Xorg logs.

Same problem with a ATI Technologies Inc M22 [Mobility Radeon X300] in an IBM Thinkpad R52 under Fedora 11. Blender just has black/white boxes for menus
that appear over the 3D window. Also redraws top menu bits over window managers
top bar if you move the mouse over the menu bits.
Have also tried latest git repositories for drm/libdrm/mesa/radeon driver to no avail.

Have tried disabling DRI hardware 3D rendering. Blender then works fine.
Note that disabling DRI was not easy:

1. Setting "Option DRI off" does not work if kernel mode setting is enabled.
2. If kernel mode setting is disabled and 'Option "DRI" "off"' then
   XServer crashes due to an EXA acceleration bug.
3. Works if kernel mode setting is disabled and 'Option "DRI" "off"' and
   'Option      "AccelMethod" "XAA"'

Sounds like two extra bugs here ...

Created attachment 28137 [details]
Picture of menu buttons drawn in wrong place

Enclosed is a picture of some of the lower menu icon buttons being redrawn in the wrong place (about 26 pixels up and 5 to the left on my 1400x1050 display). This happens when you move the mouse cursor over the real buttons. Could be a memory offset problem ?

(In reply to comment #14)
> Created an attachment (id=28137) [details]
> Picture of menu buttons drawn in wrong place

For me blender 2.49 does not refresh display. Menus don't open.
The problem is with direct front buffer rendering, which is fixed in blender 2.5 with triple buffer rendering.

However 2.5 release is planned for winter, afaik and this is optimistic date.

So looks like most blender graphics artists, that decided to use open-source drivers(minority afaik) are stucked with old 7.4.4 version of mesa.

My configuration on my GM964 is
xserver-xorg-video-intel   2.8.0
xserver-xorg-core          1.6.2.901
libdrm2                    2.4.12
mesa                       7.5-3
linux                      2.6.30.2-vanilla (KMS enabled)

2.49 version running in software rendering mode, does work fine, but is too slow to be usable.

I have noticed that blender does work on an ATI RV280 [Radeon 9200 PRO] under F11.
With me it has the menu problem with an ATI M22 [Mobility Radeon X300]
It also works with software mesa.
So is this bug a mesa issue with particular DRI drivers or a blender issue ?

Although the menu's show with an ATI RV280 [Radeon 9200 PRO] under F11, there are still problems. When using the mouse to select a menu item it looks like the program thinks that the mouse cursor is 20 or so pixels higher than it is. Ie to operate a menu you have to move the mouse 20 pixels or so below the menu. Also the system will draw some menu items 20 or so pixels above where they should be as well.

Blender SVN r22125 adds a method to workaround the menu problem; if there
is a new release after 2.49a, it should have it (so there is hope for the
people mentioned in comment #15). This way people can easily detect when
the issue in drivers is solved, but still be able to use hw accel in the
mean time. If the env var BLENDER_FORCE_SWAPBUFFERS has anything, it will
use a special function that was initially added for buggy Intel chipsets/
drivers in Macs, and .

A bit offtopic, 2.50 has three methods (triple buffer, full and overlap),
and none of them shows issues like this report even if one should be
equivalent to what <2.49 does (or so I read). OTOH, with radeon at least,
triple buffer is painfully slow.

"Macs, and ."... and forget that "and" as well as the info about being added
for Macs, deeper inspection seems to point the hack has older roots and
the detail does not matter anyway, even if at first I thought Intel chipset
would have something special in this sense, it was probably just coincidence.
Sorry. What matters is that special buffer code makes the issue not so bad
for the time being.

I have done some "git bisecting" of the mesa source code under Fedora 11 as the base platform and with an ATI M22 [Mobility Radeon X300].
The code at mesa_7_4 is good and works with F11.
The code at mesa_7_5 is bad.

I have found that the bug seems to appear at:
5340b6dff73a0a23531ce2a5f28fba8303adab6e (Merge commit 'origin/gallium-master-merge')

This looks like a major gallium merge into the main trunk ??

The code at: 9fd26daec24f21dbe17afcb2e2ab272667ee9a69 (mesa: remove the unused _mesa_UpdateTexEnvProgram() function) appears to run fine on my system.

I have tried to bisect the bug through the ee4c921b65fb76998711f3c40330505cbc49a0e0 (Merge commit 'origin/gallium-0.2' into gallium-master-merge) branch, but it gets difficult here due to dri drivers not being built by default, different drm/dri version requirements and different build systems.
I will try a bit more here.
Any info on the "origin/gallium-master-merge" ?

commit fd65418f600874b05f902b622078b40bc1abb24a
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Aug 3 14:27:41 2009 -0700

    intel: Fix inverted test for disabling flushing of front buffer output.
    
    The comment disagreed with the code, and nicely drew my eyes to what was
    going wrong.
    
    Bug #21774 (blender)
    Bug #21788 (readpix)

Gah, screwed this bug up again by having it open from a link from last time we screwed it up.

But in penance I did go ahead and commit the corresponding fix to radeon for DRI2.

This bug appears to have been fixed in the git commits for the R300. It is Ok on 2009-08-09 in the git repository.

Yes! It now works both on RV515 and M26, DRI1 and DRI2. This was the last regression for me after the radeon-rewrite, thank you to everyone involved.

The only issue left with DRI2 is that the menu does not appear when I only click on it, I have to move the mouse down the menu before it gets drawn. But I guess this is a different issue.