mesa3d-dev

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Corbin S. <mos...@gm...>]

On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard <tst...@gm...> wrote:
> On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
>>
>> Nifty. Well, there's a few places to look for information.
>>
>> If you're not sure how the actual video card works,
>> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
>> great starting point. Of particular interest is the 3D engine; r300g
>> only talks to the 3D part of the video card.
>>
>> The reference Gallium driver is probably identity, although softpipe
>> is a good reference as well. We also have documentation for the
>> Gallium API and associated bits; if you don't want to build it
>> yourself from the Mesa tree, there should be an up-to-date copy at
>> http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a
>> problem with the documentation, lemme know!)
>>
>
> Thanks for the information.
>
> After spending some time learning about the Gallium driver architecture, I
> think it might be better to set a goal to implement or improve a specific
> feature of the Gallium R300 driver rather than trying to get a specific
> game or application to work.  Is there a feature that is currently missing
> from the R300 driver that might make a good project for the summer?

Good question. There's a handful of things. Passing piglit might be a
good goal. Bumping the GL version further up, or solidifying the GLSL
support, might be good too.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<Mos...@gm...>

[Mesa3d-dev] [Bug 27254] glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27254





--- Comment #3 from Ian Romanick <id...@fr...>  2010-03-23 00:09:37 PST ---
(In reply to comment #2)
> I guess I am just curious why this one is left out as all the other GL calls we
> use in our software are included in Mesa's libGL, especially when
> BlitFramebuffer is just an alias to it.

I think that's a bug.  Our plan of record is not provide static symbols for
*any* new functions.  If there is a static symbol available for
glBlitFramebuffer (or any other function added in the last 4 years or so), it
should be removed.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Tom S. <tst...@gm...>]

On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
> 
> Nifty. Well, there's a few places to look for information.
> 
> If you're not sure how the actual video card works,
> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
> great starting point. Of particular interest is the 3D engine; r300g
> only talks to the 3D part of the video card.
> 
> The reference Gallium driver is probably identity, although softpipe
> is a good reference as well. We also have documentation for the
> Gallium API and associated bits; if you don't want to build it
> yourself from the Mesa tree, there should be an up-to-date copy at
> http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a
> problem with the documentation, lemme know!)
> 

Thanks for the information.

After spending some time learning about the Gallium driver architecture, I
think it might be better to set a goal to implement or improve a specific
feature of the Gallium R300 driver rather than trying to get a specific
game or application to work.  Is there a feature that is currently missing
from the R300 driver that might make a good project for the summer?

-Tom Stellard

[Mesa3d-dev] [Bug 22536] glxgears_pixmap shows black screen and seeing error message from X

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=22536


Kristian Høgsberg <kr...@bi...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kr...@bi...
             Status|NEW                         |ASSIGNED




--- Comment #1 from Kristian Høgsberg <kr...@bi...>  2010-03-22 19:16:40 PST ---
The patch has been applied, can we close this bug?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27254] glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27254





