[Mesa3d-dev] DRI SDK and modularized drivers.

Luc Verhaegen libv at skynet.be
Mon Mar 22 16:49:17 PDT 2010


On Mon, Mar 22, 2010 at 10:46:37PM +0100, Nicolai Haehnle wrote:
> On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <libv at skynet.be> 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.



More information about the xorg mailing list