Quickstart Button ACPI driver to serve PNP0C32 ACPI devices
in [Kernel]
|
Prev: ACPI: acpi_idle: touch TS_POLLING only in the non-MWAIT case
Next: sched_clock: Provide local_clock() and improve documentation
From: Dmitry Torokhov on 28 May 2010 14:10 On Fri, May 28, 2010 at 07:40:09PM +0200, Thomas Renninger wrote: > Hi, > > if you have a recent Microsoft Office format reader you find some > documentation here: > http://www.microsoft.com/whdc/system/platform/firmware/DirAppLaunch.mspx > > I finally got it converted and these should be readable in OpenOffice as well: > ftp.suse.com/pub/people/trenn/hotstart_quickstart_docu > > The idea of these buttons is that they are undefined from BIOS/kernel > point of view. Userspace has to map a functionality to them. > Therefore the idea to modify the input event keycode via sysfs file. What s wrong with using EVIOCSKEYCODE to adjust the mapping. Note that the issue of handlers not re-binding after keymap change should be solved regardless. > There should be 2 situations that perfectly are triggered via userspace: > - DMI match (or similar) and assign the correct buttons on the known > machine. I know that hal could do this rather well and had dmi > tables pre-defined. AFAIK hal is already obsolete? What userspace > tools/lists would be best to ask? udev/hal remap keys on laptop keyboards, they should have facilities to do that here as well. > > - If the button is undefined, a higher level userspace X application > could ask the user to set it to something useful. For this to > happen the usage id has to be passed somehow through the input > layer. Not sure how realistic such an implementation is and what > is still needed in X to make this happen. Yes, KEY_UNKNOWN is expected to cause such behavior. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |