[Pkg-utopia-maintainers] Bug#555740: Bug#555740: Bug#555712: Bug#555712: devicekit-power: wrong status for can-hibernate and lid-is-present

[Yves-Alexis Perez]

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 
>> corsac at 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
>> corsac at 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