public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* General Questions:
@ 2005-02-04 12:32 Jeremy Moles
  2005-02-04 14:47 ` Rich Townsend
  0 siblings, 1 reply; 2+ messages in thread
From: Jeremy Moles @ 2005-02-04 12:32 UTC (permalink / raw)
  To: acpi-devel-TtF/mJH4Jtrk1uMJSBkQmQ

Hello again ACPI gurus! Many thanks for the last tip; I was able to
decompile and "fix" the DSDT rather easily using the advice from your
responses.

I have a few questions about batteries:

I was looking around the battery driver code last night trying to find
out what the battery "alarm" actually does. Unfortuneately (and I only
spent a few minutes looking), I wasn't able to easily see what the
function of this feature was. I guess my first question is: does it do
anything at all? :)

Secondly, would it be beyond of the scope of ACPI for the battery driver
to generate ACPI events when the power gets low? Or is there already
something like this that exists that I'm missing? I tried
watching /proc/acpi/event last as my battery discharged and didn't see
any unusual activity.

Thirdly, does the kernel have access to the LED lights on a typical
laptop? That is, does it have the ability to ping the LED and make it
light up? Or, is that something controlled entirely by hardware? It
would be rather neat, I think, to use my "bluetooth" LED (since I don't
have bluetooth) in an arbitrary way.

Anyways. :)

-- 
Jeremy L. Moles
EmperorLinux
1-888-651-66
www.EmperorLinux.com
jeremy-LdSqz1EEwCk7YuNMryXyOw@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: General Questions:
  2005-02-04 12:32 General Questions: Jeremy Moles
@ 2005-02-04 14:47 ` Rich Townsend
  0 siblings, 0 replies; 2+ messages in thread
From: Rich Townsend @ 2005-02-04 14:47 UTC (permalink / raw)
  To: jeremy-9vekgGPT+OA7YuNMryXyOw,
	Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Jeremy Moles wrote:
> Hello again ACPI gurus! Many thanks for the last tip; I was able to
> decompile and "fix" the DSDT rather easily using the advice from your
> responses.
> 
> I have a few questions about batteries:
> 
> I was looking around the battery driver code last night trying to find
> out what the battery "alarm" actually does. Unfortuneately (and I only
> spent a few minutes looking), I wasn't able to easily see what the
> function of this feature was. I guess my first question is: does it do
> anything at all? :)

The 'alarm' feature implemented in Linux is actually mapped to the _BTP 
(battery trip point) of the ACPI specification. Section 10.2.2.4 of this 
spec indicates that a notify must be issued when the battery remaining 
capacity crosses this alarm level (either falling below or rising above).

When the battery receives this notification, it dispatches a battery 
event, which shows up in /proc/acpi/events. What action is taken on this 
event is up to whatever userspace application you are using. I myself 
have configured acpid so that when a battery event is read, AND the 
system is on battery power, AND the remaining capacity is below the 
alarm level, the system automatically suspends (using swsusp2).

> 
> Secondly, would it be beyond of the scope of ACPI for the battery driver
> to generate ACPI events when the power gets low? Or is there already
> something like this that exists that I'm missing? I tried
> watching /proc/acpi/event last as my battery discharged and didn't see
> any unusual activity.

As per the stuff above, there is already stuff there. However, it only 
works through the _BTP functionality. If this functionality is not 
implemented in the DSDT -- or if the alarm level is set crazy low -- 
then you lose the capability to get advanced warning of low-power 
situations.

> 
> Thirdly, does the kernel have access to the LED lights on a typical
> laptop? That is, does it have the ability to ping the LED and make it
> light up? Or, is that something controlled entirely by hardware? It
> would be rather neat, I think, to use my "bluetooth" LED (since I don't
> have bluetooth) in an arbitrary way.

This really depends on the laptop in question. Do you by any chance have 
an Acer? My Acer TM4502 has an unused bluetooth LED/button, and I think 
there *might* be a way to control it through the BIOS (see recent posts 
by Johan Vromans).

cheers,

Rich


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-02-04 14:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-04 12:32 General Questions: Jeremy Moles
2005-02-04 14:47 ` Rich Townsend

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox