public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Richard Hughes <hughsient@gmail.com>
Cc: Len Brown <lenb@kernel.org>, Dmitry Torokhov <dtor@insightbb.com>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	linux-input <linux-input@atrey.karlin.mff.cuni.cz>,
	Kay Sievers <kay.sievers@vrfy.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [patch] Refresh lid state on resume
Date: Mon, 30 Jul 2007 17:21:30 +0200	[thread overview]
Message-ID: <1185808891.18821.25.camel@queen.suse.de> (raw)
In-Reply-To: <1184670921.8890.2.camel@work>

On Tue, 2007-07-17 at 12:15 +0100, Richard Hughes wrote:
> 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 inline (and also attached) forces a check of the lid status in the
> resume handler.
Is this a general problem on all machines?
Or does this only happen if "shutdown" suspend mode is used?
AFAIK AML code (only on some machines? or only in suspend functions
which are not invoked in shutdown mode?) checks for LID state change and
invokes a notify(LID0,0x80) (or similar).
If this only happens in shutdown mode then IMO this is not needed ->
working around a workaround makes not much sense.
I could imagine a lot machines let it up to OS to check for LID state
change, then this one should be added.

Thanks,

    Thomas

> 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;

  reply	other threads:[~2007-07-30 15:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-17 11:15 [patch] Refresh lid state on resume Richard Hughes
2007-07-30 15:21 ` Thomas Renninger [this message]
2007-07-30 15:33   ` Richard Hughes
2007-07-31  9:08     ` Rafael J. Wysocki
2007-07-31  9:07       ` Richard Hughes
2007-07-31 10:42         ` Thomas Renninger
2007-07-31 13:18           ` Richard Hughes
2007-07-31 13:42           ` Rafael J. Wysocki
2007-07-31 14:26             ` [PATCH] Enable GPEs before _WAK is called Thomas Renninger
2007-07-31 15:09               ` Rafael J. Wysocki
2007-07-31 12:53       ` [patch] Refresh lid state on resume Henrique de Moraes Holschuh

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=1185808891.18821.25.camel@queen.suse.de \
    --to=trenn@suse.de \
    --cc=dtor@insightbb.com \
    --cc=hughsient@gmail.com \
    --cc=kay.sievers@vrfy.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=rjw@sisk.pl \
    /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