From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 8 22:10:07 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ABD2106566B for ; Mon, 8 Sep 2008 22:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8F48FC08 for ; Mon, 8 Sep 2008 22:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m88MA7Fj051641 for ; Mon, 8 Sep 2008 22:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m88MA7DZ051637; Mon, 8 Sep 2008 22:10:07 GMT (envelope-from gnats) Date: Mon, 8 Sep 2008 22:10:07 GMT Message-Id: <200809082210.m88MA7DZ051637@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Nate Lawson Cc: Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Lawson List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 22:10:07 -0000 The following reply was made to PR kern/124223; it has been noted by GNATS. From: Nate Lawson To: Pietro Cerutti Cc: bug-followup@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: kern/124223: [acpi] [patch] acpi_battery.c -- Notify user-defined critical level via devd(8) Date: Mon, 08 Sep 2008 15:04:02 -0700 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