From: Richard Hughes <hughsient@gmail.com>
To: len.brown@intel.com
Cc: Dmitry Torokhov <dtor@insightbb.com>,
linux-acpi <linux-acpi@vger.kernel.org>,
Bastien Nocera <hadess@hadess.net>,
David Zeuthen <david@fubar.dk>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: [patch] Reporting the lid status using INPUT
Date: Wed, 27 Jun 2007 20:42:25 +0100 [thread overview]
Message-ID: <1182973345.27453.9.camel@work> (raw)
In-Reply-To: <freemail.20070525224936.77205@fm01.freemail.hu>
[-- 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;
prev parent reply other threads:[~2007-06-27 19:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-15 12:29 Reporting the lid status using INPUT Richard Hughes
2007-06-15 13:12 ` [patch] " Richard Hughes
2007-06-15 14:29 ` Dmitry Torokhov
2007-06-15 14:53 ` Richard Hughes
2007-06-16 17:11 ` Richard Hughes
2007-06-16 17:51 ` Dmitry Torokhov
2007-06-24 22:06 ` GMail
2007-06-25 20:49 ` Bartók Albert
2007-06-25 21:24 ` Richard Hughes
2007-06-27 19:42 ` Richard Hughes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1182973345.27453.9.camel@work \
--to=hughsient@gmail.com \
--cc=david@fubar.dk \
--cc=dtor@insightbb.com \
--cc=hadess@hadess.net \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).