Nathan J. Williams wrote:

> The part of the XFree86 approach that bothers me is that it scans the
> entire universe of PCI busses itself, looking for a video card. That
> is duplicated effort, and it's also a pretty dangerous operation. What
> I'm suggesting is that you give X access to /dev/wsvideo or something,
> and wsvideo says "Hi, I'm a PCI card, vendor xxxx, product yyyy,
> revision z". 

I'm currently doing some work towards this.  The basic structure is to
add ioctl's at the wsdisplay/wscons level to deal with:

  1) Determining the framebuffer bus type, location and identity.  An
     example is:
	"pci:1:0:0 i:0x4c461002 s:0x00cc1028 c:0x03000002"
  2) Determining allowable mmap()able ranges and handle mapping them.
  3) Provide bus-dependant access - the only one implemented so far is
     pci config space reads and writes.

Most of the rest of the work is in the X server itself, mainly just
generalising device configuration to use the new ioctls.  At the moment
I'm targeting PCI devices, so the X server doesn't need to scan the PCI
bus(es) looking for framebuffers - it just knows that it can get all the
info from the wscons device.

For multiple frame buffer support, we probably need to add
/dev/wsdisplayN devices (or Nathan's /dev/wsvideoN - the name isn't
overly important).

The framework is designed so that it isn't PCI-centric, but that's the
easiest for me to work on right now.  I'll probably do TurboChannel
next, then that pretty much covers all the framebuffer-type hardware I
have access to.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/