GeeXboX now features HAL !!

It’s been 2 weeks since 1.2-beta1 release and results were mitigated. Some people are pretty enthusiastics as it used to worked out of the box, others were disappointed as nothing worked at all :-)

The first good news is that a lot of issues have been isolated (and hopefully fixed). There used to be breakages in installator, X.Org ATI driver (readonhd has now been dropped and replaced by the legacy one) and UPnP discovery. We have also upgraded kernel and X.Org server for a better compatibility with some GPUs and TV screen detection.

Statistically however, 95% of downloads (at least on main website, dunno about mirrors) were done against x86_32 ISO image. Geez, why did we waste time on x86_64 port if no one is using it ? I’m kinda disapointed in this area. Though, the PowerPC branch has been restored and its associated ISO will be provided for upcoming 1.2-beta2 (I don’t expect much downloads of it that said …).

Today’s point however is meant to announce that GeeXboX now support HAL, a.k.a. Hardware Abstraction Layer. X.Org is taking advantage of it through its XInput extension. Basically, that means that we do no longer provide and support the legacy X.Org keyboard and mouse drivers but evdev (Event Device) instead.

How does it work and what is it useful to ? Actually, Linux kernel provide some evdev driver that is used to detect any HID device (keyboard, mouse, touchscreen, some remote like Apple IR one) and, through udev, it notifies the hardware abstraction layer that new event devices are available. Using HAL (and the D-BUS message bus), X.Org server can automatically discover input devices and make use of them. As a result, it now support hotplug detection of input devices and do not require any configuration at all. You should now be able to plug in/out any new input device and directly use it to control the interface.

Another good news is that input drivers were the only remaining devices that needed to be probed for X.Org to work. Hence, GeeXboX used to boot in 2 steps, one starting X.Org in probe mode, generating a xorg.conf file, and then, booting X.Org for real. Now that everything is automated, the xorg.conf file do not exist anymore (i.e. X.Org can boot without it but you can still provide one if you feel the need) and boot process is faster.

Ok, I know, this still looks a bit overkill regarding current UI, especially when taking about touchscreen/mouse hotplug support but Enna will be included soon and changes will then be far different :-)

Category:

Leave a Reply