[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Using wsdisplay from the Xserver
-----BEGIN PGP SIGNED MESSAGE-----
On Jan 23, 2009, at 11:19 PM, Adam Hoka 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 /
This has the following advantages:
- - we're going to find graphics controllers not visible through /
- - 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
whatever - it could be completely agnostic regarding the actual PCI
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
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
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
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.
This would need minimal (if any) changes in existing wsdisplay
and allow X to use any graphics board you can stick into your
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |