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: <alpine.LNX.2.00.0904161123180.13028@wotan.suse.de>
Date:	Thu, 16 Apr 2009 11:24:42 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Mark Lord <lkml@....ca>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: Input driver for Twinhan USB 6253:0100 remote control

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.

-- 
Jiri Kosina
SUSE Labs
--
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/