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
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
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
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
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 =
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 =
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
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
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
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
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
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
12 matches
Mail list logo