Manual Reference Pages - UHIDD (8)
- USB HID daemon
daemon handles USB HID devices like mouse, keyboard etc. in userland using
the libusb20 library.
daemon is intended to handle USB HID devices with multiple logical
devices sharing one endpoint, usually that is multiple application
collections inside one interface. The daemon attaches interface driver
to each HID interface of the ugen%u.%u device and attaches class
drivers to application collections found inside that
inteface. Interface driver receive data through the shared interrupt
endpoint and pass it to the right class driver instance. The class
driver then process the data as approriate.
There are currently 4 HID class driver available: Mouse driver,
Keyboard driver, Consumer Control driver and Virutal Generic HID
The Mouse driver extracts mouse input data from mouse application
collection and pass the mouse event to the console driver to
make it available to the text console and user programs.
driver creates a
virtual keyboard, extracts keyboard HID input report from keyboard
application collection, translates the HID codes to key scancodes
and passes the scancodes to the
Control class driver is basically a special keyboard driver that
handles multimedia keys found on USB keyboard. It translates
consumer page usage
(USB multimedia keys)
to unassigned or rarely used keycodes. See
for how to configure the keymap. If a multimedia keymap is not found
in the configuration for a USB keyboard, The driver
will create a in-memory keymap and assigns keycodes automatically
when multimedia keys are pressed. This in-memory keymap will also
be stored in
and can be copy-pasted into configuration file so the driver can
load the keymap directly next time.
All other HID application collections that dont
have a specific driver can be attached by the Virtual Generic HID
class driver. The driver creates a virtual USB HID device using
interface, so normal USB HID applications that deal with
could access the data through the virutal interface.
daemon supports the following options:
Specify the path to the configuration file. The default path
Dump HID device report descriptor in human readable form.
This option implies
Do not detach from the controlling terminal, i.e., run in
foreground. This option is intended for debugging the daemon.
Attach the Virtual Generic HID class driver.
This option requires that
driver loaded as a kernel module.
Specify the name of the virtual HID device created by the
virtual generic HID driver. The default name used for the device is
Attach Keyboard class driver. This option requires that
compiled in the kernel or loaded as a kernel module,
and that the keyboard multiplexer
Attach Mouse class driver.
Attach Consumer Control class driver.
Instruct the Virtual Generic HID driver to strip the report ID byte
from the hid report data. This is needed if the hid application is
parser to parse the data read from the simulated
When this option is specified, if there is an active kernel
driver attached to the device interface, the
daemon will try to detach the active kernel driver first, before
attaching itself to the device.
This option is easpecially useful when there is no easy way to
unload the kernel USB HID device drivers.
If this option is not present and the
daemon finds out the device is already attached by a kernel
driver, it will abort and let the kernel driver continue handling
Output the version of
daemon to stderr and exit.
Output additional information for debugging purpose. Multiple
specified in the command line will increase the level of the
verbosity. This option implies
There are more options that can be configured through
daemon can coexist with the kernel USB HID drivers for keyboard, mouse etc.
When the daemon starts, if it detects there is an active kernel driver
already attached to the device, it will abort gracefully. If the option
is specified or the configuration option
is applicable for the device, it will attempt to detach the kernel driver
first before attaching itself to the device.
However note that if the kernel USB HID drivers are compiled as kernel
modules and are not yet loaded at the point when the device is attached
to the system, the
daemon will attach itself to the device first, and the kernel driver will
be loaded and attached to the device after. As a result, both
daemon and the kernel driver will attach to the device at the same time,
which causes undefined behaviours.
To overcome this problem, when the kernel drivers are compiled as modules,
rules listed in the
config file for the relevant USB HID kernel modules should be removed.
the default name of the configuration file
process id of the currently running
daemon that attached to device ugen.%u.%u
the in-memory multimedia keymap for device ugen.%u.%u
There are additional instructions and setup examples in the web page:
daemon was written by
.An Kai Wang Aq kaiw@FreeBSD.org ,
based on the work done by many others.
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.