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]

Date:	Mon, 13 Jul 2009 13:21:15 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
Cc:	Mark Lord <lkml@....ca>,
	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 Mon, 13 Jul 2009, Bruno Prémont wrote:

> > > +	// set_bit(EV_REP, hi->input->evbit);
> > Why is this commented out?
> That was a remaining line from basing on hid-gyration.c Don't know what 
> it does, looks like related to key repeating but I've not read enough of 
> HID/Input code to find out. (all my tests were run with it commented 
> out, so I will drop it unless there is a good reason to uncomment it)

Yes, EV_REP is a flag which signals whether the keys produced by the 
device in question should be auto-repreated.

> With my patch it seems the mappings don't show up for EVIOCGKEYCODE:
> 
> int codes[2];
> for (codes[0] = 0; codes[0] < 1024; codes[0]++)
>   if (ioctl(evdev, EVIOCGKEYCODE, codes) >= 0) {
>     // display
>   } else
>     break;
> 
> Code block above only displays for codes[0] == 0:
>  codes = { 0, 388 /* KEY_TEXT */ }
> 
> For all other values of codes[0] ioctl returns EINVAL.
> 
> Is this expected or should complete mapping table be returned
> as it is for generic PS2 PC keyboard (if so, what changes does the
> patch need for it)?

The HID core's perception of scancode is the actual HID usage as reported 
by the device, inlcuding the page number.

I.e. for your device, the usages would be in 0x70004 - 0x70052 range, not 
0-1024 (which is what your current code is checking for).

Also, looking at the patch again -- could you please keep the usage 
numbers sorted in the switch-case in twinhan_input_mapping(), so that it's 
more readable and compatible with other drivers?

Thanks,

-- 
Jiri Kosina
SUSE Labs