Reporting the lid status using INPUT

Reporting the lid status using INPUT

[Richard Hughes]

Guys,

I'm getting a few bugreports where:

* user shuts lid, initiates suspend
{lid is reported down}
* user opens lid, resume completes

But I'm not getting any lid INPUT up event. This works if you don't
initiate suspend when you shut the lid (blank screen for instance) -- so
I know my hardware is okay.

I see:

input_report_switch(input, SW_LID, !state);

in response to an event, but I'm thinking in a resume hook we should
probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
send an event, just so userspace is aware of what the state of the panel
is.

Does this sound sane?

Richard.

[patch] Reporting the lid status using INPUT

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> in response to an event, but I'm thinking in a resume hook we should
> probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> send an event, just so userspace is aware of what the state of the panel
> is.

Attached patch fixed the issue for me. Comments?

Richard.


[-- Attachment #2: acpi-resume-lid-event.patch --]
[-- Type: text/x-patch, Size: 1535 bytes --]

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index cb4110b..3631b8f 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -68,6 +68,7 @@ MODULE_LICENSE("GPL");
 
 static int acpi_button_add(struct acpi_device *device);
 static int acpi_button_remove(struct acpi_device *device, int type);
+static int acpi_button_resume(struct acpi_device *device);
 static int acpi_button_info_open_fs(struct inode *inode, struct file *file);
 static int acpi_button_state_open_fs(struct inode *inode, struct file *file);
 
@@ -77,6 +78,7 @@ static struct acpi_driver acpi_button_driver = {
 	.ids = "button_power,button_sleep,PNP0C0D,PNP0C0C,PNP0C0E",
 	.ops = {
 		.add = acpi_button_add,
+		.resume = acpi_button_resume,
 		.remove = acpi_button_remove,
 	},
 };
@@ -487,6 +489,27 @@ static int acpi_button_remove(struct acpi_device *device, int type)
 	return 0;
 }
 
