Michael Biebl a écrit : > Yves-Alexis Perez wrote: >> On mer., 2009-11-11 at 16:49 +0100, Michael Biebl wrote: >>> I think only the devices named input* are relevant (9 to go). Then >>> test each of >>> them if it has a capabilities/sw file. >>> >>> What do you get if you run >>> cd /sys/class/input >>> for i in `seq 0 8`; do >>> cat input$i/capabilites/sw >>> done >> cor...@hidalgo: for i in `seq 0 8`; do >> for> cat input$i/capabilites/sw >> for> done >> cat: input0/capabilites/sw: No such file or directory >> cat: input1/capabilites/sw: No such file or directory >> cat: input2/capabilites/sw: No such file or directory >> cat: input3/capabilites/sw: No such file or directory >> cat: input4/capabilites/sw: No such file or directory >> cat: input5/capabilites/sw: No such file or directory >> cat: input6/capabilites/sw: No such file or directory >> cat: input7/capabilites/sw: No such file or directory >> cat: input8/capabilites/sw: No such file or directory >> cor...@hidalgo: find /sys/class/input -name sw > > That won't work as find does not seem to follow symlinks. > find /sys/ -name sw is likely more successfull > >> This is on debian 2.6.31: >> Linux hidalgo 2.6.31-1-amd64 #1 SMP Sat Oct 24 17:50:31 UTC 2009 x86_64 >> GNU/Linux >> >> So I guess “something” doesn't report the LID input. What puzzles me is >> that it's a ThinkPad, which is vastly used by Linux people, so I would >> expect that kind of stuff to be present if it's the way to go. >> >> Though, iirc, LID events are reported using event4: >> >> /dev/input/event4 >> bustype : BUS_HOST >> vendor : 0x0 >> product : 0x5 >> version : 0 >> name : "Lid Switch" >> phys : "PNP0C0D/button/input0" >> bits ev : EV_SYN EV_SW >> > > I'm honestly not 100% sure if it's a DK-power issue or not. Mind to > forward/file > this bug upstream and ask for clarification? > It doesn't look like a Debian specific issue so is best handled upstream > anyways. >
Hmhm, this morning I started to have problems with hal. It wouldn't detect the lid close events (in lshal -m). I didn't suspend in a while so it may be since last hal upgrade. Restarting hal wouldn't work, so I suspended using Fn+F4, which worked. Now, after resume, I restarted X just to check if it wouldn't changed anything else, and X didn't found any input device (which it takes from hal at the moment). I tried to restart hal again, to restart dbus, just in case, but it didn't work either. So, in the end, I tried to reboot, and now: - input are detected in xorg; - lid events are detected in hal; - lid-is-present = yes in devkit-power -d; - can-hibernate = yes in devkit-power -d; So I don't really know what the problem was. I can't believe one has to restart the whole computer before hal/devkit work correctly, so it has to be something else, but I really don't know what. Sorry for the schrœdinger-like bug report... Cheers, -- Yves-Alexis -- Yves-Alexis -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
