[RFC] [PATCH] Make ACPI button driver an input device

[RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

Sleep and power buttons are logically part of the keyboard, and it makes 
for them to be exposed via an input device rather than an odd file in 
/proc. This patch adds a keycode for lid switches (are we running out of 
keycodes?) and allows the button driver to register an input device.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>

diff -ur drivers/acpi.bak/button.c drivers/acpi/button.c
--- drivers/acpi.bak/button.c	2006-04-03 04:22:10 +0100
+++ a/drivers/acpi/button.c	2006-04-19 20:36:05 +0100
@@ -26,6 +26,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/input.h>
 #include <linux/types.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
@@ -102,6 +103,8 @@
 	.release = single_release,
 };
 
+static struct input_dev *input_dev;
+
 /* --------------------------------------------------------------------------
                               FS Interface (/proc)
    -------------------------------------------------------------------------- */
@@ -260,6 +263,37 @@
                                 Driver Interface
    -------------------------------------------------------------------------- */
 
+static void acpi_button_report (struct acpi_button *button)
+{
+	int keycode = 0;
+
+	ACPI_FUNCTION_TRACE("acpi_button_report");
+
+	switch(button->type) {
+	case ACPI_BUTTON_TYPE_POWER:
+	case ACPI_BUTTON_TYPE_POWERF:
+		keycode = KEY_POWER;
+		break;
+	case ACPI_BUTTON_TYPE_SLEEP:
+	case ACPI_BUTTON_TYPE_SLEEPF:
+		keycode = KEY_SLEEP;
+		break;
+	case ACPI_BUTTON_TYPE_LID:
+		keycode = KEY_LID;
+		break;
+
+	}
+
+	if (keycode) {
+		input_report_key(input_dev, keycode, 1);
+		input_sync(input_dev);
+		input_report_key(input_dev, keycode, 0);
+		input_sync(input_dev);
+	}
+
+	return_VOID;
+}
+
 static void acpi_button_notify(acpi_handle handle, u32 event, void *data)
 {
 	struct acpi_button *button = (struct acpi_button *)data;
@@ -273,6 +307,7 @@
 	case ACPI_BUTTON_NOTIFY_STATUS:
 		acpi_bus_generate_event(button->device, event,
 					++button->pushed);
+		acpi_button_report(button);		
 		break;
 	default:
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
@@ -467,6 +502,26 @@
 		return_VALUE(-ENODEV);
 	}
 
+	input_dev = input_allocate_device();
+
+	if (input_dev) {
+		int error;
+
+		input_dev->name = "ACPI button driver";
+		input_dev->phys = "acpi/input0";
+		input_dev->id.bustype = BUS_HOST;
+		input_dev->evbit[LONG(EV_KEY)] = BIT(EV_KEY);
+		set_bit(KEY_SLEEP, input_dev->keybit);
+		set_bit(KEY_POWER, input_dev->keybit);
+		set_bit(KEY_LID, input_dev->keybit);
+
+		error = input_register_device(input_dev);
+		if (error) {
+			printk(KERN_ERR "Unable to register ACPI input device\n");
+			input_free_device(input_dev);
+		}
+	}
+
 	return_VALUE(0);
 }
 
@@ -484,6 +539,9 @@
 		remove_proc_entry(ACPI_BUTTON_SUBCLASS_LID, acpi_button_dir);
 	remove_proc_entry(ACPI_BUTTON_CLASS, acpi_root_dir);
 
+	if (input_dev)
+		input_unregister_device(input_dev);
+
 	return_VOID;
 }
 
--- include/linux/input.h.bak	2006-04-19 20:47:58 +0100
+++ a/include/linux/input.h	2006-04-19 20:49:18 +0100
@@ -344,6 +344,7 @@
 #define KEY_FORWARDMAIL		233
 #define KEY_SAVE		234
 #define KEY_DOCUMENTS		235
+#define KEY_LID			237
 
 #define KEY_UNKNOWN		240

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dominik Brodowski]

On Wed, Apr 19, 2006 at 08:53:58PM +0100, Matthew Garrett wrote:
> +++ a/include/linux/input.h	2006-04-19 20:49:18 +0100
> @@ -344,6 +344,7 @@
>  #define KEY_FORWARDMAIL		233
>  #define KEY_SAVE		234
>  #define KEY_DOCUMENTS		235
> +#define KEY_LID			237

What about 236?

	Dominik

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Wed, Apr 19, 2006 at 10:04:47PM +0200, Dominik Brodowski wrote:
> On Wed, Apr 19, 2006 at 08:53:58PM +0100, Matthew Garrett wrote:
> > +++ a/include/linux/input.h	2006-04-19 20:49:18 +0100
> > @@ -344,6 +344,7 @@
> >  #define KEY_FORWARDMAIL		233
> >  #define KEY_SAVE		234
> >  #define KEY_DOCUMENTS		235
> > +#define KEY_LID			237
> 
> What about 236?

I sent a patch last month that uses 236 for KEY_BATTERY, so decided not 
to conflict with it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dmitry Torokhov]

On 4/19/06, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Wed, Apr 19, 2006 at 10:04:47PM +0200, Dominik Brodowski wrote:
> > On Wed, Apr 19, 2006 at 08:53:58PM +0100, Matthew Garrett wrote:
> > > +++ a/include/linux/input.h 2006-04-19 20:49:18 +0100
> > > @@ -344,6 +344,7 @@
> > >  #define KEY_FORWARDMAIL            233
> > >  #define KEY_SAVE           234
> > >  #define KEY_DOCUMENTS              235
> > > +#define KEY_LID                    237
> >
> > What about 236?
>
> I sent a patch last month that uses 236 for KEY_BATTERY, so decided not
> to conflict with it.
>

Yes, I still need to apply it.

Matthew, I would recommend not adding KEY_LID but using one of the
switch codes (SW_0?) for the lid.

