LID switch broken - does not detect open lid

rgomes · 2015-01-27 18:55:54

I am posting this again, after getting no solutions a long time ago.

I am using a Razer Blade 14" 2013 with linux-ck kernel (although I have tested in the main kernel and the issue remains).
I like to be able to close the lid to suspend. But it is not working properly.
Note: I am using
cat /proc/acpi/button/lid/LID0/state
to figure out the state of the lid.
When I start the laptop, the lid is correctly reported as open. When I first close it, the laptop goes to sleep, and when I open it again, it wakes up.
However, it is now reported as closed, although I just woke it up by opening the lid.
If I close the lid, it also does not suspend (I have to manually suspend).

I originally posted this in: https://bbs.archlinux.org/viewtopic.php?id=173280
I tried searching for similar problems, and newer topics came up, but I'm not sure what to do related to those, since the problem does not seem to be exactly the same (as in, this does not work in any kernel I have experimented with, including linux-lts). For reference, these are the topics:
https://bbs.archlinux.org/viewtopic.php?id=168361
https://bbs.archlinux.org/viewtopic.php?id=179216

Some extra details: I disabled suspend on lid switch, so I wouldn't have to rely on it, but the problem remains: even if the laptop does not suspend, the lid goes to the closed state, and stays in that state.
For most cases, this is not a big issue, except if I plug in an external screen: then my laptop's main screen becomes unusable, since it's reported as having the lid closed.
Any suggestions would be very welcome.

Thank you,
Rodrigo

rgomes · 2015-02-01 20:36:33

Bump

ewaller · 2015-02-02 00:10:24

https://wiki.archlinux.org/index.php/Fo … te#Bumping

rgomes · 2015-02-02 19:50:37

ewaller wrote:

https://wiki.archlinux.org/index.php/Fo … te#Bumping

I apologize, I was under the impression that it was okay, as long as enough time had passed.
For extra information: this problem happens in other distros, so it seems to be a kernel problem (not a hardware problem because it works on Windows).
What steps should I take to diagnose this, or does anyone know who I should email about this?

techwiz24 · 2015-02-03 02:35:12

Are you running gnome by any chance? I noticed this crop up on my laptop over the past few days, been trying to nail down the cause... At first I thought it was gdm or x crashing, but I may be wrong now!

EDIT: Actually, my issue appears to be separate. When I switch to another TTY when the screen is frozen black, ACPI reports the lid as open. Mashing enter causes X to crash and restart sometimes, other times I have to reboot either from a TTY or with the power button. I guess I'll start my own thread...

Last edited by techwiz24 (2015-02-03 02:51:47)

ewaller · 2015-02-03 17:35:03

rgomes wrote:

I apologize, I was under the impression that it was okay, as long as enough time had passed.
For extra information: this problem happens in other distros, so it seems to be a kernel problem (not a hardware problem because it works on Windows).
What steps should I take to diagnose this, or does anyone know who I should email about this?

Yeah, I should have posed more, but I was in a hurry. We would definitely prefer that posts intended to reanimate a thread contain new information. Share what you have learned about the problem -- it demonstrates initiative by establishing that one is not just waiting around for an answer. Things like where you have searched, additional observations, new revisions of programs, etc... It just helps keep the signal to noise ratio of the forums up.

riveale · 2015-05-07 00:23:35

Haha, how goes it gomes!

Same laptop, same problem. I'm now running the vanilla ARCH 4.0 kernel and everything else works fine now (touchpad with multitouch, nvidia, bumblebee etc.). The only remaining problem is this silly lid thing. It's annoying because if you set it to "suspend" on lid close, it keeps suspending every minute or so.

Anyway, if anyone even has a workaround it would be quite useful -- I would usually use ACPI to suspend/wake up but the button is always in CLOSED position so it doesn't work. Is there some other way to detect lid close/open?

Richard

Linoman · 2015-11-03 19:22:21

Hi rgomes! Long time no seen around. I've been searching around and found this that might be worth a shot. Unfortunately I was not able to recompile the file due to errors. If you have a time to mess around with might be worth a shot.

By the way what is your expected behavior? Resume suspend? I'm looking forward always OPEN or a proper OPEN/CLOSE since connecting an extra monitor means once the lid is closed it won't turn on again.

P. S. As riveale mentioned I also changed to vanilla 4 and everything is working without much fuss.

Last edited by Linoman (2015-11-04 09:35:06)

rgomes · 2015-11-03 19:50:16

Huh, I decided to look into this again today, seems like this is still an issue with everyone.
@Linoman will look into that link, and report back
@riveale same here! So happy 4.0 fixed almost everything, just one final issue, and this is like the best Linux laptop

EDIT:
It seems there is a big roadblock to using our own DSDT table
https://bugs.archlinux.org/task/27906
It seems we might need to compile a custom kernel with a custom DSDT table

Last edited by rgomes (2015-11-03 20:14:56)

riveale · 2015-11-04 01:08:41

Wow, great find. I have little time to look into this right now but that is unfortunate that we can't bundle a custom DSDT table dynamically.

Also, I found this lovely line: (http://acpi.sourceforge.net/dsdt/index.php)
'''Further, the maintainer and the development team generally consider it a Linux bug if Windows handles an un-modified DSDT and Linux does not.'''

Linoman · 2015-11-04 10:03:35

Any ideas we can further investigate? Is there at least a way to prevent it to change to closed?

Linoman · 2015-11-05 18:40:22

Did any of you manage to get the media keys working? Under what DE?

rgomes · 2015-11-30 19:45:58

Linoman wrote:

Any ideas we can further investigate? Is there at least a way to prevent it to change to closed?

I haven't had a chance to experiment much further than my original research, unfortunately
There seems to be no way to prevent it from changing to closed.
Other than that, everything seems to work with this laptop
The best idea to investigate seems to be spending sometime recompiling kernels with custom DSDTs, and see if any of those work.

Linoman wrote:

Did any of you manage to get the media keys working? Under what DE?

It works out of the box for me in gnome.

cthulhuology · 2016-01-18 00:32:30

I have a patch that makes suspend work on the 4.1.13 kernel

https://github.com/cthulhuology/razer-lid-patch

Basically the issue is that DSDT on the Razer Blade 14" only sends the lid notice on lid close, and on _WAK notifies the i915 of the opening, but doesn't reset the internal variable for lid state.

The patch tacks the lid state and exploits the resume and suspend events that are triggered by the kernel waking from sleep (driven by the i915).

NB: this patch checks for RAZER in the vendor flag, and should be safe for non-Razer laptops.

rgomes · 2016-01-20 08:32:32

Thank you for the patch
It seems to have limited functionality, though My setup currently has the screen not triggering a suspend. When I open it up, after no suspend, it still reports it as closed. It reports it as open when I come back from a suspend. It also seems to crash a lot when I have an external monitor, which was the main reason for me needing a good detection of closed/open (not sure if the crashes are due to your patch or other stuff).
It seems that the newer kernels introduced a regression that breaks our ability to suspend (it hangs when trying to suspend)
A git bisect shows that this commit is the issue:

commit 0925636042170e0b6716cd86635899c5f4258f69
Author: Andrew Duggan <aduggan@synaptics.com>
Date: Mon Jul 6 16:48:31 2015 -0700

HID: rmi: Disable scanning if the device is not a wake source

It seems our old friend the touchpad is back with new issues.
I'm investigating where the issue might be, but if anyone has a need to use this, just reverting this commit should fix the issue.

Last edited by rgomes (2016-01-20 10:38:05)

rgomes · 2016-01-20 09:25:27

Upon further investigation, it seems that the touchpad is just not responding, or causing a read/write to it to fail when we start suspending.
The quick and easy fix is to just disable rmi_suspend:
https://github.com/Cynary/linux/commit/master
If you want a patch:
https://github.com/Cynary/linux/commit/master.patch
EDIT: It seems resume is also kind of broken, so I disabled those too, which were added in the same problem-causing commit.
(note that this patch is not safe for other laptops, as it will disable some powersaving features. Nevertheless those features have only been available since fairly recently).
I contacted the maintainers, hopefully a better fix will show itself, and go upstream.

Last edited by rgomes (2016-01-20 19:05:33)

Linoman · 2016-01-20 11:29:59

@rgomes

Pardon my ignorance but I have no idea how to apply said patch or how to look for it on google. Can you hand some pointers?

Last edited by Linoman (2016-01-20 11:58:18)

rgomes · 2016-01-20 18:48:02

@Linoman
No worries, it was a daunting task the first time I did it!
The main source of information is here:
https://wiki.archlinux.org/index.php/Kernels
For applying a patch, the simplest way will be to compile from the Arch Build System, you can find more info on that here:
https://wiki.archlinux.org/index.php/Ke … ild_System
Specifically, you download the ABS image, and then all you have to do is modify PKGBUILD to acquire the patch file, and apply it (I added the patch file to the list of file dependencies, and added a patch -Np1 ... right next to where the other patches were applied - I'd recommend just searching around the PKGBUILD document for what it does with the 0001-....patch file that is already part of the package).
It does seem the patch is incomplete The screen opening patch wasn't working for me (again it only works when I try to get back from sleep), and the suspension is doing weird stuff - it doesn't come back from sleep if I try to wake it up when opening the screen (which I forgot to test at 5AM yesterday ). I will work on my patch a bit more to see if it gets anywhere, but it seems that the LID switch patch needs more work too

Linoman · 2016-01-21 12:24:20

@rgomes

Thanks man, yesterday I've spent most of the time compiling my own kernel for the first time! I've never had to do it in my years using arch. I manage to compile it succesfully but the lid state remained broken. I've added the patch the same way the patch change-default-console-loglevel.patch was being applied.

I see you edited your second last comment with a new patch. I will try to add it. I'll comeback and report.

P.S. My kernel compilation time was around 2 hours. What can be safely skimmped from the config (either editing the file or the GUI menus) to accelerate this since we're using the same model?

Last edited by Linoman (2016-01-21 12:35:03)

Linoman · 2016-01-21 14:15:17

rgomes wrote:

The quick and easy fix is to just disable rmi_suspend:
https://github.com/Cynary/linux/commit/master
If you want a patch:
https://github.com/Cynary/linux/commit/master.patch

So I applied both patches and no dice. Lid state remains broken.

Is there a patch I can make just to keep the LID_STATE to open all the time?

ewaller · 2016-01-21 14:55:43

What happens (as an experiment for now) if you sudo rmmod button
Note that you may loose the power button ACPI functionality, but let's see if this isolates the lid switch.

rgomes · 2016-01-27 23:28:08

Good news: a patch to the mainstream kernel with a cleaner fix for the suspend issue is getting pushed, so it should be fixed in arch soon (from the emails, it should be applied on 4.5, for those interested: https://www.mail-archive.com/linux-kern … 60615.html )
If I do sudo rmmod button, I get the following error:

rmmod: ERROR: Module button is in use by: i915

And I can't remove i915

Last edited by rgomes (2016-01-27 23:28:25)

Linoman · 2016-01-28 09:14:11

rgomes wrote:

Good news: a patch to the mainstream kernel with a cleaner fix for the suspend issue is getting pushed, so it should be fixed in arch soon (from the emails, it should be applied on 4.5, for those interested: https://www.mail-archive.com/linux-kern … 60615.html )

Kudos rgomes outstanding job. Can the patch be applied to test it?

phcerdan · 2016-01-29 00:54:00

Thanks a lot rgomes! I am also interested in applying the patch.

rgomes · 2016-01-31 05:20:45

You can apply the patch, and it will work.
Follow the instructions in my previous post (#18), and google can probably help a lot. I will help, but need more specific questions.

Arch Linux

#1 2015-01-27 18:55:54

LID switch broken - does not detect open lid

#2 2015-02-01 20:36:33

Re: LID switch broken - does not detect open lid

#3 2015-02-02 00:10:24

Re: LID switch broken - does not detect open lid

#4 2015-02-02 19:50:37

Re: LID switch broken - does not detect open lid

#5 2015-02-03 02:35:12

Re: LID switch broken - does not detect open lid

#6 2015-02-03 17:35:03

Re: LID switch broken - does not detect open lid

#7 2015-05-07 00:23:35

Re: LID switch broken - does not detect open lid

#8 2015-11-03 19:22:21

Re: LID switch broken - does not detect open lid

#9 2015-11-03 19:50:16

Re: LID switch broken - does not detect open lid

#10 2015-11-04 01:08:41

Re: LID switch broken - does not detect open lid

#11 2015-11-04 10:03:35

Re: LID switch broken - does not detect open lid

#12 2015-11-05 18:40:22

Re: LID switch broken - does not detect open lid

#13 2015-11-30 19:45:58

Re: LID switch broken - does not detect open lid

#14 2016-01-18 00:32:30

Re: LID switch broken - does not detect open lid

#15 2016-01-20 08:32:32

Re: LID switch broken - does not detect open lid

#16 2016-01-20 09:25:27

Re: LID switch broken - does not detect open lid

#17 2016-01-20 11:29:59

Re: LID switch broken - does not detect open lid

#18 2016-01-20 18:48:02

Re: LID switch broken - does not detect open lid

#19 2016-01-21 12:24:20

Re: LID switch broken - does not detect open lid

#20 2016-01-21 14:15:17

Re: LID switch broken - does not detect open lid

#21 2016-01-21 14:55:43

Re: LID switch broken - does not detect open lid

#22 2016-01-27 23:28:08

Re: LID switch broken - does not detect open lid

#23 2016-01-28 09:14:11

Re: LID switch broken - does not detect open lid

#24 2016-01-29 00:54:00

Re: LID switch broken - does not detect open lid

#25 2016-01-31 05:20:45

Re: LID switch broken - does not detect open lid

Board footer