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

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

On 4/24/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Mon, 2006-04-24 at 10:45 -0400, Dmitry Torokhov wrote:
> > Yes, I still need to apply it.
> >
> > Matthew, I would recommend not adding KEY_LID but using one of the
> > switch codes (SW_0?) for the lid.
> >
> > Richard, on your handhelds what switch would be most similar to
> > notebook's lid? Should we alias one of the switches to SW_LID?
>
> 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.

> The final switch (SW_2) is mapped to headphone detection.
>

We need to start naming switches so drivers will use same constants
for similar switches.

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

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

> In an ideal world, given the system nature of the events, perhaps they'd
> be better suited to a more generalised or specialised piece of code
> based on the input system. A more general events system would mean we
> could have:
>
> EVENT_LID_SHUT
> EVENT_LID_OPEN
> EVENT_LID_OPEN_NOKEYBOARD
>
> or similar which would avoid the issues associated with a single SW_LID
> switch. I suspect there are no easy answers though.

Bring dbus into the kernel ;) No, I think kernel should not have
"cover everythingunder the sun" interface but rather set of
specialized ones.

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

--
Dmitry