Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.4.1 (core)

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

Hi,

On 12/6/06, Jiri Kosina <jkosina@suse.cz> wrote:
> On Wed, 6 Dec 2006, Li Yu wrote:
>
> >       1. Make hidinput_disconnect_core() be more robust, it can not
> >          break anything even failed to allocate device struct.
> >       2. Thanks new input device driver API, we need not the extra code
> >          for support force-feed device yet, so say bye to
> >          CONFIG_HID_SIMPLE_FF.
> > Is this ready to merge? or What still is problem in them? Thanks.
>
> Hi,
>
> actually, I have prepared patches to split the USBHID code in two parts -
> generic HID, which could be hooked by transport-specific HID layers (USB,
> Bluetooth).
>
> I did not send them to lkml/linux-usb, as they are quite big (mainly
> because a lot of code is being moved around). I am currently trying to
> setup a git repository on kernel.org, hopefully kernel.org people will
> react, so that the patches could be easily put into git repository and be
> available for rewiew and easy merge. After that, they are planned to be
> merged either into Greg's or Andrew's tree. I can send them to you if you
> want.
>
> Do you think that you could wait a little bit more, after the split has
> been done? (it's currently planned approximately after 2.6.20-rc1). It
> seems to me that your patches will apply almost cleanly on top of the
> split patches (you will have to change the pathnames, of course).
>

I still have the same objection - the "simple'" code will have to be
compiled into the driver instead of being a separate module and
eventyally will lead to a monster-size HID module. We have this issue
with psmouse to a degree but with HID the growth potential is much
bigger IMO.

Jiri, I have not looked at your patches yet (I need to do that) but
what I was hoping to do (or have someone to do ;) ) is to provide
ability to define HID transport drivers (we would have USB transport
and bluetooth transport) and then say:

  device = hid_create_device(&my_transport);
  device->event = my_event_handler;
  ....
  hid_start_device(device);

hid-create_device would parse all reports and create "standard" hid
device. Then you have a chance to override and tweak it as you see
fit.

This way we could have several small drivers implementing quirks to
the generic HID driver. Most of the code is still in hid core module
but every individual driver is complete USB (or bluetooth) driver, has
its own device table and is loaded via standard driver code bust
matching/hotplug modalias mechanism.

Btw, I saw you moving it into drivers/hid, would not
drivers/input/hid/ suit better?

-- 
Dmitry