Richard, on your handhelds what switch would be most similar to
notebook's lid? Should we alias one of the switches to SW_LID?

--
Dmitry

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Mon, Apr 24, 2006 at 10:45:31AM -0400, Dmitry Torokhov wrote:

> Matthew, I would recommend not adding KEY_LID but using one of the
> switch codes (SW_0?) for the lid.

Ok, sounds good. I'll wait to see which one seems most preferable.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Richard Purdie]

On Mon, 2006-04-24 at 10:45 -0400, Dmitry Torokhov wrote:
> Yes, I still need to apply it.
> 
> Matthew, I would recommend not adding KEY_LID but using one of the
> switch codes (SW_0?) for the lid.
> 
> Richard, on your handhelds what switch would be most similar to
> notebook's lid? Should we alias one of the switches to SW_LID?

This gets tricky as the handhelds have two "lid" switches. Pictures of
how it can fold are at http://www.dynamism.com/sl-c3000/main.shtml . To
summarise, it can be in three positions:

* Screen folded facing the keys (shut like a laptop)
* Screen open above the keyboard (like an open laptop)
* Screen folded over the keys but with the screen visible (becomes a
tablet like handheld with no keyboard)

Shut is when both switches (SW_0 and SW_1) are pressed, open is when
neither are pressed and the "no keyboard" mode has only one switch
pressed.

The final switch (SW_2) is mapped to headphone detection.

If we are going to have a KEY_LID switch, we should probably decide now
whether the switch is pressed (1) when the lid is either open or shut
otherwise things are going to get confused.

I've often wondered whether the input system could/should be used to
pass more generic events. I know my handheld has lots of other switch
like events such as MMC/SD card insertion, CF card insertion, a battery
lock switch, AC power insertion switch and USB cable detection "switch".
Most of these are currently acted on by the kernel so userspace doesn't
need to see them but some like the USB cable detection would be useful.
It could then load the user's chosen USB gadget kernel module for
example. In that case its a user choice as there is no "right" gadget
module to autoload. I'm not sure if it would be right for these to go
via the input system and last time I looked, udev wasn't able to handle
generic events like this. 

In an ideal world, given the system nature of the events, perhaps they'd
be better suited to a more generalised or specialised piece of code
based on the input system. A more general events system would mean we
could have:

EVENT_LID_SHUT
EVENT_LID_OPEN
EVENT_LID_OPEN_NOKEYBOARD

or similar which would avoid the issues associated with a single SW_LID
switch. I suspect there are no easy answers though.

Whilst sort of on the subject (AC power switches and AC power events)
I'd like to see some standard way of exporting power/battery information
to userspace. Currently, the ARM handhelds use kernel emulation of an
APM bios and export the battery info as part of that. Making ARM emulate
ACPI interfaces doesn't appeal. The answer could be a battery sysfs
class and the above system events interface but I'm open to other
suggestions.

Cheers,

Richard

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dmitry Torokhov]

On 4/24/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Mon, 2006-04-24 at 10:45 -0400, Dmitry Torokhov wrote:
> > Yes, I still need to apply it.
> >
> > Matthew, I would recommend not adding KEY_LID but using one of the
> > switch codes (SW_0?) for the lid.
> >
> > Richard, on your handhelds what switch would be most similar to
> > notebook's lid? Should we alias one of the switches to SW_LID?
>
> This gets tricky as the handhelds have two "lid" switches. Pictures of
> how it can fold are at http://www.dynamism.com/sl-c3000/main.shtml . To
> summarise, it can be in three positions:
>
> * Screen folded facing the keys (shut like a laptop)
> * Screen open above the keyboard (like an open laptop)
> * Screen folded over the keys but with the screen visible (becomes a
> tablet like handheld with no keyboard)
>
> Shut is when both switches (SW_0 and SW_1) are pressed, open is when
> neither are pressed and the "no keyboard" mode has only one switch
> pressed.
>

Ugh... I wonder if we could change SW_0 to report "comletely
shut"/"open" and SW_1 to report orientation. Then we could alias SW_0
<-> SW_LID, SW_1 <-> SW_TABLET_MODE.

> The final switch (SW_2) is mapped to headphone detection.
>

We need to start naming switches so drivers will use same constants
for similar switches.

> If we are going to have a KEY_LID switch, we should probably decide now
> whether the switch is pressed (1) when the lid is either open or shut
> otherwise things are going to get confused.
>

SW_LID please.

> I've often wondered whether the input system could/should be used to
> pass more generic events. I know my handheld has lots of other switch
> like events such as MMC/SD card insertion, CF card insertion, a battery
> lock switch, AC power insertion switch and USB cable detection "switch".
> Most of these are currently acted on by the kernel so userspace doesn't
> need to see them but some like the USB cable detection would be useful.
> It could then load the user's chosen USB gadget kernel module for
> example. In that case its a user choice as there is no "right" gadget
> module to autoload. I'm not sure if it would be right for these to go
> via the input system and last time I looked, udev wasn't able to handle
> generic events like this.
>

I don't think these belong to input system.

> In an ideal world, given the system nature of the events, perhaps they'd
> be better suited to a more generalised or specialised piece of code
> based on the input system. A more general events system would mean we
> could have:
>
> EVENT_LID_SHUT
> EVENT_LID_OPEN
> EVENT_LID_OPEN_NOKEYBOARD
>
> or similar which would avoid the issues associated with a single SW_LID
> switch. I suspect there are no easy answers though.

Bring dbus into the kernel ;) No, I think kernel should not have
"cover everythingunder the sun" interface but rather set of
specialized ones.

>
> Whilst sort of on the subject (AC power switches and AC power events)
> I'd like to see some standard way of exporting power/battery information
> to userspace. Currently, the ARM handhelds use kernel emulation of an
> APM bios and export the battery info as part of that. Making ARM emulate
> ACPI interfaces doesn't appeal. The answer could be a battery sysfs
> class and the above system events interface but I'm open to other
> suggestions.
>

