On Wed, 2006-08-30 at 23:07 -0400, Dmitry Torokhov wrote:
On Wednesday 30 August 2006 23:03, Len Brown wrote:
On Wednesday 30 August 2006 22:53, Dmitry Torokhov wrote:
So... do you want me to make it work with !CONFIG_INPUT or shoudl I just
add a dependency on INPUT in Kconfig for
On 9/18/06, Richard Hughes [EMAIL PROTECTED] wrote:
On Wed, 2006-08-30 at 23:07 -0400, Dmitry Torokhov wrote:
On Wednesday 30 August 2006 23:03, Len Brown wrote:
On Wednesday 30 August 2006 22:53, Dmitry Torokhov wrote:
So... do you want me to make it work with !CONFIG_INPUT or shoudl I
On Mon, 2006-09-18 at 11:17 -0400, Dmitry Torokhov wrote:
On 9/18/06, Richard Hughes [EMAIL PROTECTED] wrote:
On Wed, 2006-08-30 at 23:07 -0400, Dmitry Torokhov wrote:
On Wednesday 30 August 2006 23:03, Len Brown wrote:
On Wednesday 30 August 2006 22:53, Dmitry Torokhov wrote:
But input layer will be a hub of sorts and I am arguing for ACPI
to be converted to use input layer directly.
What does lkml think of ACPI using the input layer directly?
I think it is a good idea.
The only question I have is how to transition.
If I replace the
On Wednesday 30 August 2006 22:53, Dmitry Torokhov wrote:
So... do you want me to make it work with !CONFIG_INPUT or shoudl I just
add a dependency on INPUT in Kconfig for button driver?
If virtually everybody uses INPUT, then I'm fine with the ACPI button driver
simply depending
on
But input layer will be a hub of sorts and I am arguing for ACPI
to be converted to use input layer directly.
What does lkml think of ACPI using the input layer directly?
I think it is a good idea.
The only question I have is how to transition.
If I replace the acpi_bus_generate_event()
On Wednesday 26 July 2006 19:41, Brown, Len wrote:
But input layer will be a hub of sorts and I am arguing for ACPI
to be converted to use input layer directly.
What does lkml think of ACPI using the input layer directly?
I think it is a good idea.
The only question I have is how
On Mon, 2006-01-09 at 00:07 -0500, Dmitry Torokhov wrote:
On Sunday 08 January 2006 20:14, Richard Hughes wrote:
On Sun, 2006-01-08 at 14:13 +, Richard Hughes wrote:
On Sun, 2006-01-08 at 13:47 +, Matthew Garrett wrote:
On Sun, Jan 08, 2006 at 12:58:44PM +, Richard Hughes
On Mon, 2006-01-09 at 01:09 -0500, Dmitry Torokhov wrote:
On Monday 09 January 2006 00:24, Matthew Garrett wrote:
On Mon, Jan 09, 2006 at 12:07:43AM -0500, Dmitry Torokhov wrote:
Why don't we create an input handler that would feed certain events
from input layer to acpid via
On Sat, 2006-01-07 at 17:24 +, Matthew Garrett wrote:
Currently, there are three ways that a sleep hotkey may generate an
event:
1) Exposed in DSDT as an ACPI object, generates an ACPI notification
event (the normal way)
2) Uses hardware-specific ACPI driver, generates an ACPI
On Sun, Jan 08, 2006 at 12:58:44PM +, Richard Hughes wrote:
Can we not go further and define Dock/UnDock,
BrightnessUp/BrightnessDown, Hibernate, etc?
BrightnessUp/BrightnessDown have keycodes defined in
/usr/src/linux/input.h, so that shouldn't be a problem. I suggested a
keycode for
On Mon, Jan 09, 2006 at 09:37:01AM +0800, Yu, Luming wrote:
The hotkey.c is NOT like what you said above.
It is used to support dedicated hotkey device and dedicated hotkey AML methods
that are used by ODM to implement hotkey function on their own laptops.
As for hotkey event, hotkey.c
Thus wrote Yu Luming:
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
On Monday 09 January 2006 15:14, Karol Kozimor wrote:
Thus wrote Yu Luming:
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
14 matches
Mail list logo
