Hal and KDM breakage (was Re: KDE4 and input events stalled)

[Joe Marcus Clarke]

On Tue, 2009-04-07 at 23:12 -0700, Tim Kientzle wrote:
> >>> I'm still curious whether it's feasible to just not monitor the vtys.
> >> Sure, you can try it.  Especially if you're not using GNOME, this might
> >> be fine.  Just remove the hacks from hald's rc.d script.
> 
> I think I finally understand the issue here.  Basically,
> there seem to be two options:
> 
> Option 1: Comment out this line from /usr/local/etc/rc.d/hald
>       #start_cmd="hald_start"
> 
> After this change, the rc.d/hald script will start hald
> immediately, so that hald will be running before /etc/ttys
> is processed.
> 
> This allows KDM/xdm/gdm to be started either from /etc/ttys
> or from a very simple rc.d script (in particular, the 'lshal'
> and 'getty' checks are not necessary in this case).
> 
> The risk with this approach is that hald on 7-STABLE and
> earlier may be unable to detect whether the user is local or
> using a remote X terminal, and hence the auto-mount features
> of KDE and Gnome may not function properly.  On FreeBSD-CURRENT,
> this should be fine and everything should work properly.
> 
> Option 2: Use the current hald script as-is.
> 
> With this, the rc.d/hald script sets up a background process
> that will start hald only after /etc/ttys has been processed.
> 
> As a result, KDM cannot be started in the traditional fashion
> from /etc/ttys because KDM cannot be started before hald.
> (Although Robert claims this should work...)
> 
> In this case, KDM can only be started from an rc.d script,
> and that rc.d script needs to use some variant of the
> "lshal" hack to ensure that KDM won't start before hald.
> 
> The advantage of this approach is that auto-mount should
> function correctly in KDE and Gnome, even on 7-STABLE
> and earlier.
> 
> Joe:  Did I get this right?

This sounds right, but I have not validated the functionality of an
immediate start of hald on -CURRENT.  One problem we were seeing prior
to bland's work, and prior to the delay was that the keyboard and mouse
would lock up if CK was started before init spawned the ttys.  So beyond
making sure CK reports the correct active session, you would want to
make sure X is usable at all.

Joe

> 
> Freddie Cash pointed out:
>  > Doesn't work, at least not in my quick-n-dirty testing, using the kdm4
>  > script I just posted.  If you remove the lshal checks, then the
>  > keyboard doesn't work once kdm starts.
> 
> Freddie:  If you remove the lshal checks from the kdm startup
> script, then you have to also remove the hald_start
> call from the hald startup script.  Otherwise, kdm
> will start before hald and bad things will happen
> (keyboard/mouse failures at a minimum; I get a complete
> black screen in this case).
> 
> Tim
> 
> 
-- 
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090408/efd19565/attachment.pgp