linux-kernel - Re: Input driver for Twinhan USB 6253:0100 remote control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090713034159.GA10819@dtor-d630.eng.vmware.com>
Date:	Sun, 12 Jul 2009 20:41:59 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
Cc:	Jiri Kosina <jkosina@...e.cz>, Mark Lord <lkml@....ca>,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: Input driver for Twinhan USB 6253:0100 remote control

On Sun, Jul 12, 2009 at 06:20:26PM +0200, Bruno Prémont wrote:
> On Thu, 16 April 2009 Jiri Kosina <jkosina@...e.cz> wrote:
> > On Wed, 15 Apr 2009, Mark Lord wrote:
> > > > Yes, hid-belking is a good example of trivial driver that sits on
> > > > a HID bus for you, as it utilizes the ->input_mapping() callback,
> > > > which is probably the only callback from HID core you'd need.
> > > Actually, the input-mapping() alone won't do the job here.
> > > This Twinhan remote control sends single-byte codes for most
> > > buttons, but some buttons send multi-byte codes, and we have to
> > > discard the extraneous bytes somehow.
> > 
> > If the usages make it through the generic HID layer (depends on the
> > report descriptor of the device), then just registering hid_driver
> > with ->event() set to your callback and fixing this on the fly could
> > be enough.
> 
> I do have such a remote around.
> 
> I wrote the below patch to adjust it's key mappings, though I'm not
> sure if/how I should deal with the number keys (0..9) with regard to
> keyboard layout and/or numlock key.
> 
> I tried with KEY_0..KEY_9 (default) as well as KEY_KP0..KEY_KP9 but
> neither produces optimal results on my machine (laptop with numlock
> disabled and belgian keyboard layout, e.g. KEY_1 => '&' unless shift
> is down)
> i

That was the reason KEY_NUMERIC_* keycodes were intriduced - they
shuppsed to be unaffected by labuguage keymap or numlock state.

> KEY_NUMERIC_0..KEY_NUMERIC_9 are not recognized by Linux console (don't
> know if/how userspace understands them)
> 

They just probably missing from the installed keymap, that's all.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/