Re: 2.6.24-rc1 acpi battery driver -> sysfs interface does not update correctly

[Alexey Starikovskiy <aystarik@gmail.com>]

Ash Milsted wrote:
> On 24/10/2007, Alexey Starikovskiy <aystarik@gmail.com> wrote:
>> Ash Milsted wrote:
>>> On 24/10/2007, Ash Milsted <thatistosayiseenem@gawab.com> wrote:
>>>> On 24/10/2007, Alexey Starikovskiy <aystarik@gmail.com> wrote:
>>>>> Could you please test this patch?
>>>> Appears to work again  - sysfs values now seem to update correctly
>>>> without help from a proc read. Will check without ACPI_PROCFS and let
>>>> you know if anything still seems wrong.
>>>>
>>>> Ash
>>>>
>>> Okay, I have a further suspicion that uevents are not being sent as
>>> the battery charge changes. I have HAL 0.5.10 running and it only
>>> updates it's battery status if I (un)plug the power, despite cat
>>> /sys/class/power_supply/BAT1/charge_now now giving a current value.
>>>
>> This one is not easy. According to code, it should send twice as many notifications now.
>> One over netlink, and one as power_supply class device...
>> Could you log all the uevents?
>>
> Forgive my ignorance, but I'm not entirely sure how to capture
> uevents. If "udevmonitor --kernel" is sufficient then it appears there
> are no events associated with the battery discharging or charging,
> whereas those associated with (un)plugging do appear. To clarify, I've
> seen cat /sys/.../charge_now change without udevmonitor picking up a
> single kernel event.
Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c?
This is the only place which could send uevent. If you don't see this printk in
dmesg, then HAL uses some other method to get battery state changes.