Hi! > > 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). Well, it "headset inserted" is a kind of user button... What is on the jack, BTW? Left headphone, right headphone, mic in? Can all of them be used independently? > > > 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 Oops, really? Mechanical switch to sense ac in? (What happens when you plug in charger but that is not plugged to AC?) I think that AC presence should be handled independently from battery. There can be >1 battery in the system. (Another interesting question is: is AC status 0/1 or is it number of milivolts?) > 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? 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. Pavel -- Thanks for all the (sleeping) penguins. - 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