--- Comment #2 from Alan <al...@au...>  2010-03-22 18:49:55 PST ---
(In reply to comment #1)
> > EXT_framebuffer_object.xml specifies that BlitFramebufferEXT
> > to be hidden while BlitFramebuffer is exposed as described in
> > ARB_framebuffer_object.xml, is that intentional?
> 
> This is reasonable, at least.  The Linux OpenGL ABI only requires
> that OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture symbols be
> available.
> 
> I refer you to the ABI, particularly section 3:
> 
>   http://www.opengl.org/registry/ABI/#3
> 
> See especially 3.4, 3.5, and 3.6.
> 
> > As GL_EXT_framebuffer_blit is supported since 6.5, I would have
> > thought that BlitFramebufferEXT should be defined in the library.
> >
> > It is unfortunately that when I test some of the functions using
> > MESA, I need to get a pointer to glBlitFramebuffer and when I test
> > it on an older piece of hardware then I need to get a pointer to
> > glBlitFramebufferEXT.
> 
> Sorry; this is how OpenGL is specified.  As you can read above,
> exposing glBlitFramebuffer is an implementation courtesy.  An argument
> could be made that nothing above GL 1.2 should be exported, so that
> developers like you and I would more quickly ascertain that we are
> writing invalid code!  That'd probably be a bad idea though, because
> a lot of `in the wild' code is likely to break if we remove all those
> entry points.
> 
> Anyway, the only valid way to get glBlitFramebuffer, or any extension
> really, is to load it dynamically.  This is why I recommend GLEW :)
> 

I agree with what you said and have planned to use GLEW, this gives me extra
motivation to use it ^_^ 
I guess I am just curious why this one is left out as all the other GL calls we
use in our software are included in Mesa's libGL, especially when
BlitFramebuffer is just an alias to it.

Anyway, thanks a lot. Once we get GLEW going here then I probably won't care
much about it.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] Mesa 7.7.1 release candidate 2 and Mesa 7.8 release candidate 2

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My intention is that these will be the last release candidates.  Unless
there is some major show-stopping bug discovered, I plan to release
7.7.1 and 7.8 this *Friday*.  I will ping people on IRC before making
the release.

Mesa 7.7.1-rc2 available for testing at
ftp://freedesktop.org/pub/mesa/7.7/RC/

md5sums:

9ce0dadee431fffdaad994945d2ea676  MesaLib-7.7.1-rc2.tar.gz
63b28baeb1331223e3075970c5daa926  MesaLib-7.7.1-rc2.tar.bz2
dff3d833314ca62b810decab5703e9cd  MesaLib-7.7.1-rc2.zip
12bcbe4a74461d58faa73f0430971216  MesaDemos-7.7.1-rc2.tar.gz
442e8a42ecb91ab0f47e4b4b6ade4922  MesaDemos-7.7.1-rc2.tar.bz2
616ba723c1d286627fa068af23ba2062  MesaDemos-7.7.1-rc2.zip
f41b19e7584eb11886bd82ba7f80446e  MesaGLUT-7.7.1-rc2.tar.gz
924228f541e02d227c01e3459376a9da  MesaGLUT-7.7.1-rc2.tar.bz2
c916d8de81091b49e4127dce28c55e67  MesaGLUT-7.7.1-rc2.zip

Mesa 7.8-rc2 available for testing at ftp://freedesktop.org/pub/mesa/7.8/RC/

md5sums:

c9b1ed6118b382395fad755fe4892952  MesaLib-7.8-rc2.tar.gz
56b0a6385eee5e733d85e430a0cde1f3  MesaLib-7.8-rc2.tar.bz2
17e59e52253260ac678931767e240087  MesaLib-7.8-rc2.zip
750c8f7968711ec3485f65cae5905de7  MesaDemos-7.8-rc2.tar.gz
685cb0ac6573877835c58abe16873034  MesaDemos-7.8-rc2.tar.bz2
86606b12ac49d966ea3a4e81445ed4c7  MesaDemos-7.8-rc2.zip
0daca3e1fd683ccb7932f14e87e9b962  MesaGLUT-7.8-rc2.tar.gz
30eb579fa85d1b8f08bcd97093cb0535  MesaGLUT-7.8-rc2.tar.bz2
ad766f675263511aec4a546498ecfff5  MesaGLUT-7.8-rc2.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuoHagACgkQX1gOwKyEAw+AiACfUbvQlDr3OH3Ly4ri40p6lXj2
CAMAoI4bp9GWQepORxEw288Dvti+39Ri
=SAb7
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Høgsberg wrote:
> 2010/3/22 Ian Romanick <id...@fr...>:
>> Kristian Høgsberg wrote:
>>> 2010/2/8 Francisco Jerez <cur...@ri...>:
>>>> The spec says (regarding glXCreateWindow): "If there is already a
>>>> GLXFBConfig associated with win (as a result of a previous
>>>> glXCreateWindow call), then a BadAlloc error is generated.". It will
>>>> also come useful to implement DRI2InvalidateBuffers for the indirect
>>>> case.
>>>>
>>>> Signed-off-by: Francisco Jerez <cur...@ri...>
>> I've put this version of this patch (with krh's R-b) in my GLX-fixes
>> tree.  Are the all the rest in Kristian's dri2-invalidate tree?
> 
> We dropped this one, and the rest is in my dri2-invalidate tree.

Why was it dropped?  I believe that it enforced correct behavior.  If
this really does need to be removed, any suggestions how to fix my tree?
:(  git-revert seems the only way, but that makes for ugly history in a
tree like this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuoEBcACgkQX1gOwKyEAw+iWgCePAg8e40Lj+kYXt3xT+ZiQG+g
r6sAnRf0ez7NGhXarxYEw3oPk5E0xBi7
=CVLf
-----END PGP SIGNATURE-----

[Mesa3d-dev] [Bug 27254] glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27254





--- Comment #1 from Tom Fogal <tf...@al...>  2010-03-22 17:41:58 PST ---
> EXT_framebuffer_object.xml specifies that BlitFramebufferEXT
> to be hidden while BlitFramebuffer is exposed as described in
> ARB_framebuffer_object.xml, is that intentional?

This is reasonable, at least.  The Linux OpenGL ABI only requires
that OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture symbols be
available.

I refer you to the ABI, particularly section 3:

  http://www.opengl.org/registry/ABI/#3

See especially 3.4, 3.5, and 3.6.

> As GL_EXT_framebuffer_blit is supported since 6.5, I would have
> thought that BlitFramebufferEXT should be defined in the library.
>
> It is unfortunately that when I test some of the functions using
> MESA, I need to get a pointer to glBlitFramebuffer and when I test
> it on an older piece of hardware then I need to get a pointer to
> glBlitFramebufferEXT.

Sorry; this is how OpenGL is specified.  As you can read above,
exposing glBlitFramebuffer is an implementation courtesy.  An argument
could be made that nothing above GL 1.2 should be exported, so that
developers like you and I would more quickly ascertain that we are
writing invalid code!  That'd probably be a bad idea though, because
a lot of `in the wild' code is likely to break if we remove all those
entry points.

Anyway, the only valid way to get glBlitFramebuffer, or any extension
really, is to load it dynamically.  This is why I recommend GLEW :)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

