On Fri, 04 Jul 2008, Matthew Garrett wrote: > On Fri, Jul 04, 2008 at 09:22:47AM -0300, Henrique de Moraes Holschuh wrote: > > On Fri, 04 Jul 2008, Matthew Garrett wrote: > > > hal has bound to input devices for years. It won't run code directly, > > > since that's a policy decision, but lshal -m should show events come > > > from input devices. > > > > Is there an easy way to duplicate what acpid does (i.e. give HAL some config > > file that tells it to run an extrenal script when it gets a certain event)? > > If there is not, it is no wonder people don't want to go away from acpid and > > we have to keep proc_generate_event around... > > Right, that's why I'm not encouraging its removal from any existing > drivers at the moment. I was under the impression that there was an > acpid that could listen for input devices somewhere, but I'm having > trouble finding that now. Hm. Can't we add that to HAL? It is not ACPI specific, and it IS useful as all heck for 'system-wide' behaviour (otherwise one could use whatever the desktop environment's default "special key mapping" utility is). Another major extreme annoyance is the X.org evdev driver. Besides the (very unfortunate) fact that it simply doesn't work right, that thing insists on doing an exclusive grab of any input device you give it (for security reasons, I suppose), which actually means you need to handle the special input events inside X as well. Things like that make me wonder if I shouldn't be issuing the thinkpad-acpi events that are mapped to input events also over netlink. Well, I will wait until we get a proper replacement for proc-based acpid, first. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
