eglplatform.h pulls in Xlib.h on X11 platforms. Likewise, the egl glx
driver and egl programs needs to link to libX11. Make sure we use the
locations the user told us about.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
The Xlib demos were fixed to use $(X11_LIBS) so that configure could
detect the proper directory to link the library from, but this broke
the non-autoconf builds. Give X11_LIBS a default value to fallback on.
(cherry picked from commit e40fce13e1)
The variable X_LIBS from AC_PATH_XTRA contains only the -L searchdir
parameter and not the -lX11 to link to Xlib. Use X11 prefixed build vars
for linking with Xlib to avoid the conflict.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
(cherry picked from commit e725ef171b)
This can break on systems that don't have a system X installation.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
(cherry picked from commit de4ee20578)
Conflicts:
src/gallium/winsys/xlib/Makefile
In the direct rendered case, we need to tell the server our initial swap
interval. If we don't, the local and server values will be out of sync,
since the server and client defaults may be different (as they were
before this patch).
This should be drmCommandWriteRead to avoid an EINVAL error on systems
that strictly check ioctl args. This command has been r/w for ever.
Discussion with airlied agreed that this was the correct course.
Signed-off-by: Brian Paul <brianp@vmware.com>
When points or lines are decomposed into triangles, we need to be sure
to disable polygon culling, stippling, "un-filled" modes, etc.
This patch sets the rasterization state to disable those things prior to
drawing points/lines with triangles, then restores the previous state
afterward.
The new piglit point-no-line-cull test checks this problem & solution.
Fixes crash when using _mesa_CopyTexImage2D.
Bug #27652.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
In the direct rendered case, we need to convert DRI2 swap complete
events to GLX events for the client to consume. This path had what
looks like a stray "& 0x75" from some earlier debugging that prevented
clients from seeing the right event code.
When matching attributes using the 'mask' matching criteria, the spec
says that
"Only GLXFBConfigs for which the set bits of attribute include all
the bits that are set in the requested value are
considered. (Additional bits might be set in the attribute)."
The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute. For example, an
application asking for
GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,
as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Commit 1454f20a99 caused the regression.
When the vertex shader emitted both a texcoord and color we were grabbing
the wrong vertex attributes. Fix the draw_quad() code to put texcoords
in slot[1] and color in slot[2]. That's a bit cleaner than changing
the vertex shader code.
Tested with progs/tests/zreaddraw.c
piglit has a test called fbo-drawbuffers, this fails for me on r300g,
and fixing the texenv program to use the DATA outputs fixes it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to check pipe_blend_state::independent_blend_enable to determine
which render target/index to use when checking blend enable and colormask
state.
This is part of the fix for piglit/fbo-drawbuffers
The IDs will be the same in the case where an X window is used directly
as a GLX drawable, but will fail if a new GLX drawable is created
explicitly, as with glxgears_fbconfig.
Fixes fdo bug #27190.