On Mon, Mar 22, 2010 at 10:46:37PM +0100, Nicolai Haehnle wrote:
> On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <li...@sk...> wrote:
> >> In
> >> particular, the Mesa core <-> classic driver split only makes sense if
> >> there are enough people who are actually working on those drivers who
> >> would support the split. Otherwise, this is bound to lead straight
> >> into hell.
> >>
> >> In a way, the kernel people got it right: put all the drivers in one
> >> repository, and make building the whole package and having parallel
> >
> > "put all the drivers in one repository"?
> >
> > So, all of:
> >        * drm
> >        * firmware
> >        * libdrm
> >        * xorg
> >        * mesa/dri
> >        * mesa/gallium
> >        * libxvmc
> >        * libvdpau
> >        (add more here)
> > of the same driver stack, in one repository?
> 
> Why not?
> 
> Mind you, I'm not advocating for any change at all, but as long as you
> feel the need to move stuff around, why not try finding a goal that
> people actually find useful? Of course, my suggestion is probably
> crap, too.

Great, seems we agree on something here.

> [snip]
> > The real question is: where is the most pain, and how can we reduce it.
> > And the most pain is between the driver specific parts.
> 
> Nobody has ever had to feel the pain of a separation between Mesa core
> and drivers. And since a git log I've just done tells me that you have
> committed only twice to the Mesa repository within the last year or
> so, maybe you should listen to the opinion of people who *have* been
> active in the Mesa tree when it comes to that subject, and are working
> on drivers that are probably significantly more involved than whatever
> Unichrome does.

Heh.
 
> >> 2) it wouldn't actually solve the DRM problems, because we want to
> >> have the DRM in our codebase, and the kernel people want to have it in
> >> theirs.
> >
> > The kernel people can have theirs. What stops anyone from getting the
> > drm code of a released driver stack into the next kernel version?
> >
> > But when anyone decides they need a new driver stack which requires a
> > new drm module, it should be easy to replace the stock kernel module.
> 
> And that has worked so well in the past.

Yes, it did. And people for more than a year still pulled the mesa/drm 
tree and built and installed it, as doing this often solved their 
"driver stack internal" problems for them.

Luc Verhaegen.

[Mesa3d-dev] [Bug 27254] New: glBlitFramebuffer is defined while glBlitFramebufferEXT is hidden as described by the XMLs

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27254

           Summary: glBlitFramebuffer is defined while glBlitFramebufferEXT
                    is hidden as described by the XMLs
           Product: Mesa
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: al...@au...
                CC: al...@au...


Hi all,
EXT_framebuffer_object.xml specifies that BlitFramebufferEXT to be hidden while
BlitFramebuffer is exposed as described in ARB_framebuffer_object.xml, is that
intentional? 

As GL_EXT_framebuffer_blit is supported since 6.5, I would have thought that
BlitFramebufferEXT should be defined in the library. 

It is unfortunately that when I test some of the functions using MESA, I need
to get a pointer to glBlitFramebuffer and when I test it on an older piece of
hardware then I need to get a pointer to glBlitFramebufferEXT.

Anyway, thanks so much for reading, I just want to know rather this is a bug or
the actual implementation so that I can do the appropriate thing in my program.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Nicolai H. <nha...@gm...>]

On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <li...@sk...> wrote:
>> In
>> particular, the Mesa core <-> classic driver split only makes sense if
>> there are enough people who are actually working on those drivers who
>> would support the split. Otherwise, this is bound to lead straight
>> into hell.
>>
>> In a way, the kernel people got it right: put all the drivers in one
>> repository, and make building the whole package and having parallel
>
> "put all the drivers in one repository"?
>
> So, all of:
>        * drm
>        * firmware
>        * libdrm
>        * xorg
>        * mesa/dri
>        * mesa/gallium
>        * libxvmc
>        * libvdpau
>        (add more here)
> of the same driver stack, in one repository?

Why not?

Mind you, I'm not advocating for any change at all, but as long as you
feel the need to move stuff around, why not try finding a goal that
people actually find useful? Of course, my suggestion is probably
crap, too.


[snip]
> The real question is: where is the most pain, and how can we reduce it.
> And the most pain is between the driver specific parts.

Nobody has ever had to feel the pain of a separation between Mesa core
and drivers. And since a git log I've just done tells me that you have
committed only twice to the Mesa repository within the last year or
so, maybe you should listen to the opinion of people who *have* been
active in the Mesa tree when it comes to that subject, and are working
on drivers that are probably significantly more involved than whatever
Unichrome does.


>> 2) it wouldn't actually solve the DRM problems, because we want to
>> have the DRM in our codebase, and the kernel people want to have it in
>> theirs.
>
> The kernel people can have theirs. What stops anyone from getting the
> drm code of a released driver stack into the next kernel version?
>
> But when anyone decides they need a new driver stack which requires a
> new drm module, it should be easy to replace the stock kernel module.

And that has worked so well in the past.

cu,
Nicolai

Re: [Mesa3d-dev] A tiny problem regarding with the mesa source layout and DRI driver development

[Nicolai H. <nha...@gm...>]

