Hi Marcel,
On 12/6/06, Marcel Holtmann <[email protected]> wrote:
Hi Dmitry,
> > > 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.
I actually prefer that we go the way hid_{register|unregister}_device
and have a hid_alloc_device(descriptor) to actually create the new HID
device and allocate its descriptor tables.
The transport actually doesn't care on how you interpret or tweak the
events. This is not its job. It is a simple plain stupid transport.
Every additional driver that you put on top of the HID parser will look
at the VID/PID and then decide which input event to send or what to do.
So from my understanding the generic one should work just fine, but in
case we need some special handling you can load an extra driver to
handle this. And this could be done as HID driver. One driver could be
the new hidraw driver to allow raw access to the HID reports.
Well, it seems we have 2 different kinds of HID drivers. Hidraw is an
alternate interface driver - it provides different interface to HID
device and therefore can be implemented as "extra" driver. Li Yu's
"simple" drivers extend existing input interfaces. I do not think
you'd want to have /dev/input/event0 implementing partially incorrect
keyboard support (for a particular keyboard) and /dev/input/event1
(the one cretaed by a simple drver if impleented as extra interface)
implementing better support.
> 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.
Again. The driver doesn't have to know if it is Bluetooth or USB that
the reports are send over. For example a company can make the same
keyboard and one version is using Bluetooth and the other USB. You don't
wanna have two different drivers for it. You only need one driver that
knows how to speak HID.
But you need to know when to attach your driver. How would pure HID
driver know that? USB driver can do that via manufacturer/product IDs.
And we have all that infrastructure of loading proper modules. Or do
you want to create a hid bus?
> Btw, I saw you moving it into drivers/hid, would not
> drivers/input/hid/ suit better?
This would stick HID to the input subsystem and from my understanding
the HID parser can even work without input. The input subsystem is only
one user of it. In case of hidraw access you don't need the input
subsystem at all.
OK.
--
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]
