Re: xorg loops

 Does anyone understand the method the putting Xorg's keyboard
and mouse configuration in HAL? The only thing I can figure
is its some kind of hot-plug support for keymaps. I guess I
do not understand the point because it seams as though these
items are physically connected with a screen, and may as well
be static configured. It seams to me as though everyone has
become over enamored with dynamic configuration in general. I kind
of prefer a static configuration for the permanently configuration
of a system. It seams that this results in faster boot, better and
more consistent error messages when the expected configuration
is not found. I think this X input fiasco really illustrates what I mean.

Additionally, hald is currently not nearly robust enough to count on
as much as we are now. On my system hald and GEOM have conspired
to not only lose both original and back up copies of important data
by "automagically" and incorrectly mounting disks not intended to be
mounted. In addition, it falls over if volume labels are not as expected.
Both hald and GEOM do not behave well if labels are not as expected.
Hal tends to dumb core, GEOM seams to like to get into a state where
all of the tools fail with "unexpected error", making it very difficult to fix.

One of my disks is particularly problematic in that it normally has a UFS
label. But every once and a while, the UFS label is corrupted (see hald
doing unwanted mounts) in which case GEOM decides that there is a
msdosfs label with some binary value. This binary label then almost certainly
confuses HAL. Windows doesnt see the disk because the partition type
is 165.

Its not that I expect stuff to work with corrupt data, but central system tools
like hald and GEOM need to be robust enough to report errors and keep
providing service. Not dump core and interfering with other functions of the system.
Right now, the misidentified UFS fileystem is causing access to hal to hang for
30 seconds, then report an error. This causes Xorg and? components of
gnome to start very slow, then fail. Here is what lshal produces:

nat% lshal
*** [DIE] lshal.c:dump_devices():285 : Couldn't obtain list of devices

Stuff found in my log.

Apr? 7 08:11:39 nat hald[1482]: 08:11:39.486 [I] hald.c:108: Added device to GDL; udi=/org/freedesktop/Hal/devices/volume_part2_size_81956657664
Apr? 7 08:11:39 nat hald[1482]: 08:11:39.486 [W] device.c:215: Property has invalid UTF-8 string '/dev/msdosfs/M-^[^U\xe9M-^O\xfeuO\xbexM-^M\xed', it was changed to: '/dev/msdosfs/?^U???uO?x??'
Apr? 7 08:11:39 nat hald[1482]: 08:11:39.486 [W] hf-block.c:49: unable to stat /dev/msdosfs/?^U???uO?x??: No such file or directory
Apr? 7 08:11:39 nat hald[1482]: 08:11:39.496 [I] hald.c:108: Added device to GDL; udi=/org/freedesktop/Hal/devices/volume_part2_size_81956657664_block

Note that this disk had a UFS filesystem on it, not dosfs.

Enough ranting for now, but bottom line, I think we nay be moving towards too
much mysterious complicated automatic configuration. It is starting to feel as
though we are starting to emulate some of the worst features of windows.
Automatic is not necessarily better, even if it gets it right. When wrong its
a disaster.

-Charles


-----Original Message-----
From: Robert Noland <rnoland_at_FreeBSD.org>
To: Alex Dupre <ale_at_FreeBSD.org>
Cc: freebsd-current_at_freebsd.org
Sent: Tue, 7 Apr 2009 11:41 am
Subject: Re: xorg loops










On Tue, 2009-04-07 at 15:38 +0200, Alex Dupre wrote:
> Robert Noland ha scritto:
> > hald should work fine with moused now.  
> 
> As you wrote in the UPDATING:
> 
> "Use of AllowEmptyInput should no longer
>   be needed for most users and moused should now work fine."
> 
> I think "most" != "all" users, in fact my current up-to-date workstation 
> still needs AllowEmptyInput to work. hal-device doesn't list any mouse 
> at all. Is there anything I can do to help improving the situation?

The root of the issue is that there are just too many ways to configure
input devices... Particularly mice.  Marcus, jkim and I have tried to
make accommodations for all of the cases, but it gets rather tricky.
Users can have mice configured using psm0, ums0, (serial even), moused
and we have to be able to figure out if they are statically configured
in X or not, based on whether or not X has already opened one of the
file descriptors.  Based on analyzing all of that, we decide whether or
not to advertise to X that it should attach the device.

If you are using moused, then hald *should* recognize that and
advertise /dev/sysmouse to X.  Additional input devices, get added via
moused and hald knows that /dev/sysmouse is already opened by X, so it
shouldn't re-advertise the same port again.

We desperately need to simplify our input layer, but I'm not certain
exactly what the right answer is.

robert.

-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD