Re: [RFC PATCH] Quickstart Button ACPI driver to serve PNP0C32 ACPI devices

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

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