You are not logged in.
Pages: 1
Hello fellow Archers,
Several weeks ago my laptop stopped handling lid close event. I wasn't concerned back then since the patch could be delivered any day. However, now it just annoys me. I discovered that the lid event is not handled even though my laptop turns off the screen (so hardware is good I guess). I tried closing and opening the lid during running the following piece of bash script
# while [ 1 ] do cat /proc/acpi/button/lid/*/state; sleep 1; done
with default systemd/logind.conf (all commented out) and with the following one
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
LidSwitchIgnoreInhibited=no
#IdleAction=ignore
#IdleActionSec=30min
always with the same result:
state: open
Any help in making my lid usable would be appreciated.
Offline
thread refresh
Offline
thread refresh
I have a similar issue, except mine detects the first event (the first close), but then it never changes the state from closed.
The hardware is good as well, since the screen gets turned off.
Even if the causes are different, there should be a way to debug this that is common to both, so any suggestions would be appreciated.
My post about the issue:
https://bbs.archlinux.org/viewtopic.php?id=173280
Offline
I can post my wife's login.d once I get back from work. Lid close works for her each time without problems.
I am posting this here, so I remember to get back to this thread later
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
I don't think the problem is with login.d.
The event that the lid state has changed is not detected by the software, so the handler isn't even called (which is from my understanding what login.d sets).
I'm not sure where the event is supposed to be detected though.
Maybe it's a proprietary signal for some reason? Or the event detector has some bug that makes it ignore future signals?
Offline
robin92 wrote:thread refresh
I have a similar issue, except mine detects the first event (the first close), but then it never changes the state from closed.
The hardware is good as well, since the screen gets turned off.
Even if the causes are different, there should be a way to debug this that is common to both, so any suggestions would be appreciated.My post about the issue:
https://bbs.archlinux.org/viewtopic.php?id=173280
I had simillar issue with my thinkpad after I started to use arch. The close event worked well, but sometimes when I opened the lid it blinked and keeped off. Then I discovered that when I increase the brightness with FN key it actually *wakes up*. I solved this with acpi_osi=Linux and acpi_backlight=vendor in the kernel parameters now it sometimes blinks but immediately turns on instead of off. Anothe tip for you could be using some Xorg backlight options. Try and you'll see.
Offline
rgomes wrote:robin92 wrote:thread refresh
I have a similar issue, except mine detects the first event (the first close), but then it never changes the state from closed.
The hardware is good as well, since the screen gets turned off.
Even if the causes are different, there should be a way to debug this that is common to both, so any suggestions would be appreciated.My post about the issue:
https://bbs.archlinux.org/viewtopic.php?id=173280I had simillar issue with my thinkpad after I started to use arch. The close event worked well, but sometimes when I opened the lid it blinked and keeped off. Then I discovered that when I increase the brightness with FN key it actually *wakes up*. I solved this with acpi_osi=Linux and acpi_backlight=vendor in the kernel parameters now it sometimes blinks but immediately turns on instead of off. Anothe tip for you could be using some Xorg backlight options. Try and you'll see.
I have tried those options before with no result I don't actually have the problem you describe: wake works well, the problem is, it doesn't actually close the LID more than once (the problem is not wake from suspend)!
You are describing something that I experience sporadically, I think: the backlight goes down enough that it seems there is no image on the screen (if you have enough ambient light, you actually see a very dim picture), so it would "wake up" by increasing the brightness.
My FN keys also don't work, right now I have backlight control mapped to something else.
Offline
I had simillar issue with my thinkpad after I started to use arch. The close event worked well, but sometimes when I opened the lid it blinked and keeped off. Then I discovered that when I increase the brightness with FN key it actually *wakes up*. I solved this with acpi_osi=Linux and acpi_backlight=vendor in the kernel parameters now it sometimes blinks but immediately turns on instead of off. Anothe tip for you could be using some Xorg backlight options. Try and you'll see.
Just tried this and it doesn't work. Well, frankly speaking I think that my issue is related to the Cinnamon 2 because I'm almost sure that lid close is not handled since that update (not 100% sure, though). I'm gonna try installing another DE and post results here.
Last edited by robin92 (2013-12-15 09:43:11)
Offline
Well, frankly speaking I think that my issue is related to the Cinnamon 2 because I'm almost sure that lid close is not handled since that update (not 100% sure, though). I'm gonna try installing another DE and post results here.
Changed to XFCE4 and still the same issue. No idea what to do next. The strange thing is that it used to work just nice.
Offline
Pages: 1