tech-kern archive

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

Re: Using wsdisplay from the Xserver

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 
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 <>
Adam Hoka <>
Adam Hoka <>

Attachment: pgpTrzHGOwGsS.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index