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

From: Tim Kientzle <kientzle_at_freebsd.org>
Date: Tue, 07 Apr 2009 23:12:43 -0700
>>> 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?

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
Received on Wed Apr 08 2009 - 04:12:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC