On Sat, Feb 14, 2009 at 09:49:12AM +0000, Stephen Borrill wrote:
On Fri, 13 Feb 2009, Andrew Doran wrote:
- Another part is getting X to autoconfigure. From my perspective this
means
doing a bit of research, I don't know well enough what happens with it. Is
X -configure smart enough these days?
Pretty much except for a few quirks.
I've put a script from one of our (my company's) projects at
ftp://ftp.netbsd.org/pub/NetBSD/misc/sborrill/xdriver
Looks like it is actually here:
ftp://ftp.netbsd.org/pub/NetBSD/misc/sborrill/xconfig
It's very dependent on the specific infrastructure around it which
I'll mention here for reference:
- Main system is in a ramdisk embedded in the kernel (but running
multiuser)
- Various modules such as shared libraries and X are available as
compressed (and encrypted in our case) vnds
- rc sends all output to a log file rather than the console. Hence you'll
see lots of > /dev/tty for printing messages to the user
- It will run with just 4 or 5 files (kernel, lib, X and gui vnds) which
can be loaded from CD, ffs, pxeboot/tftp/http and does not need any local
storage
- Any local storage is run in read-only mode (except when writing back
persistent settings - I had to comment out your code to stop downgrading
from read-write to read-only that was introduced just before 5.0)
In essence the script runs X -probeonly -configure and then post processes
the generated Xorg.conf to determine the driver being used (which can be
stored for future reference if there is any local storage). Certain quirks
are applied based on experience. These include falling back to VESA in
certain circumstances (namely DDC failing with the intel driver) and
selecting software cursor on some chipsets. The Xorg.conf actually used
for X is then autogenerated. The script I've uploaded is just part of
this.
This is great, thank you!