Solo Xgl..

[Jon Smirl]

On Mon, 21 Feb 2005 20:34:36 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> On Monday 21 February 2005 20:17, Jon Smirl wrote:
> > I have all of the pieces needed to build this. I just can't figure out
> > where to hook it into the kernel. Worst case is that I have to go
> > modify 75 framebuffer drivers to explicitly support reset.
> 
> Wandering off-topic here...
> 
> You keep saying 75 or other big numbers.  Isn't the number closer to 10?  By
> which I mean, don't we really only care about structural changes to the fbdev
> drivers that have a corresponding drm driver?  That would leave: tdfx,
> radeon, rage128, mach64, mga, sis, unichrome, intel, savage... and maybe
> someday s3virge and trident too.
> 
> I don't want to get too bogged down on this point, but I'd forgotten to ask
> this at xdevconf.  I understand the appeal of having every fbdev driver
> behave the same, but it might be an easier pitch to only try to change the
> drivers that need this for 3D.

If I make structural changes to the fb-dev core I have to fix all of
the drivers even though we only use 10 of them. I guess I could make
the fixes for the 10 we use and just leave the others alone. Plus I
would like to get a software mesa solution running on the dumb
framebuffer drivers. I am only implementing the functions in the 10
drivers that we need. The rest get stubs.

An example of a change that would impact all of the drivers, splitting
fb_info into a fb_device and fb_head pieces. The current fb_info
structure assumes one card and one head. If you copy it for two heads
you end up copying a bunch of fields that are not meant to be copied
since they point at things that there is only one per device.

Nobody is arguing about changing the 75 drivers, it's just a lot of
work. Of course if I can come up with a scheme that avoids touching
the drivers I'll use it.

-- 
Jon Smirl
jonsmirl at gmail.com