As told on right sidebar of blender site :
"Users with Intel on-board graphics: some graphics operations (menus or border select) don't show due to driver bug."
and in latest comments in:
Though the frontbuffer fixes in :
are already applied on my setup:
xserver (debian unstable) - dbac41b624e4aa86a6a184b7ebb52bfdd367bbf0 upstream
x11proto-dri2 - 66c56ab10d917e3f47f93178d7eac6430970d3c4
drm (master) 790097c51330090b2b7b90429b9ab8ddf259fd8e
mesa (master) 94008088c1e6758a44a2f48c5a94db1f072d255a
xf86 video intel f53b3239dbc0ed723774e386e07ac9d8ce96bb89
blender 2.49 debian sid (non static mesa)
Weird thing is if I enable two displays and start blender with -W (non windowed mode) ... it tries to span the two displays and fails to render properly . What s interesting is that in this case I can actually see the menu entries (though the menu borders are not rendered and a lot of artifacts happens).
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.
Author: Ian Romanick <firstname.lastname@example.org>
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
Fixes bug #22288.
*** This bug has been marked as a duplicate of bug 21774 ***
I'll pay more attention next time.
(In reply to comment #1)
> 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 <email@example.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
> Fixes bug #22288.
It didn't fix it here, but I am not the original reporter and am on mesa 7.6 up to the "i915: Fix assertion failure on remapping a non-BO-backed VBO." commit (57a06d3a48c9af1067ec05e3ad96c58f4b9b99be on 06-30 which includes your above mentioned commit). Dropdown menus still dont render unless I use a static mesa blender version or LIBGL_ALWAYS_SOFTWARE=1. This is on a 945GME with -intel xserver and mesa all built from master today and the problem has existed since at least april. This is a backtrace from crashes that used to happen when clicking on a dropdown with texture tiling turned on if it helps any. That issue is fixed now but I dont know if it would help narrow down where the problem might be happening.
*** Bug 22998 has been marked as a duplicate of this bug. ***
*** Bug 22994 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=21774 which is supposed to be a duplicate of this bug, seems to address a different bug than https://bugs.freedesktop.org/show_bug.cgi?id=22998 which is also supposed to be a bug of this one.
The first one with ID 21774 says that menus are black or white, but #22998 says that they are not drawn at all (no refresh/change of the screen). And some user having the black/white issue in #21774 says it's also present in xf86-video-intel/184.108.40.2061, but #22998 explicitly states that the problem was introduces by xf86-video-intel/220.127.116.112.
So I'd rather assume that #21774 and #22998 are different issues so they cannot be both duplicates of this bug? Although the user comments seem often to mix up both issues.
Author: Eric Anholt <firstname.lastname@example.org>
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
Bug #21774 (blender)
Bug #21788 (readpix)
Mass version move, cvs -> git