Date: Mon, 17 Jul 2000 11:15:18 -0700 From: Nick Sayer <nsayer@sftw.com> To: freebsd-hackers@freebsd.org Cc: Warner Losh <imp@village.org> Subject: Re: sysctl interface for apm? Message-ID: <39734D36.5FC7DDA@sftw.com> References: <3971F574.B492B904@softweyr.com> <1884.963737703@critter.freebsd.dk> <200007171753.LAA62543@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Warner Losh wrote:
> In message <3971F574.B492B904@softweyr.com> Wes Peters writes:
> : Poul-Henning Kamp wrote:
> : >
> : > In message <200007160625.XAA92886@freefall.freebsd.org>, nsayer@FreeBSD.ORG wri
> : > tes:
> : >
> : > >So what does everyone think? Is it suitable to add a read only
> : > >sysctl 'machdep.apm_powerstate' that reports either AC, nn%,
> : > >or N/A ? Or should the format be numeric (999 = AC, <=100 = battery %,
> : > >-1 = N/A)? Or should we not bother? :-)
> : >
> : > yes it is suitable.
> :
> : Perhaps machdep.apm.powerstate, leaving room in the namespace for other
> : apm parameters? Charging state and battery life leap immediately to
> : mind.
>
> No. DO NOT CALL IT APM. APM is i386 specific and is doing its best
> to die off in favor acpi.
>
> If you must call it apm, do *NOT* cause being on AC power to override
> the batery %. These are two different things and should be reported
> as such.
>
> machdep.apm.battery: 0..100 (for battery percentage)
> machdep.apm.runtime: 0.. (for the reported battery life remaining)
> machdep.apm.ac: 0 1 (1 means we're running off AC)
> machdep.apm.charging: 0 1
> machdep.apm.batteries: 0.. (number of batteries apm says are there)
>
> But why bother? The apm command gives you this already. :-)
>
> Warner
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
The "why bother" is easy -- one should not have to belong to group
operator to determine the current battery state. Too many things
already have to be sgid (at least) without making this another reason.
I took a middle ground. I have two ints, machdep.apm_battlevel
and machdep.apm_powerstate. The power state number is
-1 to 5 for unknown, critical, low, medium, high (which four imply
battery power), AC or charging (which two imply AC power).
These patches are actually against -stable, but I will get this
into -current shortly.
Suggestions as to how to correct the errors I probably made in
the sysctl interface are welcome. :-)
[-- Attachment #2 --]
--- apm.c.orig Tue Feb 8 12:39:18 2000
+++ apm.c Mon Jul 17 10:47:13 2000
@@ -107,6 +107,65 @@
SYSCTL_INT(_machdep, OID_AUTO, apm_suspend_delay, CTLFLAG_RW, &apm_suspend_delay, 1, "");
SYSCTL_INT(_machdep, OID_AUTO, apm_standby_delay, CTLFLAG_RW, &apm_standby_delay, 1, "");
+static int apm_get_info(apm_info_t aip);
+
+/*
+ * 0-100 battery life remaining as percentage
+ * -1 unknown
+ */
+static int
+sysctl_apm_battlevel SYSCTL_HANDLER_ARGS
+{
+ int val;
+ struct apm_info stat;
+
+ if (apm_get_info(&stat))
+ val=-1;
+ else {
+ if (stat.ai_batt_life>100)
+ val=-1;
+ else
+ val=stat.ai_batt_life;
+ }
+ return sysctl_handle_int(oidp, &val, sizeof(val), req);
+}
+
+/*
+ * 5 = battery charging (implies AC power)
+ * 4 = AC power
+ * 3 = battery high
+ * 2 = battery low
+ * 1 = battery critical
+ * -1 = unknown
+ */
+static int
+sysctl_apm_powerstate SYSCTL_HANDLER_ARGS
+{
+ int val;
+ struct apm_info stat;
+
+ if (apm_get_info(&stat))
+ val=-1;
+ else {
+ if (stat.ai_batt_stat == 0)
+ val = 5;
+ else if (stat.ai_acline)
+ val = 4;
+ else if (stat.ai_batt_stat > 3)
+ val=-1;
+ else
+ val=stat.ai_batt_stat;
+ }
+ return sysctl_handle_int(oidp, &val, sizeof(val), req);
+}
+
+SYSCTL_PROC(_machdep, OID_AUTO, apm_battlevel, CTLTYPE_INT|CTLFLAG_RD, 0,
+ sizeof(sysctl_apm_battlevel), &sysctl_apm_battlevel,
+ "I", "Current APM battery level");
+SYSCTL_PROC(_machdep, OID_AUTO, apm_powerstate, CTLTYPE_INT|CTLFLAG_RD, 0,
+ sizeof(sysctl_apm_powerstate), &sysctl_apm_powerstate,
+ "I", "Current APM power state");
+
/*
* return 0 if the function successfull,
* return 1 if the function unsuccessfull,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39734D36.5FC7DDA>
