> I've been using Gerd Knorr's `"framebuffer aware" XF86_SVGA' patch on a
> Matrox Millenium for almost a month. It's a proof of concept: that if the
> graphics device support in XF86 is modularized sufficiently (as I hear it
> will be in XF86 4.0), then the XFree86 server(singular) will have
> accelerated FBDev support, and the next step will be to continue adding
> more kernel modeswitching support.
>
> >
> > The real solution to eliminating contention and incompatability amongst
> > these applications and libraries is a device driver interface to the
> > graphics hardware. This would have many benefits:
> >
>
> Such as I have described above?
Much more than that! :) I'm really looking for a complete solution. It's no
good having your X server happily coexist with the framebuffer if the whole
thing snarfs up when I run some game that directly accesses the graphics
hardware. We need to provide an efficient low level device driver that even
games writers will be happy to use. I think it would be a shame to put a lot of
effort into an X-only solution.
> > I propose the following:
> >
> > o Linux standardizes on a graphics device driver interface
> > o The driver interface, /dev/kgi, be based on the existing KGI drivers
> > o The XGGI X-server bypasses GGI and gets merged back into XFree86 as
> > XF86_KGI
> > o That a new graphics library, libkgi, be written for use by
> > applications
>
> Does this require Evstack? Last time I hacked around with GGI/KGI, it
> depended on a certain message-passing system (and had a rather limited
> system console, but that's probably fixed now).
I only see the KGI drivers as a set of already implemented rendering engines.
I'm not familiar with the detailed GGI architecture, but it's irrelevant since
the idea would simply be to take the KGI drivers and repackage them to whatever
parameter passing interface we chose.
> > This graphics library would therefore allow a single accelerated
> > device-ignorant XF86_KGI (or any other graphics application), to run on
> > top of graphics hardware that only supported a minimal "framebuffer
> > level" /dev/kgi. This is a much more general solution than XF86_FBDev.
>
> How?
Because it's not X-specific, and can also support acceleration if the hardware
supports it and software emulation if it does not.
> Is the /dev/fb-on-top-of-KGI support already in place? Does it require
> Evstack? If it doesn't, then your plan (partially) has a chance.
There's the kgicon driver, but anyways we wouldn't be using the KGI drivers in
their current form. Given that /dev/fb gives direct access to the framebuffer,
that seems to pretty much make it the bottom layer, and /dev/kgi would sit on
top of that, and probably provide a bitblt() function as it's lowest level
method of framebuffer access. It would be much tougher and less efficient to
implement /dev/fb on top of a bitblt() interface.
Ben Bridgwater
Please CC: bennyb@ntplx.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/