On Mon, Mar 22, 2010 at 1:29 PM, LiYe <omn...@gm...> wrote:
> I'm interested in openGL implementation and the DRI driver development.
> Specifically, I want to learn how an OpenGL command was implemented and
> how it was converted into direct rendering context and transferred to
> the hardware. I know this is a quite complicated and time-consuming
> task, but it would be great if I can start the learning cruve with my
> newbie background. So I'm trying to look into the mesa codes. However,
> it seems quite large and monolithic and I cannot find a suitable
> breaking point. So I wrote this to ask for some experienced advice. For
> an overview of how DRI works in codes(not in theory as explained in
> documents), where should I start with?

I would suggest getting an IDE that has decent code browsing
capabilities (I personally like to play with the KDevelop4 beta even
though it's still a bit flaky) and just start stepping through your
favourite driver in a debugger.

Note that your life will be less painful if you have a second machine
from which you can SSH in, so that your gdb session doesn't live on
the same X server as the OpenGL application that you're debugging.

cu,
Nicolai

Re: [Mesa3d-dev] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.

[Kristian H. <kr...@bi...>]

2010/3/22 Ian Romanick <id...@fr...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> 2010/2/8 Francisco Jerez <cur...@ri...>:
>>> The spec says (regarding glXCreateWindow): "If there is already a
>>> GLXFBConfig associated with win (as a result of a previous
>>> glXCreateWindow call), then a BadAlloc error is generated.". It will
>>> also come useful to implement DRI2InvalidateBuffers for the indirect
>>> case.
>>>
>>> Signed-off-by: Francisco Jerez <cur...@ri...>
>
> I've put this version of this patch (with krh's R-b) in my GLX-fixes
> tree.  Are the all the rest in Kristian's dri2-invalidate tree?

We dropped this one, and the rest is in my dri2-invalidate tree.

Kristian

Re: [Mesa3d-dev] [xserver patch v5 3/5] glx: Enforce a 1:1 correspondence between GLX and X11 windows.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Høgsberg wrote:
> 2010/2/8 Francisco Jerez <cur...@ri...>:
>> The spec says (regarding glXCreateWindow): "If there is already a
>> GLXFBConfig associated with win (as a result of a previous
>> glXCreateWindow call), then a BadAlloc error is generated.". It will
>> also come useful to implement DRI2InvalidateBuffers for the indirect
>> case.
>>
>> Signed-off-by: Francisco Jerez <cur...@ri...>

I've put this version of this patch (with krh's R-b) in my GLX-fixes
tree.  Are the all the rest in Kristian's dri2-invalidate tree?

> Looks good,
> 
> Reviewed-by: Kristian Høgsberg <kr...@bi...>
> 
>> ---
>> v5: Simplification as suggested by Kristian.
>>
>>  glx/glxcmds.c   |   24 +++++++++++++++++++++++-
>>  glx/glxserver.h |    1 +
>>  2 files changed, 24 insertions(+), 1 deletions(-)
>>
>> diff --git a/glx/glxcmds.c b/glx/glxcmds.c
>> index 77afbf4..cac30e6 100644
>> --- a/glx/glxcmds.c
>> +++ b/glx/glxcmds.c
>> @@ -51,6 +51,15 @@
>>  #include "indirect_table.h"
>>  #include "indirect_util.h"
>>
>> +static int glxWindowPrivateKeyIndex;
>> +static DevPrivateKey glxWindowPrivateKey = &glxWindowPrivateKeyIndex;
>> +
>> +__GLXdrawable *
>> +glxGetDrawableFromWindow(WindowPtr pWin)
>> +{
>> +       return dixLookupPrivate(&pWin->devPrivates, glxWindowPrivateKey);
>> +}
>> +
>>  static int
>>  validGlxScreen(ClientPtr client, int screen, __GLXscreen **pGlxScreen, int *err)
>>  {
>> @@ -519,6 +528,9 @@ __glXGetDrawable(__GLXcontext *glxc, GLXDrawable drawId, ClientPtr client,
>>        return NULL;
>>     }
>>
>> +    dixSetPrivate(&((WindowPtr)pDraw)->devPrivates, glxWindowPrivateKey,
>> +                 pGlxDraw);
>> +
>>     return pGlxDraw;
>>  }
>>
>> @@ -1107,7 +1119,7 @@ __glXDrawableRelease(__GLXdrawable *drawable)
>>     }
>>  }
>>
>> -static int
>> +static int
>>  DoCreateGLXDrawable(ClientPtr client, __GLXscreen *pGlxScreen, __GLXconfig *config,
>>                    DrawablePtr pDraw, XID glxDrawableId, int type)
>>  {
>> @@ -1128,6 +1140,10 @@ DoCreateGLXDrawable(ClientPtr client, __GLXscreen *pGlxScreen, __GLXconfig *conf
>>        return BadAlloc;
>>     }
>>
>> +    if (type == GLX_DRAWABLE_WINDOW)
>> +           dixSetPrivate(&((WindowPtr)pDraw)->devPrivates,
>> +                         glxWindowPrivateKey, pGlxDraw);
>> +
>>     return Success;
>>  }
>>
>> @@ -1422,6 +1438,12 @@ int __glXDisp_CreateWindow(__GLXclientState *cl, GLbyte *pc)
>>        return BadWindow;
>>     }
>>
>> +    /* Make sure there're no already associated GLX drawables. */
>> +    if (glxGetDrawableFromWindow((WindowPtr)pDraw)) {
>> +       client->errorValue = req->window;
>> +       return BadAlloc;
>> +    }
>> +
>>     if (!validGlxFBConfigForWindow(client, config, pDraw, &err))
>>        return err;
>>
>> diff --git a/glx/glxserver.h b/glx/glxserver.h
>> index 1daf977..3c49b5e 100644
>> --- a/glx/glxserver.h
>> +++ b/glx/glxserver.h
>> @@ -80,6 +80,7 @@ typedef struct __GLXcontext __GLXcontext;
>>
>>  extern __GLXscreen *glxGetScreen(ScreenPtr pScreen);
>>  extern __GLXclientState *glxGetClient(ClientPtr pClient);
>> +extern __GLXdrawable *glxGetDrawableFromWindow(WindowPtr pWin);
>>
>>  /************************************************************************/
>>
>> --
>> 1.6.4.4

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuny3IACgkQX1gOwKyEAw8s7wCdHFT2LwWBMvANCHW3vAfCbRLv
S/4An3U/kZH+Q4OxUJD3q6YlrFiG2RW4
=g9WK
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] mesa 7.8 GIT: Broken by "glapi: Correctly generate static disatches for X86."

