tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Using wsdisplay from the Xserver

Hash: SHA1


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

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index