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. The final switch (SW_2) is mapped to headphone detection. 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. 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. 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. 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. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