[Chia-I Wu <ol...@lu...>]

2010/3/22 Michel Dänzer <mi...@da...>:
> On Sat, 2010-03-20 at 14:51 +0100, Sedat Dilek wrote:
>> while upgrading my mesa from 7.8 GIT branch, I saw with
>>
>> commit 41a87a43e11c664935349f938022d58d3e22da4e
>> "glapi: Correctly generate static disatches for X86."
>>
>> the build breaking (especially with xdemos).
>>
>> - Sedat -
>>
>> [build.log]
>> ....
>> ccache gcc -I../../include  -g -O2 -Wall -Wmissing-prototypes -std=c99
>> -ffast-math -fvisibility=hidden -fno-strict-aliasing -g  -fPIC
>> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
>> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
>> -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
>> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
>> glxdemo.c -L../../lib -lGL -L/usr/lib  -lm -lX11 -lpthread -o glxdemo
>> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT'
>> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE'
>> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE'
>> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT'
>> collect2: ld returned 1 exit status
>> make[2]: *** [glsync] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT'
>>
>> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE'
>> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE'
>> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT'
>> collect2: ld returned 1 exit status
>> make[2]: *** [glxdemo] Error 1
>> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT'
>> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE'
>> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE'
>> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT'
>> collect2: ld returned 1 exit status
>> make[2]: *** [glthreads] Error 1
>
> These demos are broken: Those GL API calls aren't part of the Linux
> OpenGL ABI, so their addresses need to be retrieved with
> glXGetProcAddress().
The errors were due to missing symbols in libGL.so.  The demos did not call
them.  The bug was triggered by me in 41a87a43e11c664935349f938022d58d3e22da4e
and was fixed in 6fed3a9fa0a87ae797f995de5b51eb9be3493fe0.

-- 
ol...@Lu...

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luc Verhaegen wrote:
> On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
>>
>> I've been busy trying to get a release out the door, so I haven't looked
>> at these patches yet.  I won't have a chance to look at the patches
>> until at least late next week.  I also wasn't at FOSDEM, so I don't have
>> any of the background info.
> 
> I've grouped the slides and the recordings at the top of my blog entry 
> about this.
> 
> The patches themselves are actually copies of eachother, with minor 
> differences to adjust for changes of the tree around it (there are 16 or 
> so versions of the sdk done from 7.0 through 7.8). Any actual patch is 
> small, and it is build system only.
> 
>> If these patches try to enforce a "stable" interface between core Mesa
>> and the classic DRI drivers, we're not interested.  At all.  This has
>> been discussed and rejected many, many times before.
> 
> Ah, prepossession.
> 
> Ask yourself, did the fact that xf86 video drivers were out of tree, 
> ever stop anyone from _really_ bad api breakage stunts?

The difference, and I think this is significant, is that the
functionality provided by the xf86 video drivers through the X server
hasn't changed much in quite some time.  The amount of functionality
added in every single major release of Mesa which requires driver
changes is significant.  We're far enough behind the state of the GL
spec and the closed-source drivers that I don't really want anything
that will slow us down.

You can't aim a stable interface at a moving target.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkunq7sACgkQX1gOwKyEAw8dqwCfR9/JjfCecV0Q4Po4AdnJaTOE
QrQAoJu1+zMz5shOHrhmOSL+L2um190q
=+eep
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [PATCH] nvfx: fix sampler views support

[Roland S. <sr...@vm...>]

On 22.03.2010 17:46, Luca Barbieri wrote:
> The code was half converted, resulting in texturing being totally
> broken.
> 
> [sending this because my account hasn't been created yet]
> 
> ---
>  src/gallium/drivers/nvfx/nv30_fragtex.c |    2 +-
>  src/gallium/drivers/nvfx/nv40_fragtex.c |    2 +-
>  src/gallium/drivers/nvfx/nvfx_context.h |    1 -
>  3 files changed, 2 insertions(+), 3 deletions(-)

Applied, thanks!

Roland

[Mesa3d-dev] [Bug 27250] New: glEnable(GL_VERTEX PROGRAM POINT SIZE) doesn't work

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27250

           Summary: glEnable(GL_VERTEX PROGRAM POINT SIZE) doesn't work
           Product: Mesa
           Version: git
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: ne...@li...


Created an attachment (id=34328)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34328)
Test case