+/* this is needed to learn about changes made in suspended state */
+static int acpi_button_resume(struct acpi_device *device)
+{
+	struct acpi_button *button;
+	struct acpi_handle *handle;
+	struct input_dev *input;
+	unsigned long state;
+
+	button = device->driver_data;
+	handle = button->device->handle;
+	input = button->input;
+
+	/* on resume we send the state; it might be the same, but userspace
+	 * should handle duplicated events */
+	if (!ACPI_FAILURE(acpi_evaluate_integer(handle, "_LID",
+						NULL, &state)))
+		input_report_switch(input, SW_LID, !state);
+
+	return 0;
+}
+
 static int __init acpi_button_init(void)
 {
 	int result;

Re: [patch] Reporting the lid status using INPUT

[Dmitry Torokhov]

On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > in response to an event, but I'm thinking in a resume hook we should
> > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > send an event, just so userspace is aware of what the state of the panel
> > is.
>
> Attached patch fixed the issue for me. Comments?
>

The patch makes perfect sense. The only issue I have is this:

> +	/* on resume we send the state; it might be the same, but userspace
> +	 * should handle duplicated events */

If switch state matches to what input layer thinks it is the event
will not even reach userspace.

-- 
Dmitry

Re: [patch] Reporting the lid status using INPUT

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > in response to an event, but I'm thinking in a resume hook we should
> > > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > > send an event, just so userspace is aware of what the state of the panel
> > > is.
> >
> > Attached patch fixed the issue for me. Comments?
> >
> 
> The patch makes perfect sense. The only issue I have is this:
> 
> > +	/* on resume we send the state; it might be the same, but userspace
> > +	 * should handle duplicated events */
> 
> If switch state matches to what input layer thinks it is the event
> will not even reach userspace.

Okay, new patch attached, thanks for the speedy review.

Signed-off-by: Richard Hughes <richard@hughsie.com>


[-- Attachment #2: button-resume.patch --]
[-- Type: message/rfc822, Size: 2209 bytes --]

From: Richard Hughes <richard@hughsie.com>
Subject: No Subject
Date: Fri, 15 Jun 2007 15:53:11 +0100
Message-ID: <1181919191.2681.5.camel@work>

On resume we need to refresh the lid status as we will not get an event if
the lid opening was what triggered the suspend.
This manifests itself in users never getting a "lid open" event when a
suspend happens because of lid close on hardware that supports wake on
lid open. This makes userspace gets very confused indeed.
Patch attached forces a check of the lid status in the resume handler.

Signed-off-by: Richard Hughes <richard@hughsie.com>
---

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index cb4110b..fd3473b 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -68,6 +68,7 @@ MODULE_LICENSE("GPL");
 
 static int acpi_button_add(struct acpi_device *device);
 static int acpi_button_remove(struct acpi_device *device, int type);
+static int acpi_button_resume(struct acpi_device *device);
 static int acpi_button_info_open_fs(struct inode *inode, struct file *file);
 static int acpi_button_state_open_fs(struct inode *inode, struct file *file);
 
@@ -77,6 +78,7 @@ static struct acpi_driver acpi_button_driver = {
 	.ids = "button_power,button_sleep,PNP0C0D,PNP0C0C,PNP0C0E",
 	.ops = {
 		.add = acpi_button_add,
+		.resume = acpi_button_resume,
 		.remove = acpi_button_remove,
 	},
 };
@@ -487,6 +489,29 @@ static int acpi_button_remove(struct acpi_device *device, int type)
 	return 0;
 }
 
+/* this is needed to learn about changes made in suspended state */
+static int acpi_button_resume(struct acpi_device *device)
+{
+	struct acpi_button *button;
+	struct acpi_handle *handle;
+	struct input_dev *input;
+	unsigned long state;
+
+	button = device->driver_data;
+	handle = button->device->handle;
+	input = button->input;
+
+	/*
+	 * On resume we send the state; if it matches to what input layer
+	 * thinks then the event will not even reach userspace.
+	 */
+	if (!ACPI_FAILURE(acpi_evaluate_integer(handle, "_LID",
+						NULL, &state)))
+		input_report_switch(input, SW_LID, !state);
+
+	return 0;
+}
+
 static int __init acpi_button_init(void)
 {
 	int result;

Re: [patch] Reporting the lid status using INPUT

[Richard Hughes]

On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > > in response to an event, but I'm thinking in a resume hook we should
> > > > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > > > send an event, just so userspace is aware of what the state of the panel
> > > > is.
> > >
> > > Attached patch fixed the issue for me. Comments?
> > >
> > 
> > The patch makes perfect sense. The only issue I have is this:
> > 
> > > +	/* on resume we send the state; it might be the same, but userspace
> > > +	 * should handle duplicated events */
> > 
> > If switch state matches to what input layer thinks it is the event
> > will not even reach userspace.
> 
> Okay, new patch attached, thanks for the speedy review.

This fix is also confirmed by somebody else, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243030

It would be great if this could go into .22, although I appreciate it's
quite late in the day.

Richard.

Re: [patch] Reporting the lid status using INPUT

[Dmitry Torokhov]

On Saturday 16 June 2007 13:11, Richard Hughes wrote:
> On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> > On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > > On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> > > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > > > in response to an event, but I'm thinking in a resume hook we should
> > > > > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > > > > send an event, just so userspace is aware of what the state of the panel
> > > > > is.
> > > >
> > > > Attached patch fixed the issue for me. Comments?
> > > >
> > > 
> > > The patch makes perfect sense. The only issue I have is this:
> > > 
> > > > +	/* on resume we send the state; it might be the same, but userspace
> > > > +	 * should handle duplicated events */
> > > 
> > > If switch state matches to what input layer thinks it is the event
> > > will not even reach userspace.
> > 
> > Okay, new patch attached, thanks for the speedy review.
> 
> This fix is also confirmed by somebody else, see
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243030
> 
> It would be great if this could go into .22, although I appreciate it's
> quite late in the day.
>

This is of course Len's call but in my book this is a bugfix and as such
is appropriate for -rc4/rc5.

-- 
Dmitry

Re: [patch] Reporting the lid status using INPUT

[GMail]

On 16/06/07, Dmitry Torokhov <dtor@insightbb.com> wrote:
> On Saturday 16 June 2007 13:11, Richard Hughes wrote:
> > On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> > > On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > > > On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> > > > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > > > > in response to an event, but I'm thinking in a resume hook we should
> > > > > > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > > > > > send an event, just so userspace is aware of what the state of the panel
> > > > > > is.
> > > > >
> > > > > Attached patch fixed the issue for me. Comments?
> > > > >
> > > >
> > > > The patch makes perfect sense. The only issue I have is this:
> > > >
> > > > > +       /* on resume we send the state; it might be the same, but userspace
> > > > > +        * should handle duplicated events */
> > > >
> > > > If switch state matches to what input layer thinks it is the event
> > > > will not even reach userspace.
> > >
> > > Okay, new patch attached, thanks for the speedy review.
> >
> > This fix is also confirmed by somebody else, see
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243030
> >
> > It would be great if this could go into .22, although I appreciate it's
> > quite late in the day.
> >
>
> This is of course Len's call but in my book this is a bugfix and as such
> is appropriate for -rc4/rc5.

Guys? Any ack-nak?

Richard.

Re: [patch] Reporting the lid status using INPUT

[Bartók Albert]

GMail On 16/06/07, Dmitry Torokhov <dtor@insightbb.com> wrote:
> On Saturday 16 June 2007 13:11, Richard Hughes wrote:
> > On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> > > On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > > > On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> > > > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > > > > in response to an event, but I'm thinking in a resume hook we should
> > > > > > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > > > > > send an event, just so userspace is aware of what the state of the panel
> > > > > > is.
> > > > >
> > > > > Attached patch fixed the issue for me. Comments?
> > > > >
> > > >
> > > > The patch makes perfect sense. The only issue I have is this:
> > > >
> > > > > +       /* on resume we send the state; it might be the same, but userspace
> > > > > +        * should handle duplicated events */
> > > >
> > > > If switch state matches to what input layer thinks it is the event
> > > > will not even reach userspace.
> > >
> > > Okay, new patch attached, thanks for the speedy review.
> >
> > This fix is also confirmed by somebody else, see
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243030
> >
> > It would be great if this could go into .22, although I appreciate it's
> > quite late in the day.
> >
>
> This is of course Len's call but in my book this is a bugfix and as such
> is appropriate for -rc4/rc5.

> Guys? Any ack-nak?

works perfectly for me so far.

Albert



15% KEDVEZMÉNY minden PLASZTIKAI MŰTÉTRE az Aesthetica orvosi központban! Klikk ide!http://www.webdesign.hu/aesthetica/flash_microsite/?id=9;p_code=2079

Re: [patch] Reporting the lid status using INPUT

[Richard Hughes]

On Mon, 2007-06-25 at 22:49 +0200, Bartók Albert wrote:
> GMail On 16/06/07, Dmitry Torokhov <dtor@insightbb.com> wrote:
> > On Saturday 16 June 2007 13:11, Richard Hughes wrote:
> > > On Fri, 2007-06-15 at 15:53 +0100, Richard Hughes wrote:
> > > > On Fri, 2007-06-15 at 10:29 -0400, Dmitry Torokhov wrote:
> > > > > On 6/15/07, Richard Hughes <hughsient@gmail.com> wrote:
> > > > > > On Fri, 2007-06-15 at 13:29 +0100, Richard Hughes wrote:
> > > > > > > in response to an event, but I'm thinking in a resume hook we should
> > > > > > > probably do acpi_evaluate_integer(handle, "_LID", NULL, &state) and then
> > > > > > > send an event, just so userspace is aware of what the state of the panel
> > > > > > > is.
> > > > > >
> > > > > > Attached patch fixed the issue for me. Comments?
> > > > > >
> > > > >
> > > > > The patch makes perfect sense. The only issue I have is this:
> > > > >
> > > > > > +       /* on resume we send the state; it might be the same, but userspace
> > > > > > +        * should handle duplicated events */
> > > > >
> > > > > If switch state matches to what input layer thinks it is the event
> > > > > will not even reach userspace.
> > > >
> > > > Okay, new patch attached, thanks for the speedy review.
> > >
> > > This fix is also confirmed by somebody else, see
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243030
> > >
> > > It would be great if this could go into .22, although I appreciate it's
> > > quite late in the day.
> > >
> >
> > This is of course Len's call but in my book this is a bugfix and as such
> > is appropriate for -rc4/rc5.
> 
> > Guys? Any ack-nak?
> 
> works perfectly for me so far.

Thanks. Len, can you add this to your tree please. Thanks.

Richard.


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] Reporting the lid status using INPUT

[Richard Hughes]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

Len,

* user shuts lid, initiates suspend
{lid is reported down}
* user opens lid, resume completes

But the lid INPUT up event is not sent. This works if you don't initiate
suspend when you shut the lid (blank screen for instance) -- so I know
my hardware is okay.

I see:
input_report_switch(input, SW_LID, !state);

in response to an event, but in a resume hook we should probably do
acpi_evaluate_integer(handle, "_LID", NULL, &state) and then send an
event, just so userspace is aware of what the state of the panel is.

If switch state matches to what input layer thinks it is the event will
not be sent.

Signed-off-by: Richard Hughes <richard@hughsie.com>


[-- Attachment #2: button-resume.patch --]
[-- Type: message/rfc822, Size: 2209 bytes --]

From: Richard Hughes <richard@hughsie.com>
Subject: No Subject
Date: Fri, 15 Jun 2007 15:53:11 +0100
Message-ID: <1181919191.2681.5.camel@work>

On resume we need to refresh the lid status as we will not get an event if
the lid opening was what triggered the suspend.
This manifests itself in users never getting a "lid open" event when a
suspend happens because of lid close on hardware that supports wake on
lid open. This makes userspace gets very confused indeed.
Patch attached forces a check of the lid status in the resume handler.

Signed-off-by: Richard Hughes <richard@hughsie.com>
---

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index cb4110b..fd3473b 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -68,6 +68,7 @@ MODULE_LICENSE("GPL");
 
 static int acpi_button_add(struct acpi_device *device);
 static int acpi_button_remove(struct acpi_device *device, int type);
+static int acpi_button_resume(struct acpi_device *device);
 static int acpi_button_info_open_fs(struct inode *inode, struct file *file);
 static int acpi_button_state_open_fs(struct inode *inode, struct file *file);
 
@@ -77,6 +78,7 @@ static struct acpi_driver acpi_button_driver = {
 	.ids = "button_power,button_sleep,PNP0C0D,PNP0C0C,PNP0C0E",
 	.ops = {
 		.add = acpi_button_add,
+		.resume = acpi_button_resume,
 		.remove = acpi_button_remove,
 	},
 };
@@ -487,6 +489,29 @@ static int acpi_button_remove(struct acpi_device *device, int type)
 	return 0;
 }
 
+/* this is needed to learn about changes made in suspended state */
+static int acpi_button_resume(struct acpi_device *device)
+{
+	struct acpi_button *button;
+	struct acpi_handle *handle;
+	struct input_dev *input;
+	unsigned long state;
+
+	button = device->driver_data;
+	handle = button->device->handle;
+	input = button->input;
+
+	/*
+	 * On resume we send the state; if it matches to what input layer
+	 * thinks then the event will not even reach userspace.
+	 */
+	if (!ACPI_FAILURE(acpi_evaluate_integer(handle, "_LID",
+						NULL, &state)))
+		input_report_switch(input, SW_LID, !state);
+
+	return 0;
+}
+
 static int __init acpi_button_init(void)
 {
 	int result;