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:	Thu, 17 May 2007 23:31:53 +0200 (CEST)
From:	Jiri Kosina <jikos@...os.cz>
To:	Tomas Carnecky <tom@...ervice.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: SideWinder GameVoice driver

On Thu, 17 May 2007, Tomas Carnecky wrote:

> Additional info: HID device has two collections (whatever those are, I
> have _no_ idea):

If you are interested what usages and collections are (and if you are 
going to write the support for this device, you probably are :) ), please 
see http://www.usb.org/developers/hidpage - namely
http://www.usb.org/developers/devclass_docs/HID1_11.pdf and possibly also 
http://www.usb.org/developers/devclass_docs/Hut1_12.pdf

> The culprit is the IS_INPUT_APPLICATION() macro, which only accepts 
> certain 'usage' types. Should it also accept this particular one, too, 
> or even the whole 'Telephony' group? Or maybe add a (configurable) 
> 'quirk' to enable the GameVoice device?

We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed by 
the hid-input system, that seems to make a little sense. 

So either the device is bogus and has broken report descriptor (which we 
could fix in runtime), or it really can't be handled by hid-input (I have 
no idea about the purpose and internal working of the device in question, 
sorry).

Either we can fix the hiddev_connect() so that the device would be claimed 
by hiddev (*) and you can write the driver for this device easily in 
userland, or you could try to write generic in-kernel hid-telephony.c 
handler of all telephony devices (but I doubt this is doable in a 
reasonable way).

(*) I currently have no idea why this device is not claimed by hiddev 
though - it seems to have all collections of type 
HID_COLLECTION_APPLICATION which obviously are not IS_INPUT_APPLICATION() 
... could you please put debugging output into hiddev_connect() to examine 
why your device is not being claimed by hiddev?

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