kernel-2.6.33.3-85.fc13.x86_64 $ sudo evtest /dev/input/event0 Input driver version is 1.0.0 Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0 Input device name: "Lid Switch" Supported events: Event type 0 (Sync) Event type 5 (?) Event code 0 (?) Testing ... (interrupt to exit) Event: time 1273424988.764554, type 5 (?), code 0 (?), value 1 Event: time 1273424988.764572, -------------- Report Sync ------------ Event: time 1273424991.980589, type 5 (?), code 0 (?), value 0 Event: time 1273424991.980605, -------------- Report Sync ------------ This happens when closing and then opening the lid. And my system fails to suspend when I close the lid, as expected.
For me this isn't a blocker, it doesn't hit anything on the criteria and it's not really a critical function. Though obviously it's an inconvenience and we should fix it ASAP, I'd be happy with it going out as an update. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 590521 has been marked as a duplicate of this bug. ***
The dupe bug 590521 has a hardware profile from one sufferer of this bug: http://www.smolts.org/client/show/pub_efe3df8e-c410-4ae1-974b-4f8956e3a79e Rodd, Bastien, can you please say what hardware you're using? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
FWIW, this system - a Thinkpad X40 - does *not* suffer the bug. Setting it to suspend on lid close, with kernel -85, it does try to suspend when the lid is closed.
On my laptop, Dell Latitude E5400, with F13 RC2 also I don't see this bug.
My machine is a Macbook Air first gen (MacbookAir1,1). It regressed from earlier kernels though I don't have them at hand to test anymore.
Do you happen to remember which was the last kernel that worked? That'd help narrow it down.
There isn't supposed to be a keycode for the lid. It sends a switch event, which is event type 5, event code 0. The evtest output shows that correctly switching between state 0 and 1. So I think the kernel is fine here.
on my working laptop, I get exactly the same (well, minus timestamps, obviously) evtest output, FWIW.
jlaska agrees this is not a blocker, taking off the list. if anyone really disagrees, please add it again and we'll discuss at the go/no-go tomorrow.
Probably a upower bug: TI:20:12:50 FI:up-input.c FN:up_input_event_io,133 - event.value=1 ; event.code=0 (0x00) TI:20:12:50 FI:up-daemon.c FN:up_daemon_set_lid_is_closed,686 - lid_is_closed = no TI:20:12:50 FI:up-input.c FN:up_input_event_io,133 - event.value=0 ; event.code=0 (0x00) TI:20:12:50 FI:up-input.c FN:up_input_event_io,137 - not a switch event TI:20:12:52 FI:up-input.c FN:up_input_event_io,133 - event.value=0 ; event.code=0 (0x00) TI:20:12:52 FI:up-daemon.c FN:up_daemon_set_lid_is_closed,686 - lid_is_closed = yes TI:20:12:52 FI:up-input.c FN:up_input_event_io,133 - event.value=0 ; event.code=0 (0x00) TI:20:12:52 FI:up-input.c FN:up_input_event_io,137 - not a switch event That's closing and reopening the lid. And gnome-power-manager doesn't seem to receive events...
udev-151-9.fc13.x86_64 gnome-power-manager-2.30.1-1.fc13.x86_64
Regression from upower-0.9.12 upower 0.9.13 is broken.
*** This bug has been marked as a duplicate of bug 590090 ***