On 25/10/2007, Ash Milsted <thatistosayiseenem@xxxxxxxxx> wrote: > On 24/10/2007, Alexey Starikovskiy <aystarik@xxxxxxxxx> wrote: > > Ash Milsted wrote: > > > On 24/10/2007, Alexey Starikovskiy <aystarik@xxxxxxxxx> wrote: > > >> 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. > > > I can confirm that this function is *not* called as the battery > (dis)charges (having seen charge_now fall), but is called on > power-plug events. Sorry... I mean it appears to be called on module-insertion and then *never* again (not on plug events). - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
