USB Administration Guide

Chapter 1 USB Devices (Overview)

This chapter provides an overview of managing USB devices in the Solaris environment.

This is a list of the overview information in this chapter.

For general information about device management in Solaris, see “Device Management (Overview)” in System Administration Guide, Volume 1.

Overview of USB Devices

Universal Serial Bus (USB) was developed by the PC industry to provide a low-cost solution for attaching peripheral devices, such as keyboards, mouse devices, and printers, to a system.

USB connectors are designed to fit only one type of cable, one way. Devices can connect to hub devices, which connect several devices, including other hub devices. The primary design motivation for USB is to alleviate the need for multiple connector types for different devices, thereby reducing the clutter on the back panel of a system. Additional advantages of using USB devices are:

Sun Microsystems support for USB devices includes the following:

This table provides a listing of specific USB devices that are supported in the Solaris environment.

These USB Devices 

Are Supported on These Systems 

Keyboards and mouse devices 

SPARC systems with Sun USB support based on the ohci(7D) controller.

IA systems with a USB bus based on the uhci(7D) controller.

Only onboard USB controllers are supported. Plug-in host controller PCI cards are not supported. 

Mass storage  

SPARC and IA. 


SPARC and IA. 


SPARC and IA. 

Commonly Used USB Acronyms

The following table describes the USB acronyms that are used in the Solaris environment. See for a complete description of USB components and acronyms.




Universal Serial Bus 


Universal Serial Bus Architecture (Solaris) 


USBA Client Driver Interface (Solaris) 


USB host controller driver 

USB Bus Description

The USB specification is openly available and free of royalties. The specification defines the electrical and mechanical interfaces of the bus and the connectors.

Figure 1–1 USB Physical Device Hierarchy


USB employs a topology in which hubs provide attachment points for USB devices. The host controller contains the root hub, which is the origin of all USB ports in the system. See USB Hub Devices for more information about hubs.

The previous example shows a system with three active USB ports. The first USB port has a Zip drive that does not have an embedded hub, so you cannot attach additional devices. The second USB port has a hub with a Jaz drive and a composite keyboard/mouse device connected. One of the ports from the secondary hub has a keyboard with an embedded hub where the mouse is attached.

The device tree path name for some of the devices that are displayed in the previous example are listed in this table.

Zip drive 






Jaz drive 




USB Devices and Drivers

The USB devices are divided into device classes. Each device class has a corresponding driver. Devices within a class are managed by the same device driver. However, the USB specification also allows for vendor-specific devices that are not part of a specific class. Devices with similar attributes and services are grouped.

The Human Interface Device (HID) class contains devices that are user controlled such as keyboards, mouse devices, and joysticks. The Communication Device class contains devices that connect to a telephone, such as modems or an ISDN interface. Other device classes include the Audio, Monitor, Printer, and Storage Device classes. Each USB device contains descriptors that reflect the class of the device. A device class specifies how its members should behave in configuration and data transfer. You can obtain additional class information from the site.

Solaris USB Architecture (USBA)

USB devices are represented as two levels of device tree nodes. A device node represents the entire USB device, and one or more child interface nodes represent the individual USB interfaces on the device. For special cases, the device and interface nodes are combined into a single combined node.

Driver binding is achieved by using the compatible name properties. Refer to of the IEEE 1275 USB binding and Writing Device Drivers for more information. A driver can either bind to the entire device and control all the interfaces, or a driver can bind to just one interface, for example, a keyboard or mouse. If no vendor or class driver claims the entire device, a generic USB multi-interface driver is bound to the device-level node. This driver attempts to bind drivers to each interface by using compatible names properties, as defined in section of the 1275 binding.

Figure 1–1 shows an example of a hub and printer as a compound device. Both the hub and the printer are enclosed in the same plastic case, but the hub and the printer have separate USB bus addresses. The same diagram shows an example of a composite device. The composite keyboard and controller are also enclosed in the same plastic case, but they have the same USB bus address. A cable connects the USB mouse to the composite keyboard/controller in this example.