Having generic battery interface would be nice.

--
Dmitry

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Richard Purdie]

On Mon, 2006-04-24 at 12:26 -0400, Dmitry Torokhov wrote:
> On 4/24/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> > This gets tricky as the handhelds have two "lid" switches. Pictures of
> > how it can fold are at http://www.dynamism.com/sl-c3000/main.shtml . To
> > summarise, it can be in three positions:
> >
> > * Screen folded facing the keys (shut like a laptop)
> > * Screen open above the keyboard (like an open laptop)
> > * Screen folded over the keys but with the screen visible (becomes a
> > tablet like handheld with no keyboard)
> >
> > Shut is when both switches (SW_0 and SW_1) are pressed, open is when
> > neither are pressed and the "no keyboard" mode has only one switch
> > pressed.
> 
> Ugh... I wonder if we could change SW_0 to report "comletely
> shut"/"open" and SW_1 to report orientation. Then we could alias SW_0
> <-> SW_LID, SW_1 <-> SW_TABLET_MODE.

I've checked which switch is which and SW_0 is equivalent to SW_LID. We
can just rename them and retain compatibility if:

SW_0/SW_LID is pressed to indicate shut
SW_1/SW_TABLET_MODE is pressed to indicate tablet mode
SW_2/SW_HEADPHONE_DETECT is pressed to indicate headphone jack insertion

I'm happy to submit a patch to make that change (and remove the as yet
unused SW_[3-7] if you like?

I realise there are arguments for having the headphone jack control
monitoring in the sound driver but this was the nicest way I've found of
passing the event to user space to deal with. I didn't want to deal with
it in the sound driver as in this case there is no right answer as to
what the sound driver should do (we can't detect if it was headphones, a
speaker + mic headset etc. or just a mic that was inserted yet we can
support all of them).

> > If we are going to have a KEY_LID switch, we should probably decide now
> > whether the switch is pressed (1) when the lid is either open or shut
> > otherwise things are going to get confused.
>
> SW_LID please.

Sorry, I did mean SW_LID.

> > I've often wondered whether the input system could/should be used to
> > pass more generic events. I know my handheld has lots of other switch
> > like events such as MMC/SD card insertion, CF card insertion, a battery
> > lock switch, AC power insertion switch and USB cable detection "switch".
> > Most of these are currently acted on by the kernel so userspace doesn't
> > need to see them but some like the USB cable detection would be useful.
> > It could then load the user's chosen USB gadget kernel module for
> > example. In that case its a user choice as there is no "right" gadget
> > module to autoload. I'm not sure if it would be right for these to go
> > via the input system and last time I looked, udev wasn't able to handle
> > generic events like this.
> >
> 
> I don't think these belong to input system.

Yet they're arguably switches and have all the right semantics to be
reported as such. I agree they shouldn't be in the input system but
where should they be? Currently we don't need most of them but some
would be useful.

> > Whilst sort of on the subject (AC power switches and AC power events)
> > I'd like to see some standard way of exporting power/battery information
> > to userspace. Currently, the ARM handhelds use kernel emulation of an
> > APM bios and export the battery info as part of that. Making ARM emulate
> > ACPI interfaces doesn't appeal. The answer could be a battery sysfs
> > class and the above system events interface but I'm open to other
> > suggestions.
> >
> 
> Having generic battery interface would be nice.

It gets tricky. AC presence isn't a property of a battery for example
and is in fact more like a switch (my handheld has a mechanical switch
to detect when its plugged in) ;). The battery class would export some
information but not all of it and I don't know where the leftover
information should go. If I knew that, I'd write the class.

Cheers,

Richard

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

Hi!

> > Ugh... I wonder if we could change SW_0 to report "comletely
> > shut"/"open" and SW_1 to report orientation. Then we could alias SW_0
> > <-> SW_LID, SW_1 <-> SW_TABLET_MODE.
> 
> I've checked which switch is which and SW_0 is equivalent to SW_LID. We
> can just rename them and retain compatibility if:
> 
> SW_0/SW_LID is pressed to indicate shut
> SW_1/SW_TABLET_MODE is pressed to indicate tablet mode
> SW_2/SW_HEADPHONE_DETECT is pressed to indicate headphone jack insertion
> 
> I'm happy to submit a patch to make that change (and remove the as yet
> unused SW_[3-7] if you like?
> 
> I realise there are arguments for having the headphone jack control
> monitoring in the sound driver but this was the nicest way I've found of
> passing the event to user space to deal with. I didn't want to deal with
> it in the sound driver as in this case there is no right answer as to
> what the sound driver should do (we can't detect if it was headphones, a
> speaker + mic headset etc. or just a mic that was inserted yet we can
> support all of them).

Well, it "headset inserted" is a kind of user button...

What is on the jack, BTW? Left headphone, right headphone, mic in? Can
all of them be used independently?

> > > Whilst sort of on the subject (AC power switches and AC power events)
> > > I'd like to see some standard way of exporting power/battery information
> > > to userspace. Currently, the ARM handhelds use kernel emulation of an
> > > APM bios and export the battery info as part of that. Making ARM emulate
> > > ACPI interfaces doesn't appeal. The answer could be a battery sysfs
> > > class and the above system events interface but I'm open to other
> > > suggestions.
> > >
> > 
> > Having generic battery interface would be nice.
> 
> It gets tricky. AC presence isn't a property of a battery for example
> and is in fact more like a switch (my handheld has a mechanical
> switch

Oops, really? Mechanical switch to sense ac in? (What happens when you
plug in charger but that is not plugged to AC?)

I think that AC presence should be handled independently from
battery. There can be >1 battery in the system.

(Another interesting question is: is AC status 0/1 or is it number of
milivolts?)

> to detect when its plugged in) ;). The battery class would export some
> information but not all of it and I don't know where the leftover
> information should go. If I knew that, I'd write the class.

