lkml.org 
[lkml]   [2010]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] Quickstart Button ACPI driver to serve PNP0C32 ACPI devices
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


\
 
 \ /
  Last update: 2010-05-28 20:03    [W:0.227 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site