Tested with r300g.
Signed-off-by: Marek Olšák
---
src/mesa/state_tracker/st_format.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 444b8da..955d821 100644
--- a/src/mesa/state_tra
https://bugs.freedesktop.org/show_bug.cgi?id=31084
Summary: 7.9 configure doesn't check for python
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: minor
Priority: me
On Sun, Oct 24, 2010 at 9:31 PM, Jon TURNEY wrote:
>
> Since commit 8a6bdf3979c2dda0efc6771308bf9e5c32bbdab4 "egl: Minor changes to
> the _EGLConfig interface.", I have a failure building egl_glx.so (see [1])
>
> Here is the failure with a bit more verbosity:
>
> make[4]: Entering directory
> `/op
On Sun, Oct 24, 2010 at 7:59 PM, xiaoxiaomuyu
wrote:
> Thanks again.
>
> EGL: glx > what's it for?
It is an EGL driver that does EGL-over-GLX. A call to eglMakeCurrent
is translated to glXMakeCurrent, for example. It is almost always
enabled (as libGL is almost always built).
>
Since commit 8a6bdf3979c2dda0efc6771308bf9e5c32bbdab4 "egl: Minor changes to
the _EGLConfig interface.", I have a failure building egl_glx.so (see [1])
Here is the failure with a bit more verbosity:
make[4]: Entering directory `/opt/wip/jhbuild/git/mesa/mesa/src/egl/drivers/glx'
/bin/sh ../..
This fix got lost in the state rework merge.
Signed-off-by: Tilman Sauerbeck
---
src/gallium/drivers/r600/r600_pipe.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index bea7ef5..3564539 1006
Thanks again.
EGL: glx > what's it for?
EGL platforms: x11 drm > for nothing? Have to explicitly indicate
--with-egl-platforms=drm??
By the way, what's the difference among egl surfaces of pbuffer, screen,
window, bitmap?
Cheers.
__
Commit 5a3ac74 added $(TALLOC_LIBS) to the mklib call in
src/mesa/drivers/osmesa/Makefile and this breaks static builds on
Linux since ar barfs on "-ltalloc". I have been looking at different
ways of dealing with this without finding any elegant solution. We can
change configure.ac to set TALLOC_LI
radeon_bo_destroy() will want to read the list field. Without this patch,
we'd end up evaluating the list pointers before they have been properly
set up when we destroyed the newly created bo if it cannot be mapped.
Signed-off-by: Tilman Sauerbeck
---
src/gallium/winsys/r600/drm/radeon_bo.c |
