On 25/10/2007, Ash Milsted <[EMAIL PROTECTED]> wrote:
> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
> > Ash Milsted wrote:
> > > On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
