tech-kern archive

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

Re: Using wsdisplay from the Xserver



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

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.

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.

have fun
Michael

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

iQEVAwUBSXqYW8pnzkX8Yg2nAQJhpAf+OXFAtVgUFikdto5SrZl2Y+Gfh+zsYmka
sqMuRuQtDjLP7+0gLrjZOXQqvm0FxWCyc8SjcZJg8+0/jQ4XhMTxed0+7AEeh7P4
HOjVbzmJT0dtHYM5o9P9qKeqpUzWcVwh75+ZS1NEkLbjv0mDtDynt8wzh1glG9dI
gYXiwTrnee7x9sGylsGQ0e1ve/u3HPZHgGVXVih2KOpf7wSTB8btS7Xotvl+4n+J
IXOGjX/EJYdH3R+NTnSV8Nw0qCGcu4OZ3re1paopUawKCYfleTN37gFzKoYg2yb5
t0G9p/YEiCqQAxQmRvvscA2KY/02wpmyLFOQxRuAuc4sPoyuHCuoKA==
=ZrHX
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index | Old Index