Bug 110951

Summary:	Laptop Lid status (/proc/acpi/button/lid/LID0/state) on Razer Blade QHD+ 2015 remains on "closed" after first use.
Product:	ACPI	Reporter:	David J. Goehrig (dave)
Component:	Power-Sleep-Wake	Assignee:	Zhang Rui (rui.zhang)
Status:	CLOSED INSUFFICIENT_DATA
Severity:	normal	CC:	aaron.lu, kobrient, lenb, rui.zhang, vic.fryzel, yu.c.chen
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	4.1.13	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	patch to work around buggy bios export dmi info quirk to provide the cached lid state for broken bios acpidump of New Razer Blade Stealth 4K

Description David J. Goehrig 2016-01-18 01:22:40 UTC

Created attachment 200311 [details]
patch to work around buggy bios

The Razer Blade QHD+ 2015 exhibits similar problems to the bug:

https://bugzilla.kernel.org/show_bug.cgi?id=89211

wherein the 

acpi_evaluate_integer(device->handle, "_LID", NULL, &state);

call always populates state with a 0 after the lid has been closed once.

It appears to be a BIOS bug, as it is not updating the _LID state, but is notifying the i915 (GFX0) of the _WAK event.

The acpi_button_notify function is invoked each time the lid is closed, but acpi_button_resume call to acpi_lid_send_state call on wakeup only sends a state of 0 (closed) because the value of state is always 0 after it is closed.

The attached patch works around this mirroring the patch in 89211 with some modifications to limit it to only the RAZER vendor.

I currently have this working with SteamOS brewmaster (based on Debian Jessie) with systemd correctly suspending and resuming the machine.  As this relies upon the system being suspended when the lid is closed, it will result in an incorrect state should the system resume with the lid closed.

On a side note, as far as I can tell, acpi_lid_open is not being invoked in

drivers/gpu/drm/i915/intel_lvds.c

in intel_lid_notify, but I don't know if it should.

Comment 1 Aaron Lu 2016-02-01 05:24:37 UTC

Hi Yu,

What's the plan of the LID patch metioned in bug #89211?

Comment 2 Chen Yu 2016-02-01 05:30:43 UTC

I'm planning to send the patch out before Chinese new year. David, do you mind my sending the patch include your fix for Razer Blade QHD+? if not, can you please apply this patch and provide your dmi info, thanks.

Comment 3 Chen Yu 2016-02-01 05:31:49 UTC

Created attachment 202561 [details]
export dmi info

Comment 4 Chen Yu 2016-02-01 12:25:12 UTC

Created attachment 202611 [details]
quirk to provide the cached lid state for broken bios

Hi David,
I have one question, why in your patch:
return !!state;
in acpi_button_state_seq_show
isn't _LID unreliable? why not return cache_state instead?

besides can you help test if this patch work for you? you can append
acpi_button=cache_lid in cmdline to enable the quirk.
thx

Comment 5 Chen Yu 2016-02-14 06:31:40 UTC

David, the latest patch for Surface is at https://patchwork.kernel.org/patch/8200351/
hope it helpful for you, and if you are planning to send a patch for Razer Blade QHD+ 2015, please send it to acpi maillist and CCed me as well.
thanks.

Comment 6 Zhang Rui 2016-05-15 11:09:26 UTC

please attach the acpidump output.

Comment 7 Zhang Rui 2016-06-20 02:30:15 UTC

ping...

Comment 8 Zhang Rui 2016-06-27 05:46:59 UTC

bug closed as there is no response from the bug reporter.
Please feel free to reopen it if you can provide the information requested.

Comment 9 Vic Fryzel 2016-11-18 08:35:33 UTC

Created attachment 245021 [details]
acpidump of New Razer Blade Stealth 4K

Comment 10 Vic Fryzel 2016-11-18 08:36:01 UTC

I've attached the acpidump output for a New Razer Blade Stealth 4K, which exhibits this exact same behavior (never resetting lid state to open).

Comment 11 Vic Fryzel 2016-11-18 08:37:33 UTC

For what it's worth, this behavior is still present in 4.8.8 and 4.9.0-rc5.

Comment 12 kobrient 2016-11-18 21:11:39 UTC

(In reply to Vic Fryzel from comment #10)
> I've attached the acpidump output for a New Razer Blade Stealth 4K, which
> exhibits this exact same behavior (never resetting lid state to open).

I filed a new bug on this issue after noticing this one was closed.
https://bugzilla.kernel.org/show_bug.cgi?id=187271
Feel free to watch that one for updates as well.