Xgl/Xglx: initialize_visual_and_buffer: Assertion `v->BitsPerPixel > 0' failed.

[David Reveman]

On Tue, 2006-01-10 at 08:50 -0700, Brian Paul wrote:
> Ben Skeggs wrote:
> > Am Freitag, den 06.01.2006, 11:12 -0700 schrieb Brian Paul:
> > 
> >>Christopher Bayliss wrote:
> >>
> >>>Christian Parpart wrote:
> >>>
> >>>
> >>>>Hi all,
> >>>>
> >>>>after having finally(!) compiled and installed the xserver from very recent 
> >>>>CVS state, I were curious on Xgl/Xglx but when invoking them I get the 
> >>>>following:
> >>>>
> >>>>trapni at battousai /opt/sandbox/fdo/bin $ ./Xgl :1
> >>>>Xgl: /home/trapni/src/Xorg/xserver/../Mesa//src/mesa/drivers/x11/xm_api.c:1223: 
> >>>>initialize_visual_and_buffer: Assertion `v->BitsPerPixel > 0' failed.
> >>>>Aborted
> >>>>
> >>>>trapni at battousai /opt/sandbox/fdo/bin $ ./Xglx :1 -ac -screen 800x600
> >>>>Xglx: /home/trapni/src/Xorg/xserver/../Mesa//src/mesa/drivers/x11/xm_api.c:1223: 
> >>>>initialize_visual_and_buffer: Assertion `v->BitsPerPixel > 0' failed.
> >>>>Aborted
> >>>>
> >>>>I ran this within my current X session.
> >>>>Any idea on why this is happening?
> >>>
> >>>
> >>>I don't know what's happening but I had the same problem. Xgl appears to
> >>>work just fine if you comment the line out and recompile. It appears to
> >>>be a check on the requested colour depth of the output screen.
> >>>Alternatively, could try defining a colour depth when calling Xgl.
> >>
> >>Could someone provide a stack trace?
> > 
> > 
> > I see the same problem here. AMD64, Xgl build from xserver cvs. 

Xserver CVS doesn't work on AMD64 because _XSERVER64 is not defined as
it should be when building glcore sources. When _XSERVER64 isn't defined
things like XID's will be 64bit instead of 32bit as the rest of the
server is using and things obviously break.

My tree should work fine as it contains a snapshot of Mesa modified to
make sure _XSERVER64 is defined correctly. Try my tarboll and see if it
doesn't work. Remember to not set the --with-mesa-source option when
running the configure script as that will override the use of the my
modified Mesa sources.

> 
> This might be a symptom of a bug else where in the server code.  I'm 
> adding a few new assertions to the Mesa code.  Can you grab the latest 
> from CVS and try again?
> 
> Here's the patch:
> 
> diff -r1.97 xm_api.c
> 255a256
>  >    assert(depth > 0);
> 1565a1567
>  >    assert(visinfo->nplanes > 0);
> 
> 
> In the stack trace, like 985 of xf86glx.c doesn't correspond to 
> __MESA_screenProbe().  At least not in the xc or xserver CVS trees 
> that I'm looking at:
> 
>  > #5  0x00002aaaac3d4880 in __MESA_screenProbe (screen=0) at 
> xf86glx.c:985
>  > #6  0x00002aaaac723708 in xglScreenProbe (screen=16526) at
>  > xglglxext.c:5032
>  > #7  0x00002aaaac267982 in __glXScreenInit (numscreens=1) at
>  > glxscreens.c:357
>  > #8  0x00000000004a273d in InitExtensions (argc=<value optimized out>,
>  > argv=<value optimized out>)
>  >     at miinitext.c:346
>  > #9  0x000000000043c37e in main (argc=3, argv=0x7fffffc60eb8, 
> envp=<value
>  > optimized out>)
>  >     at main.c:364
> 
> 
> I see the call to XMesaCreateVisual() at line 1447.  It would be 
> helpful to put this assertion there:
> 
> assert(pVis->nplanes > 0);
> 
> -Brian
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg



-David