Hi Rafael,
Hopefully this will clear things a bit.
1. Why is this patch needed ?
Consider the following scenario.
1. User left the device idle for some time.
2. A deamon in the userland that controls suspend policy might
suspend the device. The lid is still open.
3. Now the use
On Thu, Jun 7, 2018 at 1:11 AM, Benson Leung wrote:
> Hi Rafael,
>
> On Wed, Jun 06, 2018 at 09:00:43AM +0200, Rafael J. Wysocki wrote:
>> > @@ -417,6 +414,7 @@ static void acpi_button_notify(struct acpi_device
>> > *device, u32 event)
>> > /* fall through */
>> > case ACP
Hi Rafael,
On Wed, Jun 06, 2018 at 09:00:43AM +0200, Rafael J. Wysocki wrote:
> > @@ -417,6 +414,7 @@ static void acpi_button_notify(struct acpi_device
> > *device, u32 event)
> > /* fall through */
> > case ACPI_BUTTON_NOTIFY_STATUS:
> > input = button->in
On Mon, Jun 4, 2018 at 8:26 PM, Ravi Chandra Sadineni
wrote:
> Currently ACPI LID increments wakeup count irrespective of the wake source.
> This is because we call acpi_lid_initialize_state on every resume.
I don't quite understand the connection between the two sentences
above. Care to clarify
On Mon, Jun 04, 2018 at 11:26:12AM -0700, Ravi Chandra Sadineni wrote:
> Currently ACPI LID increments wakeup count irrespective of the wake source.
> This is because we call acpi_lid_initialize_state on every resume.
> Userland deamons using wakeup_count to identify the potential wake
> source for
Currently ACPI LID increments wakeup count irrespective of the wake source.
This is because we call acpi_lid_initialize_state on every resume.
Userland deamons using wakeup_count to identify the potential wake
source for the last wake will be thrown off by this. Instead increment
the wakeup count o
6 matches
Mail list logo