Device detection and information retrieval

The device publishers update device information in PPS objects when users attach or detach devices. Your applications can read this information and use it to access media content and decide what to synchronize and play.

The interaction between these components proceeds as shown here:

Multimedia architecture diagram with device components highlighted and their order of interaction enumerated
Figure 1. Device Monitoring and Information Retrieval
  1. Detecting device attachments

    Device publishers don't physically detect when users attach or detach devices. Other OS-layer processes—device drivers and protocol stacks—monitor I/O hardware for physical state changes that indicate device attachments or detachments (e.g., SD card insertions or USB device connections). Because they interface with hardware, the drivers and stacks contain up-to-date details on the physical connectivity and mountpoints of devices. The publishers must communicate with these other processes to learn of device attachments and detachments.

  2. Obtaining device information

    Different publishers use different methods for obtaining the latest device information. The usblauncher publisher queries the io-usb process for device information (for details, see "The usblauncher Service" in the Device Publishers Programmer's Guide). The mmcsdpub and cdpub publishers monitor specific /dev paths and when they notice updated entries, they communicate with the drivers to obtain device information (for details, see "Role of device drivers and mcd").

  3. Publishing device, driver, and filesystem information to PPS

    After retrieving information about newly attached devices from other OS processes, the publishers output this information in text format to PPS objects. Each object stores information that describes a single device. Also, the publishers use different object types for storing device connectivity, driver process, and filesystem information, as explained in the "PPS object types" section in the device publisher documentation.

    When publishers learn from a driver or protocol stack process that a device has been detached, they delete the PPS objects related to that device.

  4. Detecting devices from media applications

    Before your applications can synchronize or play any media, they must learn which devices (or mediastores) are attached to your system. Your applications must monitor the device-related PPS objects to readily receive information about newly attached devices. This information includes the mountpoints, which your applications can use to explore the mediastore filesystems to identify and access media tracks.

    For example, when a USB device is inserted, its default mountpoint is /fs/usb0. The publisher that monitors USB device attachments and removals (usblauncher) writes this mountpoint information to a PPS object in /pps/qnx/mount/.

    Other information fields can help you enforce media policies. For instance, suppose that you want to restrict playback to certain types of mediastores. By examining the media_type attribute, your application can choose to play tracks on some device types (say, audio CDs) but ignore tracks on other device types (say, DVDs).

    For more details on detecting mediastores from an application, see the first two steps described in the "Synchronizing media content from applications" section in the Multimedia Synchronizer Developer's Guide.