Check out my first novel, midnight's simulacra!

HAL: Difference between revisions

From dankwiki
No edit summary
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
* Exciting news! Ubuntu 10.04 (Lucid Lynx Alpha 2, whatever that indicates) has [http://www.ubuntu.com/testing/lucid/alpha2 dropped HAL]! Our long dark night might soon be over. Hopefully [[Debian]] will follow.
It's good to possess a thorough understanding of [[udev]] and [[sysfs]] before messing with HAL.
It's good to possess a thorough understanding of [[udev]] and [[sysfs]] before messing with HAL.


Why on earth does [[Xorg hell|X]] require HAL as of late? See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515214 bug 515214]...
Why on earth does [[Xorg hell|X]] require HAL as of late? See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515214 bug 515214]...
<pre>Note that this is the direction that upstream is heading in. The design
is conceptually quite simple. The X server asks the system, in this case
via hal, to enumerate input devices are present and gets them enumerated
back. It then utilizes that hardware via the kernel rather than driving
them itself with its own drivers. Note that this system was designed and
implemented by a Nokia employee for an embedded system. It brings an
enormous simplification to the overall operating system by putting
things like keymaps in one place, and only having the kernel driving the
hardware rather than both the kernel and the X server. It also makes it
flexible with system changes, allowing hotplugging. Most importantly to
Debian and the XSF, it means that we don't have to carry around a
gigantic horrible bunch of shell script just to configure the system.
All of this is a good thing.
If you object to having the X server depend on external software, you're
going to have to learn to like it, because the goal has been to decrease
the amount of OS code that the server needs to duplicate in order to do
its job. It no longer scans the PCI bus itself, but instead relies on
libpciaccess to query the OS. It no longer carries its own build system,
but relies on autotools. All of the video drivers are moving significant
portions of themselves in to the kernel as well. If you can't deal with
hal, then you'll have to write a replacement for it that allows the
server to query the system in a transparent way, and also allows one to
easily configure device-specific properties. This is something that hal
currently does very well and the X server can not do otherwise.
All of that said, it's very likely that we will downgrade the depends to
recommends, just not right now. We have actual important bugs like
totally broken installs that we want to deal with first.
- David Nusinow</pre>
So it goes!

Latest revision as of 21:46, 17 January 2010

  • Exciting news! Ubuntu 10.04 (Lucid Lynx Alpha 2, whatever that indicates) has dropped HAL! Our long dark night might soon be over. Hopefully Debian will follow.

It's good to possess a thorough understanding of udev and sysfs before messing with HAL.

Why on earth does X require HAL as of late? See bug 515214...

Note that this is the direction that upstream is heading in. The design 
is conceptually quite simple. The X server asks the system, in this case 
via hal, to enumerate input devices are present and gets them enumerated 
back. It then utilizes that hardware via the kernel rather than driving 
them itself with its own drivers. Note that this system was designed and 
implemented by a Nokia employee for an embedded system. It brings an 
enormous simplification to the overall operating system by putting 
things like keymaps in one place, and only having the kernel driving the 
hardware rather than both the kernel and the X server. It also makes it 
flexible with system changes, allowing hotplugging. Most importantly to 
Debian and the XSF, it means that we don't have to carry around a 
gigantic horrible bunch of shell script just to configure the system. 
All of this is a good thing.

If you object to having the X server depend on external software, you're 
going to have to learn to like it, because the goal has been to decrease 
the amount of OS code that the server needs to duplicate in order to do 
its job. It no longer scans the PCI bus itself, but instead relies on 
libpciaccess to query the OS. It no longer carries its own build system, 
but relies on autotools. All of the video drivers are moving significant 
portions of themselves in to the kernel as well. If you can't deal with 
hal, then you'll have to write a replacement for it that allows the 
server to query the system in a transparent way, and also allows one to 
easily configure device-specific properties. This is something that hal 
currently does very well and the X server can not do otherwise.

All of that said, it's very likely that we will downgrade the depends to 
recommends, just not right now. We have actual important bugs like 
totally broken installs that we want to deal with first.

- David Nusinow

So it goes!