The uhidd services

# The `uhidd` services

## Application note

This describes how the uhidd service is run, on the presumption that one wants to run a uhidd service. It is, however, not necessary to have uhidd if one is using a `console-usb-ugen-realizer@ugenN.M` service bundle running `console-ugen-hid-realizer` to realize a USB Human Interface Device onto a virtual terminal, and doing so will lead to poorer functionality as `console-ugen-hid-realizer` can recognize and handle consumer control keys and other things natively without need to translate them into other input forms.

## Old behaviour under Mewburn `rc`

In response to a rule in `/usr/local/etc/devd/uhidd-devd.conf`, the Plug and Play manager starts individual uhidd processes on demand as `ugen` devices appear.

The `rc` system has a `uhidd_enabled` flag, that causes autostart of uhidd services on every `ugen` device that lives in `/dev` at that point in the bootstrap.

## How this system handles things

In response to a rule in `/usr/local/etc/devd/hidd-nosh.conf`, the Plug and Play manager (if necessary) generates, presets, and resets individual uhidd service bundles on demand as `ugen` devices appear. Each of these launches a `uhidd` dæmon against the given `ugen` device, and is individually startable, parameterized via its private environment directory, and enabled just like any other service. When the devices disappear, in response to the same ruleset the Plug and Play manager stops the services.

These service bundles live in the `/run/service-bundles/` tree, and are not persistent across system restarts. When enabled, they are wanted by a generated `uhidd` target located in the same tree.