Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760681AbWLFPAE (ORCPT ); Wed, 6 Dec 2006 10:00:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760682AbWLFPAE (ORCPT ); Wed, 6 Dec 2006 10:00:04 -0500 Received: from styx.suse.cz ([82.119.242.94]:54342 "EHLO mail.suse.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1760681AbWLFPAB (ORCPT ); Wed, 6 Dec 2006 10:00:01 -0500 Date: Wed, 6 Dec 2006 16:00:12 +0100 (CET) From: Jiri Kosina To: Marcel Holtmann Cc: Dmitry Torokhov , Li Yu , Greg Kroah Hartman , linux-usb-devel , LKML , Vincent Legoll , "Zephaniah E. Hull" , liyu Subject: Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.4.1 (core) In-Reply-To: <1165415924.2756.63.camel@localhost> Message-ID: References: <200612061803324532133@gmail.com> <1165415924.2756.63.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2368 Lines: 50 On Wed, 6 Dec 2006, Marcel Holtmann wrote: > > 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. I guess that this paragraph wasn't for me, but rather for the author of the HID Simple Driver proposal, am I right? > > Jiri, I have not looked at your patches yet (I need to do that) but Please do, when you will have time. Any comments are very welcome, before I start actually heading for the merge. > 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. Yes, the hidraw driver is one of the things that I am planning to develop on top of the generic HID layer, after the HID split gets merged. The current patches mainly take the contents of drivers/usb/input, and separate the code to transport-specific and the rest, which is then put into drivers/hid (of course some code changes are needed) and USB-specific HID code is then hooked into this new HID layer. I have tried to verify that hooking bluetooth, in the state in which it currently is (plus the patches which are not in mainline, also because of non-existence of common HID code), would stay relatively easy task, hopefully. This split is quite painful, as there are many things happening in USB all the time, so the best way seem to be just to perform big split (with needed changes) at once, and then develop other things on top of it (like hidraw). -- Jiri Kosina SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/