| On Wed, Mar 13, 2002 at 10:24:13PM +0100, Frank van der Linden wrote:
| > 
| > The mach64 framebuffer is a good thing because it's the chipset that
| > came/comes on-board with some ultrasparc machines, and, I think, some macs.
| > 
| > However, it would be a bad idea to declare it a supported interface
| > for other ports like the i386. First of all, if we want some kind of
| > MI support it's best if it's added to wscons. On i386, it's pretty
| > much impossible to support a /dev/fb, because it would mean duplicating
| > much of the XFree86 effort for db drivers for each kind of card.
| > Which would be a waste and totally impossible because of lack of
| > manpower.
|
| Hmm, I suppose it would nearly impossible to implement the API the X 
| drivers use in some kind of shim LKM layer?  So a wrapper LKM + driver
| could be loaded and wscons would use the card via the shim / emulation layer.
|
| Then it wouldn't be duplicating the card drivers, just the interface that
| they use.

The API that those alleged drivers use is poking around /dev/mem and issuing
inb()/outb() calls.  /dev/pci (and /dev/sbus) are an attempt to make this
a bit more MI, but this is really a hack to work around the basic problem.
So no, a LKM shim won't help things.

What we should be able to do is have the kernel identify that a device is
a display card, read whatever default configuration that bus provides,
and determine what the device's extents.  This information should be provided
to the X server through a couple of ioctls on some device.  But each device
node should provide information for just a single frame buffer.

Eduardo