The Solaris USB Architecture (USBA) adheres to the USB 1.0 and 1.1 specification plus Solaris driver requirements. The USBA model is similar to Sun Common SCSI Architecture (SCSA). The USBA is a thin layer that provides a generic USB transport-layer abstraction to the client driver.

The differences between SCSA and USBA are that the SCSA relies on .conf files to probe the bus, while USB hub drivers are self-probing nexus drivers.

About USB in the Solaris Environment

The following sections describe specific information you should know about USB in the Solaris environment.

USB Keyboards and Mouse Devices

Keep only one USB keyboard and mouse on the system at all times because multiple USB keyboards and mouse devices are not supported in the Solaris environment. See the following items for specific details.

USB Host Controller and Root Hub

A USB hub is responsible for:

The USB host controller has an embedded hub called the root hub. The ports that are visible at the back panel are the ports of the root hub. The USB host controller is responsible for:

USB Hub Devices

USB Storage Devices

Removable mass storage devices such as USB Zip, Jaz, Clik!, SmartMedia, CompactFlash, and ORB are supported, starting with the Solaris 8 10/00 release. See scsa2usb(7D) for a complete list of devices that are supported in the Solaris environment.

These devices can be managed with or without volume management. See vold(1M) for information on managing devices with volume management.

SPARC Only: USB Power Management

If the system has enabled power management, the USB framework makes a best effort to power-manage all devices. Power-managing a USB device means the hub driver suspends the port to which the device is connected. The device might or might not support remote wakeup. If the device supports remote wakeup, it wakes up the hub it is connected to, depending on the event, such as moving the mouse. The host system could also wake the device if an application sends an I/O to it.

All HID (keyboard, mouse, and so forth), hub, and storage devices are power-managed by default if they support the remote wakeup capability. A USB printer is power-managed only between two print jobs.

When you power-manage to reduce power consumption, USB leaf devices are powered down first, and after some delay, the parent hub is powered down. When all devices that are connected to this hub's ports are powered down, the hub is powered down after some delay. To achieve the most efficient power management, do not cascade many hubs.

Hot-Plugging USB Devices

When you plug in a USB device, the device is immediately seen in the system's device hierarchy, as displayed in the prtconf(1M) command output. When you remove a USB device, the device is removed from the system's device hierarchy, unless the device is in use.

If the USB device is in use when it is removed, the hot-plug behavior is a little different. If a device is in use when it is unplugged, the device node remains, but the driver controlling this device stops all activity on the device. Any new I/O activity issued to this device is returned with an error.

In this situation, the system prompts you to plug in the original device. To recover from accidentally removing a busy USB device, do the following:

  1. Plug the original device into the same port.

  2. Stop the application that is using the device.

  3. Remove the device.

The USB port remains unusable until the original device has been plugged in again. If the device is no longer available, the port remains unusable until the next reboot.

Note –

Data integrity might be impaired if you remove an active or open device. Always close the device before removing, except the console keyboard and mouse, which can be moved while active.

USB Cables

Never use USB cable extenders that are available in the market. Always use a hub with longer cables to connect devices. Always use fully rated (12 Mbit/sec) 20/28 AWG cables for connecting USB devices.

USB Printer Support

You can use Solaris Print Manager to set up a USB printer that is attached to a SPARC system with USB ports, starting with the Solaris 8 10/00 release. You can also set up USB printers on IA systems, starting with the Solaris 8 04/01 release.

The new logical device names for USB printers are:


Therefore, when you add a USB printer to a printer server, select one of these devices for a USB printer under Printer Port on the Add New Attached Printer screen. See the System Administration Guide, Volume 2 for more information on using Solaris Print Manager to set up printers.

Although the new Solaris USB printer driver supports all USB printer-class compliant printers, a list of recommended PostScriptTM printers is in the usbprn(7D) man page.

The usbprn driver is compliant with non-PostScript printers that utilize third-party PostScript conversion packages like GhostScript. You can obtain conversion packages from the Solaris 8 Software Companion CD, available at

Refer to the Notes and Diagnostics sections of the usbprn(7D) man page for information and cautions about hot-plugging USB printers.