__glXInitializeVisualConfigFromTags doesn't skip the payload of
unrecognized tags. Instead, it treats the value as if it were the
next tag, which can happen if the server's GLX extension is not
Mesa's. For example, this falls down when NVIDIA sends a
GLX_FLOAT_COMPONENTS_NV = 0 pair, causing
__glXInitializeVisualConfigFromTags to bail out early.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
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).
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.
We've supported indirect rendering pbuffers for a while, but not direct
rendering pbuffers. The way we do this is by creating a hidden pixmap
and wrap that in a GLX pbuffer. This only works when we have DRI2 on
the server, but if the server doesn't have DRI2, it won't expose configs
with pbuffer bits enabled.
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>
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>
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.
This can happen when an X window is destroyed behind our back. We use
DRI2CopyRegion behind the scenes in many places (like flushing the fake
front to the real front) so we have to ignore X errors triggered in that
case.
The glean test cases trigger this consistently as they don't destroy the
GLX drawable nicely, they just destroy the X window.
This can happen when an X window is destroyed behind our back. We use
DRI2CopyRegion behind the scenes in many places (like flushing the fake
front to the real front) so we have to ignore X errors triggered in that
case.
The glean test cases trigger this consistently as they don't destroy the
GLX drawable nicely, they just destroy the X window.
This change passes a remainder of 1 to the server with the
DRI2SwapBuffers request, causing it to honor the OML semantics for the
swap rather than falling through to glXSwapBuffers behavior. The
remainder actually ends up ignored since the divisor is 0, but we need
to differentiate the OML and standard behavior somehow.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
