[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XDM... source level
> 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
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
> 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
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
Erik Walthinsen <email@example.com> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user