On Friday 18 February 2005 18:31, Pavel Machek wrote: > Hi! > > > > What is the benefit of splitting the flow of information so? > > > > It's split already. You get some from input (power and sleep keys on > > keyboards, sound volume keys and display brightness on some notebooks), > > some from ACPI events (power keys on notebooks and desktop cases, sound > > volume, display brightness on other notebooks), some from /proc/acpi/* > > (battery status, fan status), some from APM, from platform specific > > devices, from hotplug, from userspace daemons (UPS status). > > > > The question is how to unify it. > > > > Using power.c to simply pass power/sleep keys to the ACPI event pipe > > could get the input subsystem out of the loop at least. Maybe we could > > even pass sound keys to it. > > I do not think passing sound keys through acpi is good idea. acpid > does not know how to handle them, and X already know how to get them > from input subsystem.
What X? I am not saying that sound events should go through acpid, but why bringing X here? One may not even run X... > > I believe power and suspend keys should definitely go through > input. I'm not that sure about battery... Lid is somewhere in > between... > I think we need a generic way of delivering system status changes to userspace. Something like acpid but bigger than that, something not so heavily oriented on ACPI. I wonder if that kernel connector patch should be looked at. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
