From owner-freebsd-hackers  Mon Apr 28 00:10:06 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA27986
          for hackers-outgoing; Mon, 28 Apr 1997 00:10:06 -0700 (PDT)
Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27977
          for <hackers@freebsd.org>; Mon, 28 Apr 1997 00:10:01 -0700 (PDT)
Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id RAA23556; Mon, 28 Apr 1997 17:09:57 +1000 (EST)
Message-ID: <19970428170957.09283@rf900.physics.usyd.edu.au>
Date: Mon, 28 Apr 1997 17:09:57 +1000
From: David Dawes <dawes@rf900.physics.usyd.edu.au>
To: hackers@freebsd.org
Subject: Re: xdm in /usr/X11R6/etc/rc.d problem
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Mon, Apr 28, 1997 at 11:08:08AM +1000, David Nugent wrote:
>> 	(sleep 10; /usr/X11R6/bin/xdm -config /usr/local/etc/xdm/xdm-config)&
>~
>> That works fine for me.
>
>Yes, me too. Just out of curiosity, why is the sleep needed?

I think the problem is with the Xserver taking a free VT before the
gettys have started (which means it may take one on which a getty does
get started).  I ususally tell the Xserver explicitly which VT to use
(in xdm's Xservers file), and the delay might not be needed in that
case.  I've kept the delay there to make certain that xfs has had time
to startup before xdm runs an X server.

Starting xdm from /etc/ttys as Jordan suggested may be a suitable
alternative, but I've never tried that myself.

>While I have you there... which version of XFree has the login.conf
>support (doesn't seem to be in the -current built for 3.2)? Does it
>need any more work?

I have no idea.  I don't recall seeing any patches for this being
submitted to us at XFree86.Org.  I don't have any machines running
-current at the moment.

I'd also like to see something that allows us to remove the direct
utmp/wtmp manipulation from xdm and xterm.

We're planning to make a new release based on 3.2A in the next month or
so.  It would be good if things like this could be included in it.

David