* [Bluez-devel] Renaming USB HID driver
@ 2004-03-22 13:54 Marcel Holtmann
2004-03-23 10:22 ` Nils Faerber
2004-03-29 8:47 ` dirk husemann
0 siblings, 2 replies; 6+ messages in thread
From: Marcel Holtmann @ 2004-03-22 13:54 UTC (permalink / raw)
To: BlueZ Mailing List; +Cc: Vojtech Pavlik, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
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
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1583 bytes --]
===== drivers/usb/input/Kconfig 1.13 vs edited =====
--- 1.13/drivers/usb/input/Kconfig Fri Feb 27 00:32:51 2004
+++ edited/drivers/usb/input/Kconfig Mon Mar 22 14:42:37 2004
@@ -21,7 +21,7 @@
If unsure, say Y.
To compile this driver as a module, choose M here: the
- module will be called hid.
+ module will be called usbhid.
comment "Input core support is needed for USB HID input layer or HIDBP support"
depends on USB && INPUT=n
===== drivers/usb/input/Makefile 1.17 vs edited =====
--- 1.17/drivers/usb/input/Makefile Fri Feb 27 13:51:51 2004
+++ edited/drivers/usb/input/Makefile Mon Mar 22 14:32:15 2004
@@ -3,32 +3,32 @@
#
# Multipart objects.
-hid-objs := hid-core.o
+usbhid-objs := hid-core.o
# Optional parts of multipart objects.
ifeq ($(CONFIG_USB_HIDDEV),y)
- hid-objs += hiddev.o
+ usbhid-objs += hiddev.o
endif
ifeq ($(CONFIG_USB_HIDINPUT),y)
- hid-objs += hid-input.o
+ usbhid-objs += hid-input.o
endif
ifeq ($(CONFIG_HID_PID),y)
- hid-objs += pid.o
+ usbhid-objs += pid.o
endif
ifeq ($(CONFIG_LOGITECH_FF),y)
- hid-objs += hid-lgff.o
+ usbhid-objs += hid-lgff.o
endif
ifeq ($(CONFIG_THRUSTMASTER_FF),y)
- hid-objs += hid-tmff.o
+ usbhid-objs += hid-tmff.o
endif
ifeq ($(CONFIG_HID_FF),y)
- hid-objs += hid-ff.o
+ usbhid-objs += hid-ff.o
endif
obj-$(CONFIG_USB_AIPTEK) += aiptek.o
obj-$(CONFIG_USB_ATI_REMOTE) += ati_remote.o
-obj-$(CONFIG_USB_HID) += hid.o
+obj-$(CONFIG_USB_HID) += usbhid.o
obj-$(CONFIG_USB_KBD) += usbkbd.o
obj-$(CONFIG_USB_KBTAB) += kbtab.o
obj-$(CONFIG_USB_MOUSE) += usbmouse.o
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Renaming USB HID driver
2004-03-22 13:54 [Bluez-devel] Renaming USB HID driver Marcel Holtmann
@ 2004-03-23 10:22 ` Nils Faerber
2004-03-23 10:30 ` Vojtech Pavlik
2004-03-24 15:27 ` Philip Blundell
2004-03-29 8:47 ` dirk husemann
1 sibling, 2 replies; 6+ messages in thread
From: Nils Faerber @ 2004-03-23 10:22 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ Mailing List, Vojtech Pavlik, Greg Kroah-Hartman
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
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Renaming USB HID driver
2004-03-23 10:22 ` Nils Faerber
@ 2004-03-23 10:30 ` Vojtech Pavlik
2004-03-24 15:27 ` Philip Blundell
1 sibling, 0 replies; 6+ messages in thread
From: Vojtech Pavlik @ 2004-03-23 10:30 UTC (permalink / raw)
To: Nils Faerber; +Cc: Marcel Holtmann, BlueZ Mailing List, Greg Kroah-Hartman
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Renaming USB HID driver
2004-03-23 10:22 ` Nils Faerber
2004-03-23 10:30 ` Vojtech Pavlik
@ 2004-03-24 15:27 ` Philip Blundell
2004-03-25 14:45 ` Nils Faerber
1 sibling, 1 reply; 6+ messages in thread
From: Philip Blundell @ 2004-03-24 15:27 UTC (permalink / raw)
To: Nils Faerber
Cc: Marcel Holtmann, BlueZ Mailing List, Vojtech Pavlik,
Greg Kroah-Hartman
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Renaming USB HID driver
2004-03-24 15:27 ` Philip Blundell
@ 2004-03-25 14:45 ` Nils Faerber
0 siblings, 0 replies; 6+ messages in thread
From: Nils Faerber @ 2004-03-25 14:45 UTC (permalink / raw)
To: Herr Philip Blundell
Cc: Marcel Holtmann, BlueZ Mailing List, Vojtech Pavlik,
Greg Kroah-Hartman
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
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bluez-devel] Renaming USB HID driver
2004-03-22 13:54 [Bluez-devel] Renaming USB HID driver Marcel Holtmann
2004-03-23 10:22 ` Nils Faerber
@ 2004-03-29 8:47 ` dirk husemann
1 sibling, 0 replies; 6+ messages in thread
From: dirk husemann @ 2004-03-29 8:47 UTC (permalink / raw)
To: bluez-devel; +Cc: Marcel Holtmann, Vojtech Pavlik, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
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
hud@zurich.ibm.com --- 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, www.gnupg.org
is a good starting point.
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-03-29 8:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-22 13:54 [Bluez-devel] Renaming USB HID driver Marcel Holtmann
2004-03-23 10:22 ` Nils Faerber
2004-03-23 10:30 ` Vojtech Pavlik
2004-03-24 15:27 ` Philip Blundell
2004-03-25 14:45 ` Nils Faerber
2004-03-29 8:47 ` dirk husemann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).