Commit ff533b76 authored by Marcel Holtmann's avatar Marcel Holtmann

[PATCH] USB: Rename the USB HID driver

> > I like to see this rename as soon as possible. So if nobody minds I send
> > a patch to LKML and ask Linus for inclusion.
>
> Go ahead, but also please patch all relevant documentation in the
> kernel.

the attached patch should do the renaming everywhere hid or hid.o was
mentioned. It also removes all references to *.o module names.
parent fea7770c
...@@ -20,7 +20,7 @@ devices. Please read joystick.txt before reading further this document. ...@@ -20,7 +20,7 @@ devices. Please read joystick.txt before reading further this document.
2. Instructions to the user 2. Instructions to the user
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here are instructions on how to compile and use the driver. In fact, this Here are instructions on how to compile and use the driver. In fact, this
driver is the normal iforce.o, input.o and evdev.o drivers written by Vojtech driver is the normal iforce, input and evdev drivers written by Vojtech
Pavlik, plus additions to support force feedback. Pavlik, plus additions to support force feedback.
Before you start, let me WARN you that some devices shake violently during the Before you start, let me WARN you that some devices shake violently during the
......
...@@ -35,18 +35,18 @@ devices, future use (say 2.5/2.6) is expected to expand to replace ...@@ -35,18 +35,18 @@ devices, future use (say 2.5/2.6) is expected to expand to replace
most of the existing input system, which is why it lives in most of the existing input system, which is why it lives in
drivers/input/ instead of drivers/usb/. drivers/input/ instead of drivers/usb/.
The centre of the input drivers is the input.o module, which must be The centre of the input drivers is the input module, which must be
loaded before any other of the input modules - it serves as a way of loaded before any other of the input modules - it serves as a way of
communication between two groups of modules: communication between two groups of modules:
1.1 Device drivers 1.1 Device drivers
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
These modules talk to the hardware (for example via USB), and provide These modules talk to the hardware (for example via USB), and provide
events (keystrokes, mouse movements) to the input.o module. events (keystrokes, mouse movements) to the input module.
1.2 Event handlers 1.2 Event handlers
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
These modules get events from input.o and pass them where needed via These modules get events from input and pass them where needed via
various interfaces - keystrokes to the kernel, mouse movements via a various interfaces - keystrokes to the kernel, mouse movements via a
simulated PS/2 interface to GPM and X and so on. simulated PS/2 interface to GPM and X and so on.
...@@ -56,12 +56,12 @@ simulated PS/2 interface to GPM and X and so on. ...@@ -56,12 +56,12 @@ simulated PS/2 interface to GPM and X and so on.
you'll have to load the following modules (or have them built in to the you'll have to load the following modules (or have them built in to the
kernel): kernel):
input.o input
mousedev.o mousedev
keybdev.o keybdev
usbcore.o usbcore
usb-uhci.o or usb-ohci.o or uhci.o uhci_hcd or ohci_hcd or ehci_hcd
hid.o usbhid
After this, the USB keyboard will work straight away, and the USB mouse After this, the USB keyboard will work straight away, and the USB mouse
will be available as a character device on major 13, minor 63: will be available as a character device on major 13, minor 63:
...@@ -98,9 +98,9 @@ XFree to this device to use it - GPM should be called like: ...@@ -98,9 +98,9 @@ XFree to this device to use it - GPM should be called like:
however not useful without being handled, so you also will need to use some however not useful without being handled, so you also will need to use some
of the modules from section 3.2. of the modules from section 3.2.
3.1.1 hid.o 3.1.1 usbhid
~~~~~~~~~~~ ~~~~~~~~~~~~
hid.o is the largest and most complex driver of the whole suite. It usbhid is the largest and most complex driver of the whole suite. It
handles all HID devices, and because there is a very wide variety of them, handles all HID devices, and because there is a very wide variety of them,
and because the USB HID specification isn't simple, it needs to be this big. and because the USB HID specification isn't simple, it needs to be this big.
...@@ -115,7 +115,7 @@ interface, but for the UPSs and LCDs it doesn't make much sense. For this, ...@@ -115,7 +115,7 @@ interface, but for the UPSs and LCDs it doesn't make much sense. For this,
the hiddev interface was designed. See Documentation/usb/hiddev.txt the hiddev interface was designed. See Documentation/usb/hiddev.txt
for more information about it. for more information about it.
The usage of the hid.o module is very simple, it takes no parameters, The usage of the usbhid module is very simple, it takes no parameters,
detects everything automatically and when a HID device is inserted, it detects everything automatically and when a HID device is inserted, it
detects it appropriately. detects it appropriately.
...@@ -123,30 +123,30 @@ detects it appropriately. ...@@ -123,30 +123,30 @@ detects it appropriately.
device that doesn't work well. In that case #define DEBUG at the beginning device that doesn't work well. In that case #define DEBUG at the beginning
of hid-core.c and send me the syslog traces. of hid-core.c and send me the syslog traces.
3.1.2 usbmouse.o 3.1.2 usbmouse
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
For embedded systems, for mice with broken HID descriptors and just any For embedded systems, for mice with broken HID descriptors and just any
other use when the big hid.o wouldn't be a good choice, there is the other use when the big usbhid wouldn't be a good choice, there is the
usbmouse.c driver. It handles USB mice only. It uses a simpler HIDBP usbmouse driver. It handles USB mice only. It uses a simpler HIDBP
protocol. This also means the mice must support this simpler protocol. Not protocol. This also means the mice must support this simpler protocol. Not
all do. If you don't have any strong reason to use this module, use hid.o all do. If you don't have any strong reason to use this module, use usbhid
instead. instead.
3.1.3 usbkbd.o 3.1.3 usbkbd
~~~~~~~~~~~~~~ ~~~~~~~~~~~~
Much like usbmouse.c, this module talks to keyboards with a simplified Much like usbmouse, this module talks to keyboards with a simplified
HIDBP protocol. It's smaller, but doesn't support any extra special keys. HIDBP protocol. It's smaller, but doesn't support any extra special keys.
Use hid.o instead if there isn't any special reason to use this. Use usbhid instead if there isn't any special reason to use this.
3.1.4 wacom.o 3.1.4 wacom
~~~~~~~~~~~~~ ~~~~~~~~~~~
This is a driver for Wacom Graphire and Intuos tablets. Not for Wacom This is a driver for Wacom Graphire and Intuos tablets. Not for Wacom
PenPartner, that one is handled by the HID driver. Although the Intuos and PenPartner, that one is handled by the HID driver. Although the Intuos and
Graphire tablets claim that they are HID tablets as well, they are not and Graphire tablets claim that they are HID tablets as well, they are not and
thus need this specific driver. thus need this specific driver.
3.1.5 iforce.o 3.1.5 iforce
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
A driver for I-Force joysticks and wheels, both over USB and RS232. A driver for I-Force joysticks and wheels, both over USB and RS232.
It includes ForceFeedback support now, even though Immersion It includes ForceFeedback support now, even though Immersion
Corp. considers the protocol a trade secret and won't disclose a word Corp. considers the protocol a trade secret and won't disclose a word
...@@ -157,8 +157,8 @@ about it. ...@@ -157,8 +157,8 @@ about it.
Event handlers distrubite the events from the devices to userland and Event handlers distrubite the events from the devices to userland and
kernel, as needed. kernel, as needed.
3.2.1 keybdev.o 3.2.1 keybdev
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
keybdev is currently a rather ugly hack that translates the input keybdev is currently a rather ugly hack that translates the input
events into architecture-specific keyboard raw mode (Xlated AT Set2 on events into architecture-specific keyboard raw mode (Xlated AT Set2 on
x86), and passes them into the handle_scancode function of the x86), and passes them into the handle_scancode function of the
...@@ -170,13 +170,13 @@ it. ...@@ -170,13 +170,13 @@ it.
best if keyboard.c would itself be an event handler. This is done in best if keyboard.c would itself be an event handler. This is done in
the input patch, available on the webpage mentioned below. the input patch, available on the webpage mentioned below.
3.2.2 mousedev.o 3.2.2 mousedev
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
mousedev is also a hack to make programs that use mouse input mousedev is also a hack to make programs that use mouse input
work. It takes events from either mice or digitizers/tablets and makes work. It takes events from either mice or digitizers/tablets and makes
a PS/2-style (a la /dev/psaux) mouse device available to the a PS/2-style (a la /dev/psaux) mouse device available to the
userland. Ideally, the programs could use a more reasonable interface, userland. Ideally, the programs could use a more reasonable interface,
for example evdev.o for example evdev
Mousedev devices in /dev/input (as shown above) are: Mousedev devices in /dev/input (as shown above) are:
...@@ -207,8 +207,8 @@ program reading the data wishes. You can set GPM and X to any of ...@@ -207,8 +207,8 @@ program reading the data wishes. You can set GPM and X to any of
these. You'll need ImPS/2 if you want to make use of a wheel on a USB these. You'll need ImPS/2 if you want to make use of a wheel on a USB
mouse and ExplorerPS/2 if you want to use extra (up to 5) buttons. mouse and ExplorerPS/2 if you want to use extra (up to 5) buttons.
3.2.3 joydev.o 3.2.3 joydev
~~~~~~~~~~~~~~ ~~~~~~~~~~~~
Joydev implements v0.x and v1.x Linux joystick api, much like Joydev implements v0.x and v1.x Linux joystick api, much like
drivers/char/joystick/joystick.c used to in earlier versions. See drivers/char/joystick/joystick.c used to in earlier versions. See
joystick-api.txt in the Documentation subdirectory for details. As joystick-api.txt in the Documentation subdirectory for details. As
...@@ -223,8 +223,8 @@ on: ...@@ -223,8 +223,8 @@ on:
And so on up to js31. And so on up to js31.
3.2.4 evdev.o 3.2.4 evdev
~~~~~~~~~~~~~ ~~~~~~~~~~~
evdev is the generic input event interface. It passes the events evdev is the generic input event interface. It passes the events
generated in the kernel straight to the program, with timestamps. The generated in the kernel straight to the program, with timestamps. The
API is still evolving, but should be useable now. It's described in API is still evolving, but should be useable now. It's described in
......
...@@ -182,7 +182,7 @@ they're basically souped up CHF sticks. ...@@ -182,7 +182,7 @@ they're basically souped up CHF sticks.
For other joystick types (more/less axes, hats, and buttons) support For other joystick types (more/less axes, hats, and buttons) support
you'll need to specify the types either on the kernel command line or on the you'll need to specify the types either on the kernel command line or on the
module command line, when inserting analog.o into the kernel. The module command line, when inserting analog into the kernel. The
parameters are: parameters are:
analog.map=<type1>,<type2>,<type3>,.... analog.map=<type1>,<type2>,<type3>,....
...@@ -503,7 +503,7 @@ and the /dev/input/jsX device should become usable. ...@@ -503,7 +503,7 @@ and the /dev/input/jsX device should become usable.
3.21 I-Force devices 3.21 I-Force devices
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
All I-Force devices are supported by the iforce.o module. This includes: All I-Force devices are supported by the iforce module. This includes:
* AVB Mag Turbo Force * AVB Mag Turbo Force
* AVB Top Shot Pegasus * AVB Top Shot Pegasus
......
...@@ -21,7 +21,7 @@ config USB_HID ...@@ -21,7 +21,7 @@ config USB_HID
If unsure, say Y. If unsure, say Y.
To compile this driver as a module, choose M here: the 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" comment "Input core support is needed for USB HID input layer or HIDBP support"
depends on USB && INPUT=n depends on USB && INPUT=n
......
...@@ -3,32 +3,32 @@ ...@@ -3,32 +3,32 @@
# #
# Multipart objects. # Multipart objects.
hid-objs := hid-core.o usbhid-objs := hid-core.o
# Optional parts of multipart objects. # Optional parts of multipart objects.
ifeq ($(CONFIG_USB_HIDDEV),y) ifeq ($(CONFIG_USB_HIDDEV),y)
hid-objs += hiddev.o usbhid-objs += hiddev.o
endif endif
ifeq ($(CONFIG_USB_HIDINPUT),y) ifeq ($(CONFIG_USB_HIDINPUT),y)
hid-objs += hid-input.o usbhid-objs += hid-input.o
endif endif
ifeq ($(CONFIG_HID_PID),y) ifeq ($(CONFIG_HID_PID),y)
hid-objs += pid.o usbhid-objs += pid.o
endif endif
ifeq ($(CONFIG_LOGITECH_FF),y) ifeq ($(CONFIG_LOGITECH_FF),y)
hid-objs += hid-lgff.o usbhid-objs += hid-lgff.o
endif endif
ifeq ($(CONFIG_THRUSTMASTER_FF),y) ifeq ($(CONFIG_THRUSTMASTER_FF),y)
hid-objs += hid-tmff.o usbhid-objs += hid-tmff.o
endif endif
ifeq ($(CONFIG_HID_FF),y) ifeq ($(CONFIG_HID_FF),y)
hid-objs += hid-ff.o usbhid-objs += hid-ff.o
endif endif
obj-$(CONFIG_USB_AIPTEK) += aiptek.o obj-$(CONFIG_USB_AIPTEK) += aiptek.o
obj-$(CONFIG_USB_ATI_REMOTE) += ati_remote.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_KBD) += usbkbd.o
obj-$(CONFIG_USB_KBTAB) += kbtab.o obj-$(CONFIG_USB_KBTAB) += kbtab.o
obj-$(CONFIG_USB_MOUSE) += usbmouse.o obj-$(CONFIG_USB_MOUSE) += usbmouse.o
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment