Recent mesa commit

[Ben Gamari]

Hey,

How are you debugging this anyways? If I'm not mistaken, this code runs
in the server (although I'm notoriously bad at figuring out where code
runs in the X stack). Do you have a second machine to remote debug from?
Attached is a naive (also non-functional) attempt to teach
driConfigEqual about GLX_DONT_CARE. Sorry about the whitespace changes. 

Anyways, even outside of the context of this problem, shouldn't
driConfigEqual check for DONT_CARE?

- Ben


diff --git a/src/glx/x11/dri_glx.c b/src/glx/x11/dri_glx.c
index 004af0b..f22888e 100644
--- a/src/glx/x11/dri_glx.c
+++ b/src/glx/x11/dri_glx.c
@@ -524,10 +524,13 @@ scalarEqual(__GLcontextModes *mode, unsigned int
attrib, unsigned int value)
     int i;
 
     for (i = 0; i < ARRAY_SIZE(attribMap); i++)
-       if (attribMap[i].attrib == attrib) {
-           driValue = *(unsigned int *) ((char *) mode +
attribMap[i].offset);
-           return driValue == value;
-       }
+                       if (attribMap[i].attrib == attrib) {
+                 driValue = *(unsigned int *) ((char *) mode +
attribMap[i].offset);
+                 if (driValue == GLX_DONT_CARE)
+                       return GL_TRUE;
+                       
+                 return driValue == value;
+                       }
 
     return GL_TRUE; /* Is a non-existing attribute equal to value? */
 }


On Fri, 2008-04-04 at 22:49 +0200, Pierre Willenbrock wrote:
> Pierre Willenbrock schrieb:
> > Pierre Willenbrock schrieb:
> >> Ben Gamari schrieb:
> >>> Kristian,
> >>>
> >>> Is it possible that your recent commit
> >>> (dc836edf49a08a7fd77fc1f127818b0550558581: Initialize
> >>> GLX_EXT_texture_from_pixmap attributes correctly.) broke GLX? Since
> >>> today, all GL applications fail to find any visuals. For instance, take
> >>> glxinfo,
> >>>
> >>> ben at mercury /opt/exp/mesa $ glxinfo
> >>> name of display: :0.0
> >>> Error: couldn't find RGB GLX visual
> >>>
> >>>    visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
> >>>  id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
> >>> ----------------------------------------------------------------------
> >>> 0x21 24 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> >>> 0x22 24 dc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> >>> 0x56 32 tc  1  0  0 c  .  .  0  0  0  0  0  0  0  0  0  0  0  0 0 None
> >>>
> >>> I have bisected the problem down to the commit listed above. The problem
> >>> in particular seems to be triggered by the first chunk of the diff
> >>> (enabling some entries in the attribute map). I'm not too familiar with
> >>> the plumbing for glx visuals, but I'll take a quick look at it tonight.
> >>> Otherwise, is it possible that your change could have lead to some
> >>> unexpected (or perhaps expected ;-) ) breakage? Thanks,
> >>>
> >>> - Ben
> >>
> >> i have been suffering from this, too, but recompiling everything from 
> >> scratch did not fix this. Searching further, i found that the 
> >> attribute __DRI_ATTRIB_YINVERTED has been enabled in the attribute 
> >> offset list used to compare with attributes in the DRIconfig struct, 
> >> although the needed infrastructure for that attribute is not in place, 
> >> leading to failure in all compares.
> > 
> > That was a bit too early. Removing that attribute makes only 
> > progs/xdemos/glxinfo work. The rest still fails.. Back to the debugger.
> > 
> 
> The xserver sends no GLX_BIND_TO_TEXTURE_RGB_EXT-tag(and others) for 
> visuals, therefore the comparison in driConfigEqual always fails for 
> visuals. I think there are two ways to deal with this: either teach 
> __glXDisp_GetVisualConfigs to send the missing tags, or teach 
> driConfigEqual to ignore variables set to GLX_DONT_CARE.
> 
> Indirect rendering mode seems to be unaffected, possibly because the 
> visual structs are passed in server as-is(just speculating). Some 
> distros seem to always set LIBGL_ALWAYS_INDIRECT.
> 
> Regards,
>    Pierre
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg