Ash Milsted wrote: > On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote: >> Ash Milsted wrote: >>> On 24/10/2007, Ash Milsted <[EMAIL PROTECTED]> wrote: >>>> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
