Using wsdisplay from the Xserver

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

in order to get rid of some of the PCI cruft in the Xserver and to  
allow X to use more than one display device even when not using /dev/ 
mem or something similar I started hacking it into using wsdisplay  
ttys to find PCI-like video controllers instead of grubbing through / 
dev/pci0
This has the following advantages:
- - we're going to find graphics controllers not visible through /dev/pci0
- - we're going to see only graphics controllers
- - X doesn't need to know about the actual bus structure at all
- - X can mmap the right IO space for each individual device without  
knowing about PCI domains, bus layout and whatnot - as far as X is  
concerned each device can be in its own domain
- - X doesn't need to know how to translate bus addresses to physical to  
whatever - it could be completely agnostic regarding the actual PCI  
bus setup

There are a few problems though.
- - we currently don't create device nodes for wsdisplay > 0, MAKEDEV  
doesn't even know about ttyF* and so on.
- - we have no way to run hardware-specific ioctl()s on a wsdisplay that  
doesn't have any screens
- - by convention we let userland mmap() a graphics device's PCI  
resources at their bus addresses - can't do that either if there are  
no screens

Since screens or working terminal emulation are by no means necessary  
to access the underlying hardware I propose the following:
- - allow wsdisplays to attach even if they can't open any screens -  
userland may know how to set them up. This goes especially for genfb.
- - add another device entry for hardware-specific ioctl()s and mmap  
requests, let's name it ttyEhw, ttyFhw and so on. Supported ioctl()s  
would be WSDISPLAYIO_GTYPE and if applicable PCI_IOC_CFGREAD,  
PCI_IOC_CFGWRITE. Probably equivalents for other bus types. Also  
forward mmap() requests in order to map hardware resources ( obviously  
the resp. driver must be clever enough to reject attempts to mmap  
video memory at offset 0 if it has no way to know about it )
This would need minimal (if any) changes in existing wsdisplay drivers  
and allow X to use any graphics board you can stick into your computer  
in a much cleaner way than /dev/mem abuse or things like /dev/xf86.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSXqM0MpnzkX8Yg2nAQJ45wf7Bplxl7PYBU3aQt5i6fDybHhuuYVtt89T
eBbNZcESF+xy6a3TYq+G2taLay85MwWrjLKHdV6wA6+KTre4RzOhO2ei8JNXmHoD
X+74u11GUHyonlP6qrVoN5/NGzf11km4wfIgJyo33otV+0xNfxjJmz+kSzaYmFD4
4kbyaQJRdO+5tgPKFS3b8k1wCYMrqkK/c7ONzuV4tDJSv+1g5euyZ1/p7JyCQXVA
zY0Dw3GhVkCfbzKgZNhZxVCvH5OJ5KGaVpHue9cXIHR7fqg90IMqINaYnLjWmcAX
lSocsqZbXXaeJ6HmtntC+qzHvQKSu2SLIE1v9JPpBD5GTtvGDiF2hQ==
=SRsB
-----END PGP SIGNATURE-----