Re: XDM... source level

[Erik Walthinsen <omega@omegacs.net>]

> the user doesn't have to restart XDM only tell it (through killall -HUP
> xdm) to reread it's configuration, and XDM will try and restart the
> display... that's smart.
Heheh.. I just tried it, and it works... :)  However, it seems to have this 
itty bitty little problem of giving up completely when you're running 
manually without debugging.  Runlevel 5 works just fine, though, so I'm not 
worried.  It is a little funky though, you have to specify both 
startAttempts and openTimeout (I'm using 2 and 1, resp.).  killall -HUP xdm
works just fine now, starting the cycle over again.

One minor problem now, though, which points to a flaw in this particular 
method:  when I fix the XF86Config file, it still doesn't work.  Know why?  
It's the 1 second openTimeout.  The default is 5.  So what appears to be 
happening is:

1) xdm starts server, try 1.
2) xdm tries to connect with port 6000 for openTimeout seconds
3) if it can't, it restarts the server, try 2.
4) tries to connect to port 6000 for openTimeout seconds
5) fails, disables server.

So we still have the asynch problem of a system that can't (for whatever 
reason) start the server in 5 seconds, plus we have the fixed 10sec delay 
if things are broken.

I saw some Debug messages in there (while searching for the definition of 
Debug... it must be in libX11) about "Server for display %s terminated
unexpectedly...", so I'm going to go look at the code there and see if 
there's a way to modify the code to trap for server failures, rather than 
XDMCP failures (so we can find out immediately rather than waiting for 
timeoues).

> Here, I've seen a great flaw in X, bigger than the loop of death.  If my
> card, doesn't have a driver, it's unusable.
Yeah, that's the biggest problem for Linux in general.  Part of the 
seul-pub effort (actually a subgroup of that) will be organizing 
information on as much hardware as possible, including stuff that isn't 
supported, then using that information to push for support, either official 
vendor support, release of appropriate documentation, or reverse 
engineering.  That should help the situation quite a bit, I hope.

>   As an absolute minimum, the generic driver in X should be able to do
> equivalent to Windows, and run a generic VGA or SVGA card in 800x600 with
> 4 or 8 pixel depth.
Would it be possible to create a single 'recovery' server that includes the 
generic (S)VGA modes, mono, plus NVidia support?  That might be extremely
useful, and we can try to make it as small as we can.  It doesn't have to 
be fast, or have PEX or XIE or any other extensions, just be enough to 
start X and run a basic recovery application.

Are you (Orn) close enough to building something like that?  If so, go for 
it, and find help if you need it.  A webpage would be in order too.  If 
not, is there anyone else out there who would be able to do that?

> and when I'm done with that I'm going to collect some modelines from the
> Monitor and Device files to collect some VESA modelines, there is a pretty
> complete list there I think.
That and the Windoze monitor?.inf files should give you about a thousand 
monitors (Monitors has 59, monitor?.inf has 962!).  There are a few 
repositories out there as well, such as the one in Japan I got my laptop 
configuration from.

The hardware guide that I want to get started (under seul-pub with major 
help from other groups) should be an amazing source of information.  If we 
can make sure that everything it has can be packaged up efficiently enough 
to fit on the (secondary) install media, then we'll have a serious win over 
everyone else.


     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user