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

[Richard Purdie <rpurdie@rpsys.net>]

On Mon, 2006-04-24 at 12:26 -0400, Dmitry Torokhov wrote:
> On 4/24/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> > This gets tricky as the handhelds have two "lid" switches. Pictures of
> > how it can fold are at http://www.dynamism.com/sl-c3000/main.shtml . To
> > summarise, it can be in three positions:
> >
> > * Screen folded facing the keys (shut like a laptop)
> > * Screen open above the keyboard (like an open laptop)
> > * Screen folded over the keys but with the screen visible (becomes a
> > tablet like handheld with no keyboard)
> >
> > Shut is when both switches (SW_0 and SW_1) are pressed, open is when
> > neither are pressed and the "no keyboard" mode has only one switch
> > pressed.
> 
> Ugh... I wonder if we could change SW_0 to report "comletely
> shut"/"open" and SW_1 to report orientation. Then we could alias SW_0
> <-> SW_LID, SW_1 <-> SW_TABLET_MODE.

I've checked which switch is which and SW_0 is equivalent to SW_LID. We
can just rename them and retain compatibility if:

SW_0/SW_LID is pressed to indicate shut
SW_1/SW_TABLET_MODE is pressed to indicate tablet mode
SW_2/SW_HEADPHONE_DETECT is pressed to indicate headphone jack insertion

I'm happy to submit a patch to make that change (and remove the as yet
unused SW_[3-7] if you like?

I realise there are arguments for having the headphone jack control
monitoring in the sound driver but this was the nicest way I've found of
passing the event to user space to deal with. I didn't want to deal with
it in the sound driver as in this case there is no right answer as to
what the sound driver should do (we can't detect if it was headphones, a
speaker + mic headset etc. or just a mic that was inserted yet we can
support all of them).

> > If we are going to have a KEY_LID switch, we should probably decide now
> > whether the switch is pressed (1) when the lid is either open or shut
> > otherwise things are going to get confused.
>
> SW_LID please.

Sorry, I did mean SW_LID.

> > I've often wondered whether the input system could/should be used to
> > pass more generic events. I know my handheld has lots of other switch
> > like events such as MMC/SD card insertion, CF card insertion, a battery
> > lock switch, AC power insertion switch and USB cable detection "switch".
> > Most of these are currently acted on by the kernel so userspace doesn't
> > need to see them but some like the USB cable detection would be useful.
> > It could then load the user's chosen USB gadget kernel module for
> > example. In that case its a user choice as there is no "right" gadget
> > module to autoload. I'm not sure if it would be right for these to go
> > via the input system and last time I looked, udev wasn't able to handle
> > generic events like this.
> >
> 
> I don't think these belong to input system.

Yet they're arguably switches and have all the right semantics to be
reported as such. I agree they shouldn't be in the input system but
where should they be? Currently we don't need most of them but some
would be useful.

> > Whilst sort of on the subject (AC power switches and AC power events)
> > I'd like to see some standard way of exporting power/battery information
> > to userspace. Currently, the ARM handhelds use kernel emulation of an
> > APM bios and export the battery info as part of that. Making ARM emulate
> > ACPI interfaces doesn't appeal. The answer could be a battery sysfs
> > class and the above system events interface but I'm open to other
> > suggestions.
> >
> 
> Having generic battery interface would be nice.

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
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.

Cheers,

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/