[rant] keeping policy in HAL
nix at esperi.org.uk
Sat Dec 6 16:26:46 PST 2008
On 1 Dec 2008, David Miller verbalised:
> A default that, btw, anti-socially totally ignores what people put
> into their xorg.conf file unless they add yet another knob. That's
> worse than a default change.
What's worse yet is that hal is the single most unstable daemon I have
*ever* run on any system I administer. My logs show that for more than
half the time over the last two years it has refused to start: it
coredumped on startup for a long time, for reasons that changed two or
three times as I tracked the development HAL in hopes of it getting
fixed, then started working, then some change in 2.6.27 made it freeze
on startup: this now seems to be fixed in the stable tree, but, still,
robust software this is not.
I didn't care enough to track any of these problems down myself because
on my fixed-hardware desktop HAL is basically a waste of memory: the
hardware doesn't change and I know what I've got. I checked enough to
make sure there was a bug reported, then moved on.
So I was... somewhat annoyed to discover that when upgrading to xserver
1.5.3 I had to add 'AllowEmptyInput false', particularly given that the
option name gives you no clue whatsoever as to why on earth this would
make the keyboard reappear, and even the git logs give no rationale. I
still have no idea why anyone would consider this behaviour desirable,
particularly if you're loading kbd but are not loading evdev.
IMHO, if the daemon isn't running at all, AllowEmptyInput should be
unnecessary, and kbd/mouse should be consulted if loaded, *whether or
not* the server was compiled with HAL support. Anything else is just
too prone to failure.
More information about the xorg