Leftover information?

I think we should create directory in sysfs, and populate it according
to battery's capabilities.

Zaurus' battery would have voltage and maybe percent fields.

ACPI battery would have all the usual fields.

Another important question is a way for user applications to avoid
polling... but I guess that should be solveable by enabling select on
one of those files.
								Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Richard Purdie]

On Mon, 2006-04-24 at 22:34 +0200, Pavel Machek wrote:
> What is on the jack, BTW? Left headphone, right headphone, mic in? Can
> all of them be used independently?

> > It gets tricky. AC presence isn't a property of a battery for example
> > and is in fact more like a switch (my handheld has a mechanical
> > switch
> 
> Oops, really? Mechanical switch to sense ac in? (What happens when you
> plug in charger but that is not plugged to AC?)

Most of the Zaurus devices can measure the AC voltage and make sanity
checks on it in the SharpSL Battery/PM code.

> I think that AC presence should be handled independently from
> battery. There can be >1 battery in the system.

Agreed. This is some of the leftover information I'm referring to below.

>(Another interesting question is: is AC status 0/1 or is it number of
> milivolts?)

I'd say millivolts except for the problem of what you do on systems that
don't support voltage readings. Use a very high value I guess. For a lot
of devices millivolts also means in kernel conversion tables. Do such
things belong in kernel or user space?

> > to detect when its plugged in) ;). The battery class would export some
> > information but not all of it and I don't know where the leftover
> > information should go. If I knew that, I'd write the class.
> 
> Leftover information?

Where to put AC status and AC voltage readings amongst other things.
Another sysfs class? Also, how do you control suspend/resume
notifications to userspace if not using APM/ACPI?

> I think we should create directory in sysfs, and populate it according
> to battery's capabilities.
> 
> Zaurus' battery would have voltage and maybe percent fields.
> 
> ACPI battery would have all the usual fields.
> 
> Another important question is a way for user applications to avoid
> polling... but I guess that should be solveable by enabling select on
> one of those files.

Agreed, this is something that would be needed.

Richard

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

Hi!

> >(Another interesting question is: is AC status 0/1 or is it number of
> > milivolts?)
> 
> I'd say millivolts except for the problem of what you do on systems that
> don't support voltage readings. Use a very high value I guess. For a lot
> of devices millivolts also means in kernel conversion tables. Do such
> things belong in kernel or user space?

We should probably return 0/-1 in such case (-1 = on, but voltage unknown).

> > > to detect when its plugged in) ;). The battery class would export some
> > > information but not all of it and I don't know where the leftover
> > > information should go. If I knew that, I'd write the class.
> > 
> > Leftover information?
> 
> Where to put AC status and AC voltage readings amongst other things.
> Another sysfs class? Also, how do you control suspend/resume
> notifications to userspace if not using APM/ACPI?

I'd say that AC status should go to separate class, I'm
afraid. Potentially AC has more parameters (like current, current
frequency, difference between phase of current and voltage, ...?) and
UPSs even measure that.

