Michael wrote: > 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 ) I'm just wondering if the /dev node could get a more meaningful name, so it clear that its dedicated for this kind of access (calling it tty something is just odd :) ). > 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. Can we run Xorg as unprivileged with this? Keep up the good work! -- When in doubt, use brute force. Adam Hoka <ahoka%NetBSD.org@localhost> Adam Hoka <ahoka%MirBSD.de@localhost> Adam Hoka <adam.hoka%gmail.com@localhost>
Attachment:
pgpTrzHGOwGsS.pgp
Description: PGP signature