HAL: Difference between revisions

(One intermediate revision by the same user not shown)

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.

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!

@@ 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.
 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!

Dank (talk | contribs)