Extra keyboard buttons
Bastien Nocera
hadess at hadess.net
Mon Apr 23 14:14:59 PDT 2007
On Mon, 2007-04-23 at 16:01 -0400, David Zeuthen wrote:
> On Thu, 2007-04-19 at 23:27 +0100, Richard Hughes wrote:
> > With reference to my recent blog post:
> > http://hughsient.livejournal.com/23351.html
> >
> > I've been doing some research on how some random vendor buttons are
> > currently mapped into keycodes. Distros like ubuntu provide the
> > hotkey-setup [1] package that match dmi information and then assign keys
> > based on the vendor and type. Fedora don't ship this package.
> >
> > Maybe this is an idea for hal-info - we are perfectly in scope as we can
> > match DMI data trivially and then launch a very small script that just
> > runs commands like:
> >
> > setkeycodes e018 188
> >
> > hal-info can then be trivially updated as new keys are found for new
> > laptops.
> >
> > So, good idea / bad idea?
>
> I guess we could expose some of this in hal-info and have a callout in
> hal that takes this data and does the same as setkeycodes does. Or
> should it live elsewhere?
>
> Also, I think we need to be more ambitious; this weekend I was
> reconfiguring my multimedia keyboard, using the "Keyboard Shortcuts"
> dialog, to make the Play, Pause, Vol+, Vol-, Mute etc. known to GNOME.
> Would it make sense to have this kind of information in hal-info? Or
> should it live elsewhere?
In keymaps...
Richard's fix is for keys that don't generate kernel keycodes properly,
only scancodes.
> I'm fine with having all this in hal-info but _only_ if it's the right
> place to store this kind of data.
Some is, as Richard pointed out, but for everything else keymaps are the
right way to go.
--
Bastien Nocera <hadess at hadess.net>
More information about the hal
mailing list