Another change coming in 2-27 – gnome-power-manager will stop listening to HAL for button events. Peter has been rocking with evdev over the last few months and now all the multimedia buttons come up through both X and HAL. g-p-m has to filter the second button, and mostly this works well. Some distros are still not configuring evdev properly, and some still inject events into HAL, or rely on HAL to scrape events from oddball kernel interfaces. The way forward is using INPUT in the kernel, and the vast majority of events are now coming through INPUT from random devices, and through X to applications.
gnome-power-manager and buttons
Published by
hughsie
Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food. View all posts by hughsie
What about the unrecognized scancodes that are currently fed back by HAL through EVIOCSKEYCODE? I guess you’ll still get them when they come back through X. What about the issue of X not handling keycodes > 255? I think this is the right way forward, but I’m just curious.