The USB Launcher Service

The USB launcher service (usblauncher_otg) processes USB device attachments and detachments, launches drivers for communicating with devices, and publishes device information through PPS. The service can also force a re-enumeration of a device, by resetting it or by requesting it to disconnect and change its personality.

The USB launcher service depends on the following services:
io-usb-otg
The USB stack, io-usb-otg, manages the USB bus and USB protocols through hardware controller drivers. The stack monitors the USB hardware and notifies the USB launcher service of device attachments and detachments. The stack can run in either USB host mode or USB device mode.
Drivers for USB device mode
When the user inserts a USB device, the USB stack notifies the USB launcher, which immediately starts the appropriate driver based on the device properties provided by the stack. For instance, the devc-serusb_dcd driver enables serial data transfer, and the devu-umass_client-block driver supports mass storage devices. Other drivers that may be used in device mode include mm-ipod, io-pkt with usbdnet, and others.
Drivers for USB host mode
When the USB stack is acting as a USB host, the USB launcher service can start different drivers to communicate with different types of devices. The simplest example is when a user plugs in a mass-storage device, in which case, USB launcher starts a devb-umass driver to communicate with it; if a device has multiple partitions, one such driver manages all of the device's filesystems. Other drivers that may be used in host mode include mm-ipod, io-pkt with a USB Ethernet driver, devc-serusb, and others.

Benefits of USB launcher

The multipurpose USB launcher service allows for a simple system setup and provides these benefits:
Drivers can be started immediately
Because the service launches the USB drivers, it knows immediately whether a newly attached device is supported (i.e., if the target system has a suitable driver for the device's type). Thus, when creating a PPS device object, USB launcher can publish the number of drivers that it will start for the device; this lets applications subscribed to this PPS object know right away whether the device is supported.
Automatic filesystem mounting
The USB launcher service can mount the filesystems of USB devices based on the mount rules specified in a file (default is /etc/usblauncher/rules.mnt). The service can also publish the status of mount operations to inform applications whether individual device filesystems were successfully mounted.
Support for accessory mode
Many smartphones now come with software that allows them to connect with another system that acts as an accessory; end-users can then use the accessory to launch and interact with smartphone apps. For instance, if you're building a car infotainment system, you may want to let vehicle occupants access smartphone features through the infotainment system's display. Together with add-ons available for the QNX CAR Platform for Infotainment, the USB launcher service can:
  • accept a command from a client application to ask an Android device to enable its Android Open Accessory (AOA) interface, so users can play media and access smartphone features from the target
  • check whether an Apple device supports the iPod Accessory Protocol 2 (iAP2) and, if so, request that the device switch to USB host mode and role-swap the USB stack on the target to device mode, which supports Apple CarPlay and client-mode iAP2
  • support the MirrorLink solution for accessing smartphone features, by requesting that a device switch to a Network Configuration Management (NCM) personality

Architecture


Architectural diagram showing usblauncher_otg and the components it uses to monitor USB devices, retrieve device information, and publish that information through PPS
Figure 1. Basic architecture of USB launcher service

The USB launcher service relies on the USB stack to learn about changes in device states, as illustrated in Figure 1 (here, the arrows show information flow). When USB devices are attached or detached, they trigger hardware interrupts that the running stack (io-usb-otg) detects. When the stack learns that a device has been attached, it enumerates the new device and notifies USB launcher.

The USB launcher service queries the stack to retrieve the descriptors (properties) of any newly attached devices and compares these descriptors against the USB matching rules in its configuration file. When it finds a match, the service performs the specified follow-up actions. Often, this involves launching drivers and publishing device, driver, and mountpoint information through PPS.

To mount filesystems, the USB launcher service sends mount requests to the drivers that manage the USB device paths. The mountpoints requested by the service are based on the rules in the specified mount-rules file (for details, see the section on mounting filesystems).

Subscribed applications receive updates through PPS when device information changes, so they can learn when devices are reconfigured or removed.

Note: We recommend that your applications open the PPS objects in delta mode, to read only the changed attributes. When a new device is detected and a driver is launched for it, the PPS objects are updated frequently. Using delta mode ensures that client applications don't read identical attribute values many times, as explained in the Delta mode section of the Persistent Publish/Subscribe Developer's Guide.