Hi Jiri,
On Tue, 20 Mar 2007, Jiri Kosina wrote:
What is your opinion on an alternative aproach - the hid_blacklist[] could
stay intact, and the linked list in your patch will be used in a slightly
different way - it will be used to define *exceptions* (which will be
possible to be tuned in run
On Mon, 19 Mar 2007, Jiri Kosina wrote:
>I agree that current quirk handling in usbhid is not the best thing on
>earth and needs improving - this should be acomplished in future by
>converting HID layer to bus.
Hi, Jiri,
I find this mail list just now :D
I am try to make HID busize. Here is the
On Mon, 19 Mar 2007, Paul Walmsley wrote:
> > Also your solution cosumes significantly more memory (adding 16 bits to
> > every hid_blacklist entry, duplicating the information into list that in
> > most cases will stay intact and just mirror the contents of
> > hid_blacklist). Not that it's a big
Hello Jiri,
thanks for the review.
On Mon, 19 Mar 2007, Jiri Kosina wrote:
You can currently "force" HID_QUIRK_IGNORE for the device that has been
already bound to usbhid driver through 'unbind' file in sysfs. This lets
you to ask usbhid driver to release the device. So you can just have
HID_Q
On Sun, 18 Mar 2007, Paul Walmsley wrote:
> The USB HID quirk list ('hid_blacklist') is a compile-time fixed array
> in the current kernel. Any modifications require editing the module
> source and recompiling. Some distributions compile the usbhid code into
> the kernel, thus requiring that
The USB HID quirk list ('hid_blacklist') is a compile-time fixed array
in the current kernel. Any modifications require editing the module
source and recompiling. Some distributions compile the usbhid code
into the kernel, thus requiring that the entire kernel be rebuilt.
For most HID devices,