Under GL 2.0 you are meant to be able to write to the gl_PointSize output from
the vertex shader to change the point size per-vertex. This doesn't appear to
work in Mesa.

The attachment is a simple program that draws a single point in the center of
the screen. It uses a vertex shader to change the size of the point to 32
pixels. Under Mesa git master this ends up being a single pixel but on an
NVIDIA machine it correctly ends up as 32 pixels.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27248] New: Mesa slang float to int casting bug

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27248

           Summary: Mesa slang float to int casting bug
           Product: Mesa
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: janitor
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: it...@gm...


i believe where is a typo in :

slang_typeinfo.c

allowing "float to int" conversation instead of "int to float":

this :
slang_type_specifier_compatible(const slang_type_specifier * x,
                                const slang_type_specifier * y)
{
   /* special case: float == int */
   if (x->type == SLANG_SPEC_INT && y->type == SLANG_SPEC_FLOAT) {
      return GL_TRUE;
   }
should be replaced with :
   if (x->type == SLANG_SPEC_FLOAT && y->type == SLANG_SPEC_INT) {


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [PATCH] nvfx: fix sampler views support

[Luca B. <lu...@lu...>]

The code was half converted, resulting in texturing being totally
broken.

[sending this because my account hasn't been created yet]

---
 src/gallium/drivers/nvfx/nv30_fragtex.c |    2 +-
 src/gallium/drivers/nvfx/nv40_fragtex.c |    2 +-
 src/gallium/drivers/nvfx/nvfx_context.h |    1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nvfx/nv30_fragtex.c b/src/gallium/drivers/nvfx/nv30_fragtex.c
index 2b56f45..54e4757 100644
--- a/src/gallium/drivers/nvfx/nv30_fragtex.c
+++ b/src/gallium/drivers/nvfx/nv30_fragtex.c
@@ -91,7 +91,7 @@ struct nouveau_stateobj *
 nv30_fragtex_build(struct nvfx_context *nvfx, int unit)
 {
 	struct nvfx_sampler_state *ps = nvfx->tex_sampler[unit];
-	struct nvfx_miptree *nv30mt = nvfx->tex_miptree[unit];
+	struct nvfx_miptree *nv30mt = (struct nvfx_miptree *)nvfx->fragment_sampler_views[unit]->texture;
 	struct pipe_texture *pt = &nv30mt->base;
 	struct nouveau_bo *bo = nouveau_bo(nv30mt->buffer);
 	struct nv30_texture_format *tf;
diff --git a/src/gallium/drivers/nvfx/nv40_fragtex.c b/src/gallium/drivers/nvfx/nv40_fragtex.c
index 5889b5e..05506e2 100644
--- a/src/gallium/drivers/nvfx/nv40_fragtex.c
+++ b/src/gallium/drivers/nvfx/nv40_fragtex.c
@@ -109,7 +109,7 @@ struct nouveau_stateobj *
 nv40_fragtex_build(struct nvfx_context *nvfx, int unit)
 {
 	struct nvfx_sampler_state *ps = nvfx->tex_sampler[unit];
-	struct nvfx_miptree *nv40mt = nvfx->tex_miptree[unit];
+	struct nvfx_miptree *nv40mt = (struct nvfx_miptree *)nvfx->fragment_sampler_views[unit]->texture;
 	struct nouveau_bo *bo = nouveau_bo(nv40mt->buffer);
 	struct pipe_texture *pt = &nv40mt->base;
 	struct nv40_texture_format *tf;
diff --git a/src/gallium/drivers/nvfx/nvfx_context.h b/src/gallium/drivers/nvfx/nvfx_context.h
index 001b19e..ab7225c 100644
--- a/src/gallium/drivers/nvfx/nvfx_context.h
+++ b/src/gallium/drivers/nvfx/nvfx_context.h
@@ -158,7 +158,6 @@ struct nvfx_context {
 	struct pipe_buffer *idxbuf;
 	unsigned idxbuf_format;
 	struct nvfx_sampler_state *tex_sampler[PIPE_MAX_SAMPLERS];
-	struct nvfx_miptree *tex_miptree[PIPE_MAX_SAMPLERS];
 	struct pipe_sampler_view *fragment_sampler_views[PIPE_MAX_SAMPLERS];
 	unsigned nr_samplers;
 	unsigned nr_textures;
-- 
1.7.0.1.147.g6d84b

Re: [Mesa3d-dev] mesa 7.8 GIT: Broken by "glapi: Correctly generate static disatches for X86."

[Michel D. <mi...@da...>]

On Sat, 2010-03-20 at 14:51 +0100, Sedat Dilek wrote: 
> Hi,
> 
> while upgrading my mesa from 7.8 GIT branch, I saw with
> 
> commit 41a87a43e11c664935349f938022d58d3e22da4e
> "glapi: Correctly generate static disatches for X86."
> 
> the build breaking (especially with xdemos).
> 
> - Sedat -
> 
> [build.log]
> ....
> ccache gcc -I../../include  -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fvisibility=hidden -fno-strict-aliasing -g  -fPIC
> -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS
> -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> glxdemo.c -L../../lib -lGL -L/usr/lib  -lm -lX11 -lpthread -o glxdemo
> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT'
> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE'
> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE'
> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT'
> collect2: ld returned 1 exit status
> make[2]: *** [glsync] Error 1
> make[2]: *** Waiting for unfinished jobs....
> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT'
> 
> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE'
> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE'
> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT'
> collect2: ld returned 1 exit status
> make[2]: *** [glxdemo] Error 1
> ../../lib/libGL.so: undefined reference to `glBlitFramebufferEXT'
> ../../lib/libGL.so: undefined reference to `glDeleteVertexArraysAPPLE'
> ../../lib/libGL.so: undefined reference to `glIsVertexArrayAPPLE'
> ../../lib/libGL.so: undefined reference to `glBlendEquationSeparateEXT'
> collect2: ld returned 1 exit status
> make[2]: *** [glthreads] Error 1

These demos are broken: Those GL API calls aren't part of the Linux
OpenGL ABI, so their addresses need to be retrieved with
glXGetProcAddress().


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] A tiny problem regarding with the mesa source layout and DRI driver development

[Jerome G. <gl...@fr...>]

On Mon, Mar 22, 2010 at 08:29:11PM +0800, LiYe wrote:
> Hi devs,
> 
> I have no idea if this is the right place to ask. But I've searched
> around and didn't find the answer. So I am sorry if I made a noise. 
> 
> I'm interested in openGL implementation and the DRI driver development.
> Specifically, I want to learn how an OpenGL command was implemented and
> how it was converted into direct rendering context and transferred to
> the hardware. I know this is a quite complicated and time-consuming
> task, but it would be great if I can start the learning cruve with my
> newbie background. So I'm trying to look into the mesa codes. However,
> it seems quite large and monolithic and I cannot find a suitable
> breaking point. So I wrote this to ask for some experienced advice. For
> an overview of how DRI works in codes(not in theory as explained in
> documents), where should I start with?
> 
> About my background, as an EE student mainly working in wireless
> communication areas, I only have some basic knowledge of C
> programming(but no large project experience) and several years of Linux
> administration experience. I also have some theoretical knowledge about
> Linux kernel and drivers.
> 
> Thanks sincerely for your time and input. 
> 
> Best Regards,
> Li Ye
> 

I would suggest looking at gallium (src/gallium/include/pipe for API
btw gallium & driver). The high level API like OpenGL go through a lot
of common code before hitting the driver, classic mesa hw driver are
bit harder to understand than gallium hw driver. Gallium offer a "clear"
interface btw the higher level API (OpenGL, OpenEGL, OpenVG, ...) and
the hw driver (src/gallium/include/pipe) thus i believe they are easier
to understand (you can then choose to look into src/gallium/driver).

Cheers,
Jerome

[Mesa3d-dev] A tiny problem regarding with the mesa source layout and DRI driver development

[LiYe <omn...@gm...>]

Hi devs,

I have no idea if this is the right place to ask. But I've searched
around and didn't find the answer. So I am sorry if I made a noise. 

I'm interested in openGL implementation and the DRI driver development.
Specifically, I want to learn how an OpenGL command was implemented and
how it was converted into direct rendering context and transferred to
the hardware. I know this is a quite complicated and time-consuming
task, but it would be great if I can start the learning cruve with my
newbie background. So I'm trying to look into the mesa codes. However,
it seems quite large and monolithic and I cannot find a suitable
breaking point. So I wrote this to ask for some experienced advice. For
an overview of how DRI works in codes(not in theory as explained in
documents), where should I start with?

About my background, as an EE student mainly working in wireless
communication areas, I only have some basic knowledge of C
programming(but no large project experience) and several years of Linux
administration experience. I also have some theoretical knowledge about
Linux kernel and drivers.

Thanks sincerely for your time and input. 

Best Regards,
Li Ye

[Mesa3d-dev] [Bug 27216] Assignment with a function call in an if statement causes an assertion failure

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27216


Vinson Lee <vl...@vm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mesa3d-                     |br...@vm...
                   |de...@li...   |




--- Comment #1 from Vinson Lee <vl...@vm...>  2010-03-21 22:36:50 PST ---
mesa: 9fc6c8b831e5b43ae86ece6a531fc892f6f66356 (master)

(gdb) bt
#0  0x0073f422 in __kernel_vsyscall ()
#1  0x009ff4d1 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x00a02932 in *__GI_abort () at abort.c:92
#3  0x009f8648 in *__GI___assert_fail (assertion=0x424373 "index >= 0",
file=0x424300 "shader/slang/slang_emit.c", line=350, 
    function=0x424dd4 "storage_to_src_reg") at assert.c:81
#4  0x003a2373 in storage_to_src_reg (src=0x97f965c, st=0xb65a7de0) at
shader/slang/slang_emit.c:350
#5  0x003a2bf4 in emit_instruction (emitInfo=0xbfb05680, opcode=OPCODE_IF,
dst=0x0, src0=0xb65a7de0, src1=0x0, src2=0x0) at shader/slang/slang_emit.c:593
#6  0x003a4c85 in emit_if (emitInfo=0xbfb05680, n=0xb65a7f40) at
shader/slang/slang_emit.c:1700
#7  0x003a6722 in emit (emitInfo=0xbfb05680, n=0xb65a7f40) at
shader/slang/slang_emit.c:2488
#8  0x003a64ae in emit (emitInfo=0xbfb05680, n=0xb65a7f80) at
shader/slang/slang_emit.c:2361
#9  0x003a64eb in emit (emitInfo=0xbfb05680, n=0xb65a7fc0) at
shader/slang/slang_emit.c:2371
#10 0x003a6482 in emit (emitInfo=0xbfb05680, n=0xb65a8040) at
shader/slang/slang_emit.c:2358
#11 0x003a6bf2 in _slang_emit_code (n=0xb65a8040, vt=0xb659fc10,
prog=0x97f51e0, pragmas=0x94f1d78, withEnd=1 '\001', log=0xbfb06bfc)
    at shader/slang/slang_emit.c:2645
#12 0x003a1acc in _slang_codegen_function (A=0xbfb0571c, fun=0xb65a2b88) at
shader/slang/slang_codegen.c:5345
#13 0x002d6da1 in parse_code_unit (C=0xbfb05924, unit=0xbfb05bd4,
shader=0x94f1d58) at shader/slang/slang_compile.c:2636
#14 0x002d6e7b in compile_binary (prod=0x980bd78 "\005\001", unit=0xbfb05bd4,
version=110, type=SLANG_UNIT_FRAGMENT_SHADER, infolog=0xbfb06bfc, 
    builtin=0xbfb05b24, downlink=0xbfb05ba8, shader=0x94f1d58) at
