On Sat, Mar 06, 1999 at 06:50:14PM -0500, Branden Robinson wrote: > This works. I've verified it multiple times. For instance, set your > FontPath to refer ONLY to the font server, e.g. > > FontPath "unix/:7100" > > and kill xfs. Then start or restart xdm with local server management. > > xdm will try four, and only four, times to get the server started with no > fonts. After that it will give up and return you to your original VC no > worse for the wear. This process takes about ten seconds on my machine. Yes, this works (I'm pretty sure), I'm glad you got it fixed. Sure beats my hack doesn't it? > I guarantee that this works. > > Now then, if someone's xfs can't get started completely in the time it > takes xdm to cycle the X server four times, I suggest they add the locally > installed fonts (which will be there if they're running xfs anyway) to the > FontPath, remove the font server from the font path, or use a font server > on a remote host. Not an option in the case of xfstt. X servers don't speak TTF yet (yet..) But still, I think it's possible to add some delay or re-arrange things with the runlevels to fix this. > Given the getty/xdm fistcuffs of the past, I don't think changing xfs's > order in the runlevels is going to fix anything. *laugh* Actually it DID fix it on my box amazingly enough. But then, my problem is just that my system is short on RAM and processor power (and disk space, video memory, etc, etc, etc) => -- Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer PGP: E8D68481E3A8BB778EE22996C9445FBE The Source Comes First! To boldly go where no bunch of geeks have gone before :) --Joel Klecker
Attachment:
pgpkBBJxJyFNR.pgp
Description: PGP signature