Michael wrote: > Hello, > > On Jan 23, 2009, at 11:19 PM, Adam Hoka wrote: > > > 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 :) ). > > Well, there's already ttyE0-7, ttyEcfg and ttyEstat, Since there new > node belongs to the same device it should be ttyEsomething. Or maybe I > should just add some functionality to tty?cfg. True. Never mind then. :) > >> 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? > > We already do on macppc and sparc(64), although arguably we probably > shouldn't allow mapping PCI resources without INSECURE. Cool! -- 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:
pgp1MBd9l4c6i.pgp
Description: PGP signature