shader/slang/slang_compile.c:2679
#15 0x002d71f7 in compile_with_grammar (
    source=0x97f5160 "void\n main ()\n {\n   float thing;\n\n   if ((thing =
sqrt (5.0)) > 1.0)\n     gl_FragColor = vec4 (1.0, 0.0, 0.0, 1.0);\n }\n\n\n", 
    unit=0xbfb05bd4, type=SLANG_UNIT_FRAGMENT_SHADER, infolog=0xbfb06bfc,
builtin=0xbfb05b24, shader=0x94f1d58, pragmas=0x94f1d78, shader_type=1, 
    parsing_builtin=0) at shader/slang/slang_compile.c:2786
#16 0x002d74fe in compile_object (
    source=0x97f5160 "void\n main ()\n {\n   float thing;\n\n   if ((thing =
sqrt (5.0)) > 1.0)\n     gl_FragColor = vec4 (1.0, 0.0, 0.0, 1.0);\n }\n\n\n", 
    object=0xbfb05b24, type=SLANG_UNIT_FRAGMENT_SHADER, infolog=0xbfb06bfc,
shader=0x94f1d58, pragmas=0x94f1d78) at shader/slang/slang_compile.c:2912
#17 0x002d767e in _slang_compile (ctx=0x94c5248, shader=0x94f1d58) at
shader/slang/slang_compile.c:2964
#18 0x0028a42a in _mesa_compile_shader (ctx=0x94c5248, shaderObj=1) at
shader/shader_api.c:1466
#19 0x0034e742 in _mesa_CompileShaderARB (shaderObj=1) at main/shaders.c:80

