Hi,
On 12/6/06, Jiri Kosina <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