Does userspace need to be notified of suspend/resume? [I keep
insisting that they do not, and I'm probably wrong, but... :-)]

								Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

Hi!

> Whilst sort of on the subject (AC power switches and AC power events)
> I'd like to see some standard way of exporting power/battery information
> to userspace. Currently, the ARM handhelds use kernel emulation of an
> APM bios and export the battery info as part of that. Making ARM emulate
> ACPI interfaces doesn't appeal. The answer could be a battery sysfs
> class and the above system events interface but I'm open to other
> suggestions.

Battery sysfs class would be _very_ welcome. Both existing interfaces
(APM and ACPI) are crap :-(.
								Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

Hi!

> Sleep and power buttons are logically part of the keyboard, and it makes 
> for them to be exposed via an input device rather than an odd file in 
> /proc. This patch adds a keycode for lid switches (are we running out of 
> keycodes?) and allows the button driver to register an input device.

Yes, please. This is actually long overdue.

								Pavel

-- 
Thanks, Sharp!

RE: [RFC] [PATCH] Make ACPI button driver an input device

[Yu, Luming]

>Sleep and power buttons are logically part of the keyboard, 
>and it makes 
>for them to be exposed via an input device rather than an odd file in 
>/proc. This patch adds a keycode for lid switches (are we 
>running out of 
>keycodes?) and allows the button driver to register an input device.

Do you plan to port the whole acpi event interface into input layer?
If so,  keycode is NOT a right way.

--Luming

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 01:45:27PM +0800, Yu, Luming wrote:

> Do you plan to port the whole acpi event interface into input layer?
> If so,  keycode is NOT a right way.

Not really, though it would be one possibility. However, the input layer 
doesn't really provide the flexibility needed for certain events. I'm 
not sure what the right answer is for other events, but I'm pretty sure 
the button driver maps onto the input layer sensibly.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Apr 20, 2006 at 01:45:27PM +0800, Yu, Luming wrote:
> 
>> Do you plan to port the whole acpi event interface into input layer?
>> If so,  keycode is NOT a right way.
> 
> Not really, though it would be one possibility. However, the input layer 
> doesn't really provide the flexibility needed for certain events. I'm 
> not sure what the right answer is for other events, but I'm pretty sure 
> the button driver maps onto the input layer sensibly.
> 
Could it be more sensible to use kevent and dbus for sending all events from ACPI?

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 07:35:53PM +0400, Alexey Starikovskiy wrote:

> Could it be more sensible to use kevent and dbus for sending all events 
> from ACPI?

For most of the events, probably. I'm less convinced by the button 
driver - sleep and power buttons can also generate keycodes rather than 
ACPI events, and so getting the button driver to behave like an input 
device adds consistency.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Apr 20, 2006 at 07:35:53PM +0400, Alexey Starikovskiy wrote:
> 
>> Could it be more sensible to use kevent and dbus for sending all events 
>> from ACPI?
> 
> For most of the events, probably. I'm less convinced by the button 
> driver - sleep and power buttons can also generate keycodes rather than 
> ACPI events, and so getting the button driver to behave like an input 
> device adds consistency.
> 
I think you will agree that ACPI buttons are special and will need special handling even in input stream...
Generic application does not need to know if power, sleep, or lid button is pressed, so you will need to intercept them from input stream... I cannot find any reason to mix these buttons into input, do you?

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Xavier Bestel]

On Thu, 2006-04-20 at 17:57, Alexey Starikovskiy wrote:
> Matthew Garrett wrote:
> > On Thu, Apr 20, 2006 at 07:35:53PM +0400, Alexey Starikovskiy wrote:
> > 
> >> Could it be more sensible to use kevent and dbus for sending all events 
> >> from ACPI?
> > 
> > For most of the events, probably. I'm less convinced by the button 
> > driver - sleep and power buttons can also generate keycodes rather than 
> > ACPI events, and so getting the button driver to behave like an input 
> > device adds consistency.
> > 
> I think you will agree that ACPI buttons are special and will need special handling even in input stream...
> Generic application does not need to know if power, sleep, or lid button is pressed, so you will need to intercept them from input stream... I cannot find any reason to mix these buttons into input, do you?

There are keyboards with power/sleep buttons. It makes sense they have
the same behavior than ACPI buttons.

	Xav

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Xavier Bestel wrote:
> There are keyboards with power/sleep buttons. It makes sense they have
> the same behavior than ACPI buttons.
Agree, make them behave like ACPI buttons -- remove them from input stream, as they do not belong there...

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 08:33:26PM +0400, Alexey Starikovskiy wrote:
> Xavier Bestel wrote:
> >There are keyboards with power/sleep buttons. It makes sense they have
> >the same behavior than ACPI buttons.
> Agree, make them behave like ACPI buttons -- remove them from input stream, 
> as they do not belong there...

Making the atkbd driver punt certain scancodes to the ACPI layer 
/really/ isn't the right answer.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Apr 20, 2006 at 08:33:26PM +0400, Alexey Starikovskiy wrote:
>> Xavier Bestel wrote:
>>> There are keyboards with power/sleep buttons. It makes sense they have
>>> the same behavior than ACPI buttons.
>> Agree, make them behave like ACPI buttons -- remove them from input stream, 
>> as they do not belong there...
> 
> Making the atkbd driver punt certain scancodes to the ACPI layer 
> /really/ isn't the right answer.
> 
Yes, this is why I mentioned using kevent and dbus before... Could it be the righter answer?

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 08:47:39PM +0400, Alexey Starikovskiy wrote:

> Yes, this is why I mentioned using kevent and dbus before... Could it be 
> the righter answer?

I think it makes sense for atkbd and usb hid power and sleep buttons to 
be treated like all other keys on those keyboard types. As a result, I 
think it makes sense for ACPI keys to behave in the same way. I wrote an 
addon for hal to take input events and put them on the system dbus some 
time ago, so that's already a solved problem.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Apr 20, 2006 at 08:47:39PM +0400, Alexey Starikovskiy wrote:
> 
>> Yes, this is why I mentioned using kevent and dbus before... Could it be 
>> the righter answer?
> 
> I think it makes sense for atkbd and usb hid power and sleep buttons to 
> be treated like all other keys on those keyboard types. As a result, I 
> think it makes sense for ACPI keys to behave in the same way. I wrote an 
> addon for hal to take input events and put them on the system dbus some 
> time ago, so that's already a solved problem.
> 
So now you can do a shortcut and send ACPI events to dbus without involving input layer and hal.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

On Thu 20-04-06 21:06:32, Alexey Starikovskiy wrote:
> Matthew Garrett wrote:
> >On Thu, Apr 20, 2006 at 08:47:39PM +0400, Alexey 
> >Starikovskiy wrote:
> >
> >>Yes, this is why I mentioned using kevent and dbus 
> >>before... Could it be the righter answer?
> >
> >I think it makes sense for atkbd and usb hid power and 
> >sleep buttons to be treated like all other keys on those 
> >keyboard types. As a result, I think it makes sense for 
> >ACPI keys to behave in the same way. I wrote an addon 
> >for hal to take input events and put them on the system 
> >dbus some time ago, so that's already a solved problem.
> >
> So now you can do a shortcut and send ACPI events to dbus 
> without involving input layer and hal.

And break handheld devices and require everyone to run dbus?

							Pavel
-- 
Thanks, Sharp!

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dmitry Torokhov]

On 4/20/06, Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com> wrote:
> Xavier Bestel wrote:
> > There are keyboards with power/sleep buttons. It makes sense they have
> > the same behavior than ACPI buttons.
> Agree, make them behave like ACPI buttons -- remove them from input stream, as they do not belong there...

What if there is no ACPI? What if I want to remap the button to do
something else? Input layer is the proper place for them.

--
Dmitry

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Xavier Bestel]

Le jeudi 20 avril 2006 à 15:30 -0400, Dmitry Torokhov a écrit :
> On 4/20/06, Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com> wrote:
> > Xavier Bestel wrote:
> > > There are keyboards with power/sleep buttons. It makes sense they have
> > > the same behavior than ACPI buttons.
> > Agree, make them behave like ACPI buttons -- remove them from input stream, as they do not belong there...
> 
> What if there is no ACPI? What if I want to remap the button to do
> something else? Input layer is the proper place for them.