#4  0x003a2373 in storage_to_src_reg (src=0x97f965c, st=0xb65a7de0) at
shader/slang/slang_emit.c:350
350        assert(index >= 0);
(gdb) print index
$1 = -1


src/mesa/shader/slang/slang_emit.c
   342  static void
   343  storage_to_src_reg(struct prog_src_register *src, const
slang_ir_storage *st)
   344  {
   345     const GLboolean relAddr = st->RelAddr;
   346     GLint index = st->Index;
   347     GLuint swizzle = st->Swizzle;
   348  
   349     /* if this is storage relative to some parent storage, walk up the
tree */
   350     assert(index >= 0);
   351     while (st->Parent) {
   352        st = st->Parent;
   353        if (st->Index < 0) {
   354           /* an error should have been reported already */
   355           return;
   356        }
   357        assert(st->Index >= 0);
   358        index += st->Index;
   359        swizzle = _slang_swizzle_swizzle(fix_swizzle(st->Swizzle),
swizzle);
   360     }


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27150] glBlitFramebuffer defined on 64bit but not 32bit of Ubuntu with Mesa7.7

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27150





--- Comment #7 from Chia-I Wu <ol...@gm...>  2010-03-21 20:10:05 PST ---
The gl* functions are generated from glAPI XMLs and scripts.  The original bug
was a bug in the scripts, and is fixed.  On the other hand, the XMLs do say
that glBlitFramebuffer should be exported while glBlitFramebuffer should not. 
See src/mesa/glapi/gen/{ARB,EXT}_framebuffer_object.xml.

Applications should use glXGetProcAddress to get the pointer to the missing
function.  Depending on one's interpretation, it may or may not be considered a
bug.  Please open a new bug against the XMLs if you think it is.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.