From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Trilok Soni <soni.trilok@gmail.com>
Cc: "Rick L. Vinyard, Jr." <rvinyard@cs.nmsu.edu>,
Linux USB <linux-usb@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-input@vger.kernel.org
Subject: Re: Using EV_MSC or extending KEY_*
Date: Tue, 15 Sep 2009 11:34:06 -0700 [thread overview]
Message-ID: <20090915183406.GA5696@core.coreip.homeip.net> (raw)
In-Reply-To: <5d5443650909151011k4b21a6d0n28ac6142c3d7161d@mail.gmail.com>
On Tue, Sep 15, 2009 at 10:41:30PM +0530, Trilok Soni wrote:
> Adding linux-input.
>
> On Tue, Sep 15, 2009 at 9:49 PM, Rick L. Vinyard, Jr.
> <rvinyard@cs.nmsu.edu> wrote:
> > On the Logitech G13 there are a set of 10 special keys at the top of the
> > device.
> >
> > I've written the driver so that it maintains a map from the general keys
> > (G1-G22) to Linux' input subsystem keys.
> >
> > The map can be changed on the fly, allowing multiple keymaps to be loaded.
> >
> > As a side note I haven't provided for this functionality (multiple
> > keymaps) in the driver since this can be maintained from userspace, but it
> > does need to know about the currently loaded keymap so that when the raw
> > HID events are parsed the appropriate EV_KEY events can be input.
> >
> > I could set it up so that the special keys also map to a KEY_* code.
> > However, I'd prefer to set things up so that any G1-G22 key can be mapped
> > to any input subsystem KEY_* code and not reserve a set of 10 from the
> > current KEY_* codes for the 10 special keys.
> >
> > One way I was thinking of approaching this was to generate EV_MSC type
> > events (with a MSC_RAW code) using the value to indicate the state
> > (pressed/released) and special key.
Doesn't HID already generate EV_MSC/MSC_SCAN for exactly this purpose
so userspace knows what keys can be remapped? You may initially map all
keys you don't know the usage to KEY_UNKNOWN.
> >
> > Another way to approach this would be to extend the KEY_* #defines with a
> > special set of 10 codes for the 10 special keys.
> >
No, please don't do this.
--
Dmitry
next prev parent reply other threads:[~2009-09-15 18:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-15 16:19 Rick L. Vinyard, Jr.
2009-09-15 17:11 ` Trilok Soni
2009-09-15 18:34 ` Dmitry Torokhov [this message]
2009-09-15 19:05 ` Rick L. Vinyard, Jr.
2009-09-16 2:19 ` Henrique de Moraes Holschuh
2009-09-16 21:27 ` Rick L. Vinyard, Jr.
2009-09-16 3:46 ` Dmitry Torokhov
2009-09-16 21:27 ` Rick L. Vinyard, Jr.
2009-09-17 17:57 ` Henrique de Moraes Holschuh
2009-09-18 6:46 ` Dmitry Torokhov
2009-09-18 13:56 ` Henrique de Moraes Holschuh
2009-09-18 16:00 ` Rick L. Vinyard, Jr.
2009-09-28 17:03 ` Dmitry Torokhov
2009-09-18 15:40 ` Rick L. Vinyard, Jr.
2009-09-28 17:03 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090915183406.GA5696@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rvinyard@cs.nmsu.edu \
--cc=soni.trilok@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®