The simple tasks HAL does for us in the X server is:
- List all input devices (the equivalent to the InputDevice sections in the xorg.conf).
- Nominate the appropriate driver for each input device (the equivalent to the Driver "..." line in each InputDevice section).
- Provide user-configured extra options such as the keyboard layout (the equivalent to the Option "Foo" "bar" lines).
Note that 2 and 3 are a result of your local configuration files and not some random guesses.
So whenever it's unclear if a problem is in fact caused by HAL ask yourself: if you had a xorg.conf, could this problem be fixed by editing it? If not, then you need to report the bug against the input driver or the X server. Here's Fedora's rough checklist for reporting input bugs.
That HAL is being replaced by libudev is a completely different issue as well.
[edit]
libudev, not DeviceKit.
2 comments:
Hi Peter,
Just to let you know DeviceKit won't replace Hal, DK was just a test project but its maintainer said it's a dead-end now (but note DK-Power or DK-Disk still remain).
So hal should be replaced by libudev.
Regards
According to Kay Sievers from SUSE:
(linux hotplug mailing-list)
1."The plain DeviceKit daemon was a temporary thing until libudev/gudev
was ready to do event multiplexing. It didn't do anything substantial
but pass an udev event to multiple listeners - the same what libudev/gudev does now. The DeviceKit daemon will not be in the final setups. Only udev will provide the device events."
But this doesn't mean that component specific subsystems will disappear :
2."There are still all the subsystem specific high-level interfaces for desktop stuff. See DeviceKit-disks, DevicKit-power, NetworkManager, PulseAudio, ... - all use libudev/gudev now instead if HAL."
So I am forced now to use libudev for my project.
I still don't understand why there won't be a simple DBus interface for device hotplug signals.
Post a Comment