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.