hardware format of the texture, and SetTexImages is supposed to use the
format selected by ChooseTextureFormat. However, both routines were making
their choices based on the texture's BaseFormat. This is wrong.
ChooseTextureFormat uses BaseFormat and SetTexImages uses
TexFormat->MesaFormat.
Once SetTexImages was fixed to use the right format values,
ChooseTextureFormat was cleaned up. It now uses the few available texture
formats supported by the i810 in a smarter way. This should improve the
quality of LUMINANCE, LUMINANCE_ALPHA, and INTENSITY textures.
I tested this by cycling through all the texture formats in demos/texenv and
tests/yuvsquare.
erroring out when it shouldn't. The errno could be changed by usleep() between
the ioctl call and the loop check, if a signal was received. This could cause
an EAGAIN return from the DRM_RADEON_TEXTURE ioctl to not loop again.
Instead of checking errno, check thevalue of ret itself, since it is a saved
(and sign-flipped) copy of errno from the ioctl call.
but, for whatever reason, the extension wasn't enabled.
Add some comments to i810ChooseTextureFormat. There's some strangeness with
i810 texture formats.
Make 'USING_EGL=0' the default for now. It's causing too much confusion for
too many non-developers (which in turn wastes too much developer time). It
is trivially overridden from the make command line. See comments in
linux-dri.
Add additional checks for the *DRIRec info structure passed in from the
device driver. This ensures that things fallback to indirect rendering if
the DDX driver has had modifications (i.e. removal of the drmAddress field).
extension wasn't enabled. I have verified its correct function with Mesa's
stencil_wrap test. It is enabled on both Savage4 and Savage3D. Since
Savage3D uses a software fallback for *all* stencil operations, this is safe.
should be defined. It was flawed on some platforms (e.g., Darwin & mingw).
Instead, rely on the build system to define it on the compiler command line.
This also reverts ajax's hand-edit to indirect_size.c. I'll fix that on the
X.org side of things later today.