HAL FDI matched Buttons

[Richard Hughes]

On Sun, 2005-11-27 at 22:22 +0100, Matthias Grimm wrote:
> On Sun, 27 Nov 2005 17:40:28 +0000
> Richard Hughes <hughsient at gmail.com> wrote:
> 
>  
> > * Perhaps use a uinput kernel side input device for maximum
> >   compatibility.
> 
> This one is the best. All you need is to assign a keycode to not
> supported keys. Desktop applications would do the rest.
> 
> Actually I wanted to tell you now that there are a lot of applications
> already out there to do this, but to my surprise, they aren't. I looked
> for a program that is able to start arbitrary programs on key trigger,
> but I found only a single project. I thought that
> desktop-preferences/keyboard-hotkeys (or similar, I use a german
> desktop) would do the job, but it only allows to change the default key
> mapping of certain desktop events. I haven't checked KDE for their
> capabilities here. My investigation wasn't very deep so I may have
> overlooked something. If not tis would be the idea for a new project,
> maybe :-)

Well, GNOME keyboard shortcuts seems to work well for me, but then I
only want simple stuff like eject, next, previous, suspend and lock.

> > For instance, one fdi file could map the alt-f4 key to the scancode for
> > HELP, so that the image on the button matches the action. This would
> > only be done for the system.vendor = VENDOR.
> 
> But by no means I would enforce the burden of key mapping on HAL. This
> will conflict with too many other mechanisms like X11, kernel key
> mapping, and whatelse more and would only be another never ending
> construction site.

Sure, but if the key generates a scancode unknown to X, and it's meant
to be "lock" (which we can map to an existing keyname) or it generates a
acpi event we need to know how to map this from one to the other.

I figured an fdi file could do this in the existing HAL framework, but
am really open to ideas.

> You already did a step in the right direction as you started to
> implement a virtual keyboard device for HAL with uinput. Why don't go
> this way further? This would also match my visions of future power
> management (see also http://pbbuttons.berlios.de/wiki/index.php).

Ohh, I will. The uinput device is really flexible, and seems to work
well on my local tree. All I need to do now is somehow plumb it into a
generic HAL thing and make it completely generic.

In this way any user-space (session on system) can use the
functionality.

Thanks for your input,

Richard.