Re: [PATCH 1/1] HID: add have_special_driver hid module parameter

Hi Nikolai

On Sun, Apr 1, 2012 at 9:44 PM, Nikolai Kondrashov [off-list ref] wrote:

Hi David,


On 03/31/2012 02:03 AM, David Herrmann wrote:

quoted

Rebinding works perfectly well for me. I use it all the time when
testing HID drivers.

Thank you.

I've tried it, but it doesn't work for me, because HID report descriptors
are not re-parsed after rebinding and I rely on report_fixup's a lot. Please
see my reply to Jiri for slightly more details:
http://thread.gmane.org/gmane.linux.kernel.input/23708/focus=24337

quoted

Furthermore, there is a dynid-implementation in the kernel so when hacking
on something like this I'd recommend using this. It would also remove the
hard limit that you currently have.

Thanks, but this doesn't suit me currently. I don't implement report parsing
in my drivers, but rather describe every device protocol separately with a
report descriptor and rely on the generic driver for parsing. Thus, I save
in code complexity and maintenance, but loose in portability.

I think you don't understand me correctly. I meant instead of using
some static global table in the module you could instead implement
something like the "new_id"/store_new_id()/dyn_list/dyn_lock mechanism
but for the special_driver-id-array. So one could use "echo vid:pid

/sys/bus/hid/new_special_driver_id" and it would be added to a linked

list which is checked additionally to the static array.

Such a mechanism is already used by all kinds of buses, hid, usb,
pci... but only for the id-lists of drivers, not a global module list.
At least this would look less hackish than a fixed-length-array module
parameter ;)

However, I plan to make a non-HID driver for Waltop tablets, using their
proprietary, HID-incompatible protocol and there I will probably use that.

Sincerely,
Nick

Regards
David