Date: Mon, 08 Sep 2008 15:04:02 -0700 From: Nate Lawson <nate@root.org> To: Pietro Cerutti <gahr@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Message-ID: <48C5A152.9020505@root.org> In-Reply-To: <48C59C98.5020408@FreeBSD.org> References: <48C14091.4060309@FreeBSD.org> <48C16810.2030003@root.org> <48C59C98.5020408@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Pietro Cerutti wrote:
> Nate Lawson wrote:
> | There are a few problems with your approach.
> |
> | Critical status is already reported with a flag when usermode polls for
> | the battery status:
> |> if (sc->bst.state & ACPI_BATT_STAT_CRITICAL) {
> |> if ((sc->flags & ACPI_BATT_STAT_CRITICAL) == 0) {
> |> sc->flags |= ACPI_BATT_STAT_CRITICAL;
> |> device_printf(dev, "critically low charge!\n");
> |> }
> |> }
>
> I agree. Critical level is already checked for in the cmbat module.
> However, reporting is not done in a "standardized" way. My patch would
> just like to add notification through devd.
But it doesn't just add notification through devd. It adds a thread,
that separately polls for battery state and sends a notify through devd.
If the user is running any battery app, there's a double poll for the
same info.
I subscribe to the design approach that where it makes sense to do
something in usermode, don't do it in kernel mode. In this case, the IO
interface is poll-only, and any user app that is running can set its own
policy for how to deal with the information it gets from polling.
> I agree that userlevel utilities can e.g., retrieve the remaining
> percent and set the critical level arbitrarily, but I anyway think that
> a configurable level to be seen as critical by the OS could be a useful
> addition.
>
> I'm open to discussions about the best way to implement it (cmbat,
> battery, ...?), if we get to an agreement that this could be a useful
> feature :) Otherwise feel free to close the PR, as I can accept your
> arguments.
I think it would be better to work with the third-party apps to support
configurable levels. In xbatt:
/* If battery life is short, ring a bell */
if ((life != APM_STAT_UNKNOWN) && (life < 5) && ((life % 5) == 0)) {
... and ...
/* set gage color */
if (displayType == Color) {
if (life < 3) {
gage_color = "red";
} else if (life < 5) {
gage_color = "yellow";
}
}
These thresholds could easily be a command-line var or X resource.
Let's keep this in usermode, where policy belongs.
--
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48C5A152.9020505>