Re: [RFC] [PATCH] Make ACPI button driver an input device

[Richard Purdie <rpurdie@rpsys.net>]

On Mon, 2006-04-24 at 22:34 +0200, Pavel Machek wrote:
> What is on the jack, BTW? Left headphone, right headphone, mic in? Can
> all of them be used independently?

> > It gets tricky. AC presence isn't a property of a battery for example
> > and is in fact more like a switch (my handheld has a mechanical
> > switch
> 
> Oops, really? Mechanical switch to sense ac in? (What happens when you
> plug in charger but that is not plugged to AC?)

Most of the Zaurus devices can measure the AC voltage and make sanity
checks on it in the SharpSL Battery/PM code.

> I think that AC presence should be handled independently from
> battery. There can be >1 battery in the system.

Agreed. This is some of the leftover information I'm referring to below.

>(Another interesting question is: is AC status 0/1 or is it number of
> milivolts?)

I'd say millivolts except for the problem of what you do on systems that
don't support voltage readings. Use a very high value I guess. For a lot
of devices millivolts also means in kernel conversion tables. Do such
things belong in kernel or user space?

> > to detect when its plugged in) ;). The battery class would export some
> > information but not all of it and I don't know where the leftover
> > information should go. If I knew that, I'd write the class.
> 
> Leftover information?

Where to put AC status and AC voltage readings amongst other things.
Another sysfs class? Also, how do you control suspend/resume
notifications to userspace if not using APM/ACPI?

> I think we should create directory in sysfs, and populate it according
> to battery's capabilities.
> 
> Zaurus' battery would have voltage and maybe percent fields.
> 
> ACPI battery would have all the usual fields.
> 
> Another important question is a way for user applications to avoid
> polling... but I guess that should be solveable by enabling select on
> one of those files.

Agreed, this is something that would be needed.

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/