Hi Folks,
my plan is to move the HID parser out of the USB subsystem and provide a
general HID parser implementation under drivers/hid/ which could then be
used by the USB and the Bluetooth subsystem drivers. To avoid any naming
conflict due and after the development I suggest to rename the USB HID
module from hid.ko to usbhid.ko (see attached patch).
I know that renaming a kernel module in a stable series is not a good
idea, but doing it now will help us in the long term. However people
which are using hotplug won't even notice it, because the kernel knows
the right module name. And if the transition is finished we can simply
remove the HID parser code from usbhid and everything will still work.
In the end it should look like this:
drivers/hid/hid.ko HID parser (input+hiddev+ff)
drivers/usb/input/usbhid.ko USB HID transport layer
net/bluetooth/hidp/hidp.ko Bluetooth HID protocol
Comments?
Regards
Marcel
On Monday 22 March 2004 14.54, Marcel Holtmann wrote to BlueZ Mailing List:
> Hi Folks,
>
> my plan is to move the HID parser out of the USB subsystem and provide a
> general HID parser implementation under drivers/hid/ which could then be
> used by the USB and the Bluetooth subsystem drivers. To avoid any naming
> conflict due and after the development I suggest to rename the USB HID
> module from hid.ko to usbhid.ko (see attached patch).
>
> I know that renaming a kernel module in a stable series is not a good
> idea, but doing it now will help us in the long term. However people
> which are using hotplug won't even notice it, because the kernel knows
> the right module name. And if the transition is finished we can simply
> remove the HID parser code from usbhid and everything will still work.
go for it...as to renaming kernel modules: the USB scanner module just
disappeared into thin air in the current 2.6 series (8=(()....so if that is
acceptable...
cheers,
dirk
--
Dr Dirk Husemann, Mobile Computing, IBM Research, Zurich Research Lab
[email protected] --- http://www.zurich.ibm.com/~hud/
PGP key: http://www.zurich.ibm.com/~hud/contact/PGP
PGP Fingerprint: 983C 48E7 0A78 A313 401C C4AD 3C0A 278E 6431 A149
Email only authentic if signed with PGP key.
Appended to this email is an electronic signature attachment. You can
ignore it if your email program does not know how to verify such a
signature. If you'd like to learn more about this topic, http://www.gnupg.org
is a good starting point.
Am Mi, den 24.03.2004 schrieb Philip Blundell um 16:27:
> On Tue, 2004-03-23 at 10:22, Nils Faerber wrote:
> > For example I am currently working on Linux for PDAs. Some of them can
> > be attached to external keyboards, mostly serial. Having a cleanly
> > abstracted HID layer would make it possible to have those properly
> > supported. Currently this is done by a pretty ugly hack calling
> > handle_scancode() or similar :(
> I don't think this would actually help much for those keyboards. As far
> as I know, none of the common PDA keyboards speak HID; they all use some
> custom serial protocol for event reporting. You can avoid the gruesome
> handle_scancode() stuff by injecting EV_KEY events into the input stack,
> either via input_report_key() within the kernel, or via uinput from
> user-space.
Ah, yes indeed, that make more sense.
So pls ignore my post ;)
I was about almost about to start digging through HID parsing and
thinking about emulating it...
> p.
CU
nils faerber
--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen D1 : +49-170-2729106
--
On Tue, 2004-03-23 at 10:22, Nils Faerber wrote:
> For example I am currently working on Linux for PDAs. Some of them can
> be attached to external keyboards, mostly serial. Having a cleanly
> abstracted HID layer would make it possible to have those properly
> supported. Currently this is done by a pretty ugly hack calling
> handle_scancode() or similar :(
I don't think this would actually help much for those keyboards. As far
as I know, none of the common PDA keyboards speak HID; they all use some
custom serial protocol for event reporting. You can avoid the gruesome
handle_scancode() stuff by injecting EV_KEY events into the input stack,
either via input_report_key() within the kernel, or via uinput from
user-space.
p.
On Tue, Mar 23, 2004 at 11:22:13AM +0100, Nils Faerber wrote:
> Am Mo, den 22.03.2004 schrieb Marcel Holtmann um 14:54:
> > Hi Folks,
> Hello!
>
> > my plan is to move the HID parser out of the USB subsystem and provide a
> > general HID parser implementation under drivers/hid/ which could then be
> > used by the USB and the Bluetooth subsystem drivers. To avoid any naming
> > conflict due and after the development I suggest to rename the USB HID
> > module from hid.ko to usbhid.ko (see attached patch).
> [...]
> > Comments?
>
> Maybe as additional motivation for a better abstraction, like Marcel
> porposed, I would like to mention other keyboard devices on other Linux
> platforms that could benefit from this!
> For example I am currently working on Linux for PDAs. Some of them can
> be attached to external keyboards, mostly serial. Having a cleanly
> abstracted HID layer would make it possible to have those properly
> supported. Currently this is done by a pretty ugly hack calling
> handle_scancode() or similar :(
You seem to be talking 2.4? In 2.6 you have an abstract input layer,
where you call register_input_device() and then input_report_key() for
these kinds of devices. You definitely are not supposed to call
handle_scancode() directly.
We're talking about another HID separation, separating the parser for
HID descriptors, as defined in the USB HID specification.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Am Mo, den 22.03.2004 schrieb Marcel Holtmann um 14:54:
> Hi Folks,
Hello!
> my plan is to move the HID parser out of the USB subsystem and provide a
> general HID parser implementation under drivers/hid/ which could then be
> used by the USB and the Bluetooth subsystem drivers. To avoid any naming
> conflict due and after the development I suggest to rename the USB HID
> module from hid.ko to usbhid.ko (see attached patch).
[...]
> Comments?
Maybe as additional motivation for a better abstraction, like Marcel
porposed, I would like to mention other keyboard devices on other Linux
platforms that could benefit from this!
For example I am currently working on Linux for PDAs. Some of them can
be attached to external keyboards, mostly serial. Having a cleanly
abstracted HID layer would make it possible to have those properly
supported. Currently this is done by a pretty ugly hack calling
handle_scancode() or similar :(
> Regards
> Marcel
CU
nils faerber
--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen D1 : +49-170-2729106
--