On Monday 09 January 2006 11:27, Matthew Garrett wrote: > On Mon, Jan 09, 2006 at 11:13:15AM +0800, Yu Luming wrote: > > Comparing with generic hotkey solution, dev_acpi solution cannot prevent > > any trouble in terms of supportability, and manageability. > > > > For dev_acpi, you won't need kernel patch. But you need to know > > everything in AML world from user space. > > We need to know that in any case. The difference is that in the kernel > case, adding support for new hotkeys requires upgrading the kernel. In >From practical point of view, the acpi hotkey won't change for a quite long period. For example, I cannot find too much changes on acpi hotkey from Thinkpad T21 and Thinkpad T42. And, I don't see any reason for ODM to change their well-know ACPI device PNP ID and well-know AML methods names for acpi hotkey on new platfrom, because they can just implement any platform changes in AML code. > the case of it adding a new button type that hasn't been seen before, it > also requires upgrading userspace. If we do it all in userspace, we only > have one application to fix up in most cases.
> > > PS. According to my testing, windows do have platform specific hotkey > > drivers. > > In the Windows world, vendors can provide customised distributions on a > per-laptop basis. That's not practical in the Linux world. My points is that if hotkey.c become sucessful, then linux won't need those platform specific hotkey drivers for common hotkeys such as brightness control, volume control, and output switch.. Does it make sense? Thanks, Luming - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
