1i5t5.duncan at cox
May 16, 2010, 2:09 AM
Post #3 of 3
Nikos Chantziaras posted on Sun, 16 May 2010 10:52:33 +0300 as excerpted:
> On 05/16/2010 10:42 AM, Leonid Podolny wrote:
>> While merging x11-base/xorg-server-1.8.1 I encountered the following
>> Usage of hal is strongly discouraged. Please migrate to udev.
>> From next major release on the hal support will be fully disabled.
>> Both hal and udev flags are enabled.
>> Enabling only udev!
>> I guess that the message above speaks only about the HAL dependency of
>> the Xorg itself, i.e. it doesn't mean that general usage of HAL at the
>> system is discouraged/deprecated. Obviously, KDE depends pretty heavily
>> on HAL.
>> Is it correct?
> Correct. This refers only to X itself. Everything else is still free
> to use HAL. To avoid the warning, simply disable the "hal" USE flag for
> x11-base/xorg-server only.
Absolutely correct with current kde (4.4.x). Over the medium term, it too
will likely be dropping hal, in favor of udev and various other helpers,
as hal itself is deprecated and not getting new development, only minimal
support of current features until there has been some time to switch away
Hal is now considered a dead-end, a hotplugging experiment that was a good
first start and from which the various developers and users learned a lot,
but which was proven far too complex and hard to maintain over the longer
And, based on the hal vs new hotplugging config in xorg, I must say I
agree. I had occasion to have to edit hal's XML based *.fdi files by
hand, and while it was possible for me as a tech-head Gentoo user to get
my head around enough to get working, the experience wasn't pleasant by a
long shot. The new xorg config, back in traditional xorg format, is
**FAR** easier, the more so because my Logitech keyboard with its extra
keys was detected without me even having to do anything at all, not even
setting the model number as I did pre-hal to get them working properly.
udev config files as well, are **WAY** easier to modify by hand when
necessary, than hal's XML/FDI files, and I expect that will continue to be
the case with pretty much the whole hal replacement, as one of the reasons
they decided hal didn't work was because asking end users to edit XML
files and get it right was just considered too much, and what with all the
new products constantly coming out, it was found to be simply unrealistic
to try to have the distributions keep up with it themselves.
So I'm definitely looking forward to the day hal isn't needed for any of
that automation, any longer, as I too expect it to be a far better and
simpler situation than hal ever was, or ever could be.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman