[arch-general] sleep + lid events + kde => new problem
Using fully updated testing repo - starting 'recently' - I notice that lid close no longer sleeps my laptop. Kde power is configured to sleep on lid close. If i click the menu and choose sleep manually - it sleeps fine - and subsequently wakes fine on lid-open. I can confirm with this little shell loop (left running and then close lid and reopen) that acpi shows lid is indeed closed: while [[ 1 == 1 ]]
do cat /proc/acpi/button/lid/*/state sleep 1 done state: open state: open state: open state: open state: closed state: closed state: closed state: closed state: open state: open
So, it -seems- as if lid-event is not being passed along for some reason to the (kde) power management - or not being listened to. I have not yet switched to systemd - and I'm not sure which process is responsible for such events. It still happens with 3.5.4 kernel if that makes any difference. It is a W520 lenovo laptop. Anyone else notice similar - or can offer suggestions? Thanks. gene/
On Mon, Sep 17, 2012 at 3:11 PM, Genes MailLists <lists@sapience.com> wrote:
Using fully updated testing repo - starting 'recently' - I notice that lid close no longer sleeps my laptop.
Kde power is configured to sleep on lid close. If i click the menu and choose sleep manually - it sleeps fine - and subsequently wakes fine on lid-open.
I can confirm with this little shell loop (left running and then close lid and reopen) that acpi shows lid is indeed closed:
while [[ 1 == 1 ]]
do cat /proc/acpi/button/lid/*/state sleep 1 done state: open state: open state: open state: open state: closed state: closed state: closed state: closed state: open state: open
So, it -seems- as if lid-event is not being passed along for some reason to the (kde) power management - or not being listened to.
I have not yet switched to systemd - and I'm not sure which process is responsible for such events.
It still happens with 3.5.4 kernel if that makes any difference.
It is a W520 lenovo laptop.
Anyone else notice similar - or can offer suggestions?
Thanks.
Does running acpi_listen and closing then reopening the lid gives an indication that the lid open/close is being seen - just to check if there is any switch failure? -- mike c
I can confirm this, I started seeing this behavior about 2 months ago. But in my case, it sometimes work, and sometimes doesn't whereas it used to work flawlessly before. --Héctor Acosta On Mon, Sep 17, 2012 at 10:13 AM, mike cloaked <mike.cloaked@gmail.com> wrote:
On Mon, Sep 17, 2012 at 3:11 PM, Genes MailLists <lists@sapience.com> wrote:
Using fully updated testing repo - starting 'recently' - I notice that lid close no longer sleeps my laptop.
Kde power is configured to sleep on lid close. If i click the menu and choose sleep manually - it sleeps fine - and subsequently wakes fine on lid-open.
I can confirm with this little shell loop (left running and then close lid and reopen) that acpi shows lid is indeed closed:
while [[ 1 == 1 ]]
do cat /proc/acpi/button/lid/*/state sleep 1 done state: open state: open state: open state: open state: closed state: closed state: closed state: closed state: open state: open
So, it -seems- as if lid-event is not being passed along for some reason to the (kde) power management - or not being listened to.
I have not yet switched to systemd - and I'm not sure which process is responsible for such events.
It still happens with 3.5.4 kernel if that makes any difference.
It is a W520 lenovo laptop.
Anyone else notice similar - or can offer suggestions?
Thanks.
Does running acpi_listen and closing then reopening the lid gives an indication that the lid open/close is being seen - just to check if there is any switch failure?
-- mike c
On 09/17/2012 11:13 AM, mike cloaked wrote:
Does running acpi_listen and closing then reopening the lid gives an indication that the lid open/close is being seen - just to check if there is any switch failure?
Tried this - I note that acpid was not running and it is needed for acpi_listen - so I started it - closed lid and re-opened. (laptop did not sleep after starting acpid either). acpi_listen then reports: % acpi_listen button/lid LID close button/lid LID open gene/
Seems other events have stopped being processed as well - e.g. unplugging a/c and going to battery - laptop beeps - but screen no longer dims - Again - I can dim screen by hand by doing something like this: echo '11' > /sys/class/backlight/acpi_video0/brightness This has been flaky a while but usually worked at least some of the time - now its just not working period. I wonder if udev responsible for this? Looks like I upgraded systemd at the end of last month to 189-4 ... seems unlikely it took me till last weekend to notice this .. but I can be slow at times :-) kde had a bunch of updates sep 4 (4.9.0 to 4.9.1).. again a week or so back If anyone has suggestions how to get these working again would be appreciated .. not fatal as I can do everything by hand but since things used to work be ncie to get them working again. gene
On Mon, Sep 17, 2012 at 10:21 PM, Genes MailLists <lists@sapience.com> wrote:
unplugging a/c and going to battery - laptop beeps - but screen no longer dims -
Again - I can dim screen by hand by doing something like this:
echo '11' > /sys/class/backlight/acpi_video0/brightness
This has been flaky a while but usually worked at least some of the time - now its just not working period.
Good tip, didn't knew about it. In my particular case I need to add acpi_backlight=vendor to the kernel line in order to be able to control screen bright with the fn+function keys combination (only in KDE SC, this don't work in dwm or Awesome), may be you can try this to solve your problem.
On Tue, Sep 18, 2012 at 2:21 AM, Genes MailLists <lists@sapience.com> wrote:
Seems other events have stopped being processed as well - e.g.
unplugging a/c and going to battery - laptop beeps - but screen no longer dims -
Again - I can dim screen by hand by doing something like this:
echo '11' > /sys/class/backlight/acpi_video0/brightness
This has been flaky a while but usually worked at least some of the time - now its just not working period.
I wonder if udev responsible for this? Looks like I upgraded systemd at the end of last month to 189-4 ... seems unlikely it took me till last weekend to notice this .. but I can be slow at times :-)
kde had a bunch of updates sep 4 (4.9.0 to 4.9.1).. again a week or so back
If anyone has suggestions how to get these working again would be appreciated .. not fatal as I can do everything by hand but since things used to work be ncie to get them working again.
gene
Any chance you may have a setting that could be changed in the KDE power management settings window to get this working again? -- mike c
On 09/21/2012 10:39 AM, mike cloaked wrote:
Any chance you may have a setting that could be changed in the KDE power management settings window to get this working again?
Spot on - in the KDE power management - there was a section called 'activities' - it was selected - deselecting and instead choosing 'dont do anything special' .. fixed the issue .. All is well!! I don't recall changing this but either it was the big kde update or I did so accidently and was not aware ... Thanks! gene/
On Fri, Sep 21, 2012 at 4:15 PM, Genes MailLists <lists@sapience.com> wrote:
On 09/21/2012 10:39 AM, mike cloaked wrote:
All is well!!
Did you mean All Izz Well!? http://www.youtube.com/watch?v=S-LltgOtFSg (from the movie "Three Idiots", a very great one) I love Bollywood!
On Sat, Sep 22, 2012 at 9:03 AM, Martín Cigorraga <msx@archlinux.us> wrote:
All is well!!
Did you mean All Izz Well!? http://www.youtube.com/watch?v=S-LltgOtFSg (from the movie "Three Idiots", a very great one) I love Bollywood!
Oh well! :-) -- ------------------------------------------------------- Cheers Jayesh Vinay Badwaik Electronics and Communication Engineering VNIT, INDIA -
participants (5)
-
Genes MailLists
-
hector acosta
-
Jayesh Badwaik
-
Martín Cigorraga
-
mike cloaked