Err .. that's what I meant, sorry I was not clear. Matthew's solution
looks right.

	Xav

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Xavier Bestel wrote:
> Le jeudi 20 avril 2006 à 15:30 -0400, Dmitry Torokhov a écrit :
>> On 4/20/06, Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com> wrote:
>>> Xavier Bestel wrote:
>>>> There are keyboards with power/sleep buttons. It makes sense they have
>>>> the same behavior than ACPI buttons.
>>> Agree, make them behave like ACPI buttons -- remove them from input stream, as they do not belong there...
>> What if there is no ACPI? What if I want to remap the button to do
>> something else? Input layer is the proper place for them.
> 
> Err .. that's what I meant, sorry I was not clear. Matthew's solution
> looks right.
If there is no ACPI, you don't have ACPI buttons to remap. Remapping power/lid/sleep button is not wise at least, just because you boot once with acpi=off and get unclean shutdown instead of your intended remapped keystroke.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

> >Err .. that's what I meant, sorry I was not clear. 
> >Matthew's solution
> >looks right.
> If there is no ACPI, you don't have ACPI buttons to 
> remap. Remapping power/lid/sleep button is not wise at 
> least, just because you boot once with acpi=off and get 
> unclean shutdown instead of your intended remapped 
> keystroke.

There are many machines that have no ACPI, but have power buttons and
want to use them... and map them. Not all the world is PC.
-- 
Thanks, Sharp!

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dmitry Torokhov]

On 4/21/06, Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com> wrote:
> Xavier Bestel wrote:
> > Le jeudi 20 avril 2006 à 15:30 -0400, Dmitry Torokhov a écrit :
> >> On 4/20/06, Alexey Starikovskiy <alexey_y_starikovskiy@linux.intel.com> wrote:
> >>> Xavier Bestel wrote:
> >>>> There are keyboards with power/sleep buttons. It makes sense they have
> >>>> the same behavior than ACPI buttons.
> >>> Agree, make them behave like ACPI buttons -- remove them from input stream, as they do not belong there...
> >> What if there is no ACPI? What if I want to remap the button to do
> >> something else? Input layer is the proper place for them.
> >
> > Err .. that's what I meant, sorry I was not clear. Matthew's solution
> > looks right.
> If there is no ACPI, you don't have ACPI buttons to remap. Remapping power/lid/sleep button is not wise at least, just because you boot once with acpi=off and get unclean shutdown instead of your intended remapped keystroke.
>

I can see that with power button but lid/sleep should be fine really.
And even with power button - "doctor it hurts..."

--
Dmitry

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

On Thu 20-04-06 20:33:26, Alexey Starikovskiy wrote:
> Xavier Bestel wrote:
> >There are keyboards with power/sleep buttons. It makes 
> >sense they have
> >the same behavior than ACPI buttons.
> Agree, make them behave like ACPI buttons -- remove them 
> from input stream, as they do not belong there...

So you propose to

a) break backwards compatibility

b) introduce not-yet-existing mechanism for delivering events to
userspace

when you have perfectly working interface (input) you can just use?
Not a good idea, I'd say.
-- 
Thanks, Sharp!

Re: [RFC] [PATCH] Make ACPI button driver an input device

[David Weinehall]

On Thu, Apr 20, 2006 at 08:33:26PM +0400, Alexey Starikovskiy wrote:
> Xavier Bestel wrote:
> >There are keyboards with power/sleep buttons. It makes sense they have
> >the same behavior than ACPI buttons.
> Agree, make them behave like ACPI buttons -- remove them from input stream, 
> as they do not belong there...

It's far more sane to have them as normal keys; you might want to remap
them to do something else than to suspend your machine, for instance.


Regards: David
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 07:57:01PM +0400, Alexey Starikovskiy wrote:

> I think you will agree that ACPI buttons are special and will need special 
> handling even in input stream...
> Generic application does not need to know if power, sleep, or lid button is 
> pressed, so you will need to intercept them from input stream... I cannot 
> find any reason to mix these buttons into input, do you?

On many machines, they're /already/ in the input stream. Applications 
that misbehave if they receive unknown keycodes are broken and need 
fixing in any case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Apr 20, 2006 at 07:57:01PM +0400, Alexey Starikovskiy wrote:
> 
>> I think you will agree that ACPI buttons are special and will need special 
>> handling even in input stream...
>> Generic application does not need to know if power, sleep, or lid button is 
>> pressed, so you will need to intercept them from input stream... I cannot 
>> find any reason to mix these buttons into input, do you?
> 
> On many machines, they're /already/ in the input stream. Applications 
> that misbehave if they receive unknown keycodes are broken and need 
> fixing in any case.
> 
I don't quite understand your point... You want all buttons/switches in a computer to send events to input layer, regardless if this make sense or not, just to be consistent? May be you should go other way around and  if keyboard has some strange key, send it on its strange way? 

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 08:28:02PM +0400, Alexey Starikovskiy wrote:

> I don't quite understand your point... You want all buttons/switches in a 
> computer to send events to input layer, regardless if this make sense or 
> not, just to be consistent? May be you should go other way around and  if 
> keyboard has some strange key, send it on its strange way? 

There's a reason that KEY_POWER and KEY_SLEEP are already present in 
/usr/include/linux/input.h. It makes sense to expose keys that are on my 
keyboard in the same way as other keys on my keyboard. Just think of the 
ACPI events interface as a bus that a small keyboard with not many keys 
sits on.

>From the userspace point of view, it's *far* easier to deal with this 
stuff if the keys generate keycodes.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Apr 20, 2006 at 08:28:02PM +0400, Alexey Starikovskiy wrote:
> 
>> I don't quite understand your point... You want all buttons/switches in a 
>> computer to send events to input layer, regardless if this make sense or 
>> not, just to be consistent? May be you should go other way around and  if 
>> keyboard has some strange key, send it on its strange way? 
> 
> There's a reason that KEY_POWER and KEY_SLEEP are already present in 
> /usr/include/linux/input.h. It makes sense to expose keys that are on my 
> keyboard in the same way as other keys on my keyboard. Just think of the 
> ACPI events interface as a bus that a small keyboard with not many keys 
> sits on.
> 
>>From the userspace point of view, it's *far* easier to deal with this 
> stuff if the keys generate keycodes.
Lid is a _switch_ with state, how many keys on keyboard have same behavior? Do you want to introduce special case just for that?
 

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Thu, Apr 20, 2006 at 08:35:28PM +0400, Alexey Starikovskiy wrote:

> Lid is a _switch_ with state, how many keys on keyboard have same behavior? 
> Do you want to introduce special case just for that?

All keys have state, and that's something that's exposed via the input 
layer right now. On the other hand, it's not something that's exposed by 
my patch - however, that's easily fixed.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

On Thu 20-04-06 20:35:28, Alexey Starikovskiy wrote:
> Matthew Garrett wrote:
> >On Thu, Apr 20, 2006 at 08:28:02PM +0400, Alexey 
> >Starikovskiy wrote:
> >
> >>I don't quite understand your point... You want all 
> >>buttons/switches in a computer to send events to input 
> >>layer, regardless if this make sense or not, just to be 
> >>consistent? May be you should go other way around and  
> >>if keyboard has some strange key, send it on its 
> >>strange way? 
> >
> >There's a reason that KEY_POWER and KEY_SLEEP are 
> >already present in /usr/include/linux/input.h. It makes 
> >sense to expose keys that are on my keyboard in the same 
> >way as other keys on my keyboard. Just think of the ACPI 
> >events interface as a bus that a small keyboard with not 
> >many keys sits on.
> >
> >>From the userspace point of view, it's *far* easier to 
> >>deal with this 
> >stuff if the keys generate keycodes.
> Lid is a _switch_ with state, how many keys on keyboard 
> have same behavior? Do you want to introduce special case 
> just for that?

It is already there. Handhelds have lid switches controlled by input.
Old capslock keys (around XT era) actually worked like that, too.
(And input was actually _designed_ to handle them).
						Pavel
-- 
Thanks, Sharp!

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Martin Mares]

Hello!

> Generic application does not need to know if power, sleep, or lid button is 
> pressed, so you will need to intercept them from input stream... I cannot 
> find any reason to mix these buttons into input, do you?

Neither does a generic application need to know if the NumLock key is just
pressed. This doesn't mean anything.

I don't see any reason for treating some keys or buttons differently.
A key is just a key.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Q: How many alchemists does it take to change a light bulb?  A: Into what?

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Martin Mares wrote:
> Hello!
> 
>> Generic application does not need to know if power, sleep, or lid button is 
>> pressed, so you will need to intercept them from input stream... I cannot 
>> find any reason to mix these buttons into input, do you?
> 
> Neither does a generic application need to know if the NumLock key is just
> pressed. This doesn't mean anything.
> 
> I don't see any reason for treating some keys or buttons differently.
> A key is just a key.
> 
> 				Have a nice fortnight
There is one special key anyway -- reset...

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

On Thu 20-04-06 21:08:48, Alexey Starikovskiy wrote:
> Martin Mares wrote:
> >Hello!
> >
> >>Generic application does not need to know if power, 
> >>sleep, or lid button is pressed, so you will need to 
> >>intercept them from input stream... I cannot find any 
> >>reason to mix these buttons into input, do you?
> >
> >Neither does a generic application need to know if the 
> >NumLock key is just
> >pressed. This doesn't mean anything.
> >
> >I don't see any reason for treating some keys or buttons 
> >differently.
> >A key is just a key.

> There is one special key anyway -- reset...

Your point is? There's also hardware power button on many machines.
They are not controllable by software => they are not relevant to this
discussion.
								Pavel

-- 
Thanks, Sharp!

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Pavel Machek wrote:
>>> I don't see any reason for treating some keys or buttons 
>>> differently.
>>> A key is just a key.
> 
>> There is one special key anyway -- reset...
> 
> Your point is? There's also hardware power button on many machines.
> They are not controllable by software => they are not relevant to this
> discussion.
> 								Pavel
> 
Really? And you are what are you going to do with bugs about "my power button doesn't remap, and always shuts down my machine?"

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

On Po 24-04-06 10:54:23, Alexey Starikovskiy wrote:
> Pavel Machek wrote:
> >>>I don't see any reason for treating some keys or buttons 
> >>>differently.
> >>>A key is just a key.
> >
> >>There is one special key anyway -- reset...
> >
> >Your point is? There's also hardware power button on many machines.
> >They are not controllable by software => they are not relevant to this
> >discussion.
> >
> Really? And you are what are you going to do with bugs about "my power 
> button doesn't remap, and always shuts down my machine?"

If they have hardware power button, I'll laugh at them (then
CLOSE/INVALID). Feel free to reassign such bugs to me.

Anyway stripping useful functinality because very old (386-era!)
machines don't support it is not a way to go.
								Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Alexey Starikovskiy]

Pavel Machek wrote:
> On Po 24-04-06 10:54:23, Alexey Starikovskiy wrote:
>> Pavel Machek wrote:
>>>>> I don't see any reason for treating some keys or buttons 
>>>>> differently.
>>>>> A key is just a key.
>>>> There is one special key anyway -- reset...
>>> Your point is? There's also hardware power button on many machines.
>>> They are not controllable by software => they are not relevant to this
>>> discussion.
>>>
>> Really? And you are what are you going to do with bugs about "my power 
>> button doesn't remap, and always shuts down my machine?"
> 
> If they have hardware power button, I'll laugh at them (then
> CLOSE/INVALID). Feel free to reassign such bugs to me.
> 
> Anyway stripping useful functinality because very old (386-era!)
> machines don't support it is not a way to go.
> 								Pavel
Any new machine will have this same functionality if booted with acpi=off,ht etc, and this is done automatically on recent SUSE installs.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Matthew Garrett]

On Mon, Apr 24, 2006 at 06:39:12PM +0400, Alexey Starikovskiy wrote:

> Any new machine will have this same functionality if booted with 
> acpi=off,ht etc, and this is done automatically on recent SUSE installs.

Machines booted without acpi will have different functionality to 
machines booted with acpi. That's a feature, not a bug.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Stefan Seyfried]

On Mon, Apr 24, 2006 at 06:39:12PM +0400, Alexey Starikovskiy wrote:
> Any new machine will have this same functionality if booted with 
> acpi=off,ht etc, and this is done automatically on recent SUSE installs.

I am doing many "recent SUSE" installs and have not seen one where a
acpi=.. line was present without the user doing something strange.
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen

RE: [RFC] [PATCH] Make ACPI button driver an input device

[Yu, Luming]

>> > There are keyboards with power/sleep buttons. It makes 
>sense they have
>> > the same behavior than ACPI buttons.
>> Agree, make them behave like ACPI buttons -- remove them 
>from input stream, as they do not belong there...
>
>What if there is no ACPI? What if I want to remap the button to do
>something else? Input layer is the proper place for them.

If you define input layer as a universe place to all manual input 
activity, then I agree to port some type of ACPI event into
input layer.  But it shouldn't be a fake keyboard scancode,
My suggestion is to have a separate input event type,e.g. EV_ACPI
for acpi event layer.

>
>--
>Dmitry

Thanks,
Luming

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Pavel Machek]

Hi!

> >> > There are keyboards with power/sleep buttons. It makes 
> >sense they have
> >> > the same behavior than ACPI buttons.
> >> Agree, make them behave like ACPI buttons -- remove them 
> >from input stream, as they do not belong there...
> >
> >What if there is no ACPI? What if I want to remap the button to do
> >something else? Input layer is the proper place for them.
> 
> If you define input layer as a universe place to all manual input 
> activity, then I agree to port some type of ACPI event into
> input layer.  But it shouldn't be a fake keyboard scancode,
> My suggestion is to have a separate input event type,e.g. EV_ACPI
> for acpi event layer.

There's nothing fake about it. Power button is just that - a button.
Having EV_ACPI might make sense for thermal/battery events, but not
for normal keys.

-- 
Thanks, Sharp!

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dmitry Torokhov]

On 4/20/06, Pavel Machek <pavel@ucw.cz> wrote:
> Having EV_ACPI might make sense for thermal/battery events, but not
> for normal keys.

No, I do not want EV_ACPI at all. If it does not map to standard
key/button/switch abstraction it really does not belong in input
layer. There could be a "battery" or "power" layers providing
abstraction for ACPI/APM/whateverfor that kind of stuff, but not input
layer.

But KEY_SLEEP, KEY_POWER, etc are more than welcome.

--
Dmitry

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Martin Mares]

Hello!

> If you define input layer as a universe place to all manual input 
> activity, then I agree to port some type of ACPI event into
> input layer.  But it shouldn't be a fake keyboard scancode,
> My suggestion is to have a separate input event type,e.g. EV_ACPI
> for acpi event layer.

But why should be a ACPI suspend button treated so differently
from a button with the same label on a normal keyboard?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Linux vs. Windows is a no-WIN situation.

Re: [RFC] [PATCH] Make ACPI button driver an input device

[Dmitry Torokhov]

On 4/21/06, Yu, Luming <luming.yu@intel.com> wrote:
> >> > There are keyboards with power/sleep buttons. It makes
> >sense they have
> >> > the same behavior than ACPI buttons.
> >> Agree, make them behave like ACPI buttons -- remove them
> >from input stream, as they do not belong there...
> >
> >What if there is no ACPI? What if I want to remap the button to do
> >something else? Input layer is the proper place for them.
>
> If you define input layer as a universe place to all manual input
> activity,

Yes. If something is related to input it should be integrated into input layer.

> then I agree to port some type of ACPI event into
> input layer.  But it shouldn't be a fake keyboard scancode,
> My suggestion is to have a separate input event type,e.g. EV_ACPI
> for acpi event layer.
>

The point is that it is not a fake scancode. There are keyboards that
have these keys that don't have anything to do with ACPI. That's why
they belong to input layer. The same goes for lid switch - we have
EV_SW that is used by some PDAs.

Note that I am not saying that other ACPI events, like battery status
or device insertion/removal, should be propagated through input layer.
But things that exist even without ACPI should not be ACPI-specific.

--
Dmitry

RE: [RFC] [PATCH] Make ACPI button driver an input device

[Yu, Luming]

>> >> > There are keyboards with power/sleep buttons. It makes
>> >sense they have
>> >> > the same behavior than ACPI buttons.
>> >> Agree, make them behave like ACPI buttons -- remove them
>> >from input stream, as they do not belong there...
>> >
>> >What if there is no ACPI? What if I want to remap the button to do
>> >something else? Input layer is the proper place for them.
>>
>> If you define input layer as a universe place to all manual input
>> activity,
>
>Yes. If something is related to input it should be integrated 
>into input layer.

Yes, it sounds reasonable. Then, at least, the user space Apps can
rely on a single interface, and don't need to know the implementation  
details for the common input event. That will save a lot of support
effort. 

>
>> then I agree to port some type of ACPI event into
>> input layer.  But it shouldn't be a fake keyboard scancode,
>> My suggestion is to have a separate input event type,e.g. EV_ACPI
>> for acpi event layer.
>>
>
>The point is that it is not a fake scancode. There are keyboards that
>have these keys that don't have anything to do with ACPI. That's why
>they belong to input layer. The same goes for lid switch - we have
>EV_SW that is used by some PDAs.

ok.

>
>Note that I am not saying that other ACPI events, like battery status
>or device insertion/removal, should be propagated through input layer.
>But things that exist even without ACPI should not be ACPI-specific.
>

I'm NOT sure if it is reasonable to propagate other ACPI events 
through input layer.  But from my understanding, Laptop with ACPI
features 
should be the super class of PDA. It would be nice to have input layer
handle all ACPI events. Then, we can enjoy the advantage of a single 
input interface for user Apps.

--Luming