Xorg 7.4 release plan
Dan Nicholson
dbn.lists at gmail.com
Wed Feb 27 09:43:18 PST 2008
On Wed, Feb 27, 2008 at 8:26 AM, Adam Jackson <ajax at redhat.com> wrote:
>
> On Tue, 2008-02-26 at 11:17 -0800, Dan Nicholson wrote:
> > On Tue, Feb 26, 2008 at 11:06 AM, Adam Jackson <ajax at redhat.com> wrote:
> > >
> > > February 29: Branch 1.4.99.901, no new features
> >
> > Out of curiosity, which version of mesa is being targeted? I would
> > assume master since that's what you've been using in Rawhide. In that
> > case, does a mesa release need to be coordinated? I guess this depends
> > on DRI2.
>
> Aah, the Mesa question. I love this part.
>
> DRI2, unlike pciaccess, is not a complete switchover. Both the DDX and
> the DRI driver can implement support for either or both of DRI1 and
> DRI2, so it's not blocking the release in the sense of "we can't ship
> until this works".
Unfortunately, building DRI2 requires some parts of mesa master
(dri_sarea.h for sure).
> I believe, though have not tested, that Mesa 7.0.x can be used to build
> the GLX support in current xserver, though obviously that won't get you
> DRI2 support. I would be thrilled to have a Mesa 7.1 release in time
> for xserver 1.5, but I don't know how this aligns with Brian's plans for
> the world.
If DRI2 was made conditional, then I believe you could do it. I made a
couple changes in both masters on how the generated sources are used
from mesa, but I could easily backport those to the mesa 7.0 branch.
> Of course, in my truly ideal world, we would build libGLcore.so from
> Mesa, and then you wouldn't need the Mesa source at xserver build time
> at all. Why has no one implemented this for me yet?
I have patches which kill off symlink-mesa.sh and all the
GL/mesa/Makefile.am's, removing a major source of the breakage, but I
haven't gotten far enough to build GLCore in Mesa. That might be
beyond my current abilities since I'm not familiar enough with the
necessary server interfaces. Unfortunately, you still need the mesa
source at xserver build time to build libglx since it pulls in sources
generated in mesa. Maybe there's a solution to that (libglxapi.so?),
but, again, that would take some more work.
--
Dan
More information about the xorg
mailing list