linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Linux Input <linux-input@vger.kernel.org>, jonno.conder+bugs@gmail.com
Subject: HID: Allow changing not-yet-mapped usages
Date: Tue, 14 Sep 2010 21:58:22 -0700	[thread overview]
Message-ID: <20100915045822.GA21672@core.coreip.homeip.net> (raw)

Jiri,

Currently HID only allows re-mapping of usages that have already been
mapped by hid-input or one of the sub-drivers as keys. This,
unfortunately, leads to sub-drivers multiplying by the hour and many
of them only do initial setup of usages and waste memory once that is
done.

How about we also allow EVIOCSKEYCODE to establish mapping for
not-yet-unmapped usages (usage->type == 0)? Then we could offload the
task of setting up keymaps to udev.

This depends on the large keycode handling patches that are in my tree
in 'next' branch. Not tested past booting...

-- 
Dmitry

Input: hid-input - allow mapping unknown usages

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Currently HID layer only allows to remap keycodes for known usages,
and responds with -EINVAL when user tries to map new usage code.
This precludes us form relying on udev/keymap for establishing correct
mappings and forces us to write dummy HID drivers responsible only for
setting up keymaps.

Let's allow remapping not only usages that have been set up as keys
(usage->type == EV_KEY) but also yet-unmapped usages (usage->type == 0).

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/hid/hid-input.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)


diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index b12c07e..8dd17ce 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -77,7 +77,10 @@ static bool match_scancode(struct hid_usage *usage,
 static bool match_keycode(struct hid_usage *usage,
 			  unsigned int cur_idx, unsigned int keycode)
 {
-	return usage->code == keycode;
+	/*
+	 * We should exclude unmapped usages when doing lookup by keycode.
+	 */
+	return usage->type == EV_KEY && usage->code == keycode;
 }
 
 static bool match_index(struct hid_usage *usage,
@@ -103,7 +106,7 @@ static struct hid_usage *hidinput_find_key(struct hid_device *hid,
 			for (i = 0; i < report->maxfield; i++) {
 				for (j = 0; j < report->field[i]->maxusage; j++) {
 					usage = report->field[i]->usage + j;
-					if (usage->type == EV_KEY) {
+					if (usage->type == EV_KEY || usage->type == 0) {
 						if (match(usage, cur_idx, value)) {
 							if (usage_idx)
 								*usage_idx = cur_idx;
@@ -144,7 +147,8 @@ static int hidinput_getkeycode(struct input_dev *dev,
 
 	usage = hidinput_locate_usage(hid, ke, &index);
 	if (usage) {
-		ke->keycode = usage->code;
+		ke->keycode = usage->type == EV_KEY ?
+				usage->code : KEY_RESERVED;
 		ke->index = index;
 		scancode = usage->hid & (HID_USAGE_PAGE | HID_USAGE);
 		ke->len = sizeof(scancode);
@@ -164,7 +168,8 @@ static int hidinput_setkeycode(struct input_dev *dev,
 
 	usage = hidinput_locate_usage(hid, ke, NULL);
 	if (usage) {
-		*old_keycode = usage->code;
+		*old_keycode = usage->type == EV_KEY ?
+				usage->code : KEY_RESERVED;
 		usage->code = ke->keycode;
 
 		clear_bit(*old_keycode, dev->keybit);

             reply	other threads:[~2010-09-15  4:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15  4:58 Dmitry Torokhov [this message]
2010-09-15  6:51 ` HID: Allow changing not-yet-mapped usages Jonathan Conder
2010-09-15  7:03   ` Dmitry Torokhov
2010-09-15 14:36 ` Jarod Wilson
2010-09-15 14:48 ` Jiri Kosina
2010-09-15 16:16   ` Dmitry Torokhov
2010-09-15 17:15     ` Jiri Kosina

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=20100915045822.GA21672@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jonno.conder+bugs@gmail.com \
    --cc=linux-input@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).