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

Stopping X from dying on font issues (Was: Debian runlevel policy?)

Joseph Carter <knghtbrd@debian.org> writes:

> [1  <text/plain; us-ascii (7bit)>]
> On Sat, Mar 06, 1999 at 07:47:52PM -0500, Branden Robinson wrote:
> > > 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.
> > 
> > Uh, WHAT program exactly is dying so hard because it can't get TTF fonts
> > that it kills the X server?
> > 
> > As long as everyday, regular X fonts are available, the X server should be
> > able to start up fine.
> xfstt goes into Fontpath as a font server.  You can I suppose use xset in
> ~/.xsession but that's hardly useful for globally available fonts.

Then use an xset in /etc/X11/Xsession or in /etc/X11/xdm/Xsetup_0.
This is what I do with other X options that I could put in the XF86
config. file but don't for lack of knowing what the relevant option is
called (for example, I do a 'xset +dpms' in these startup files; I
also get fonts from a network fontserver which occasionally has
issues, and an xset instead of a FontPath means I can still use my
machine when the font server is down or unreachable).

Actually, I might go so far as to say that the XF86Config file should
not contain anything that can be set later with xset and which can be
left out of the config. file without breaking it.  Hrm... this gives
me an idea - is there some file which we can guarantee is read each
time an X server is started (in the normal course of events)?
(Xsession isn't read by an xdm-initiated server until someone logs in, 
unfortunately)  If there were such a file, we could put all xset-able
and potentially server-killing stuff into that file, and simply log
all errors instead of having X go bouncing up and down.

Of course, what I am willing to bet is the most common misconfiguration 
- incorrect/inconsistent video settings - will still cause X to
bounce, but anything that will make a few X configurations more stable
(without, I think, causing too much chaos) is a good thing. (TM)

Reply to: