Hi,
On 20-12-2019 04:02, Jason Ekstrand wrote:
Sorry for the late reply. The e-mail got filtered and I didn't see it until now. :-(
No problem.
On Sun, Dec 8, 2019 at 8:05 AM Hans de Goede <hdegoede@xxxxxxxxxx <mailto:hdegoede@xxxxxxxxxx>> wrote:
Hi,
On 06-12-2019 18:54, Jason Ekstrand wrote:
> Running evemu-record on the lid switch event shows that the lid reports
> the first close but then never reports an open. This causes systemd to
> continuously re-suspend the laptop every 30s. Resetting the _LID to
> open fixes the issue.
Sorry to be a bit nitpicky here, but the LID does work normally right,
so it does signal an event when it gets closed a second time right.
What I observed with evemu-record is exactly what I wrote above. Without this patch, I see one LID event when I close the laptop lid the first time and never see another LID event again, either open or close.
Right, but I assume that with the fix to assume the LID is "open" on resume, that
suspending by LID does work a second (and third, etc.) time, so the LID is
sending events more then once, it just is only sending close events. Where as
your current comment and commit messages to me sound as if it only sends an
event once.
If closing the LID does properly suspend a second time, then the issue is
that it always reports close, even when queried to sync the state on resume,
so in essence the same as on the Medion Akoya E2215T, which uses the following
comment in its dmi entry:
{
/*
* Medion Akoya E2215T, notification of the LID device only
* happens on close, not on open and _LID always returns closed.
*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "MEDION"),
DMI_MATCH(DMI_PRODUCT_NAME, "E2215T MD60198"),
},
.driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
},
So assuming that I have correctly understood that the LID does suspend the
system a second time when closed a second time (and a third, etc.) then
IMHO the comment for the Razer Blade Stealth 13 late 2019 should be
something like the above comment (and idem for the commit msg).
I hope this explains better what I tried to say in my first email,
if not let me know.
Regards,
Hans
Your current commit message and comment suggest closing the LID only
works once. So perhaps something like this for the comment:
The commit message and comment are different from our IRC conversations because I updated them after running evemu-record and seeing slightly different behavior than we discussed on IRC. Our earlier conversations were based mostly on guesses from me seeing spurious suspend issues and looking at the types of ACPI bugs I'd seen reported for other machines.
--Jason
/*
* Razer Blade Stealth 13 late 2019, _LID always reports closed,
* even when opened.
*/
And adjust the comment accordingly.
Regards,
Hans
> Signed-off-by: Jason Ekstrand <jason@xxxxxxxxxxxxxx <mailto:jason@xxxxxxxxxxxxxx>>
> ---
>
> Re-sending due to a typo in my own e-mail address. :(
>
> drivers/acpi/button.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 662e07afe9a1..f7ca94e41c48 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -122,6 +122,17 @@ static const struct dmi_system_id dmi_lid_quirks[] = {
> },
> .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
> },
> + {
> + /*
> + * Razer Blade Stealth 13 late 2019, _LID reports the first
> + * close but never resets to open.
> + */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Razer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Razer Blade Stealth 13 Late 2019"),
> + },
> + .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
> + },
> {}
> };
>
>
