Chapter 28 Using USB Devices (Overview/Tasks)

This chapter provides an overview of Universal Serial Bus (USB) devices and step-by-step instructions for using USB devices in the Solaris environment.

For information on the procedures associated with using USB devices, see the following:

• Using USB Mass Storage Devices (Task Map)

• Using USB Audio Devices (Task Map)

• Hot-Plugging USB Devices With the cfgadm Command (Task Map)

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

• Overview of USB Devices

• About USB in the Solaris Environment

• Using USB Mass Storage Devices

• Hot-Plugging USB Devices

• Using USB Audio Devices

• Troubleshooting USB Audio Device Problems

• Hot-Plugging USB Devices With the cfgadm Command

For general information about dynamic reconfiguration and hot-plugging, see Chapter 27, Dynamically Configuring Devices (Tasks).

For information on configuring USB printers, see “What's New in Printing?” in System Administration Guide: Advanced Administration.

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 was to alleviate the need for multiple connector types for different devices. This design reduces the clutter on the back panel of a system. Additional advantages of using USB devices are as follows:

• USB devices are hot-pluggable. For more information, see Hot-Plugging USB Devices.

• Supports a maximum of 126 devices per host controller in the Solaris environment.

• Supports a maximum of 12 Mbit/sec data transfer.

• Supports low speed (1.5 Mbit/sec) and full speed (12 Mbit/sec) devices.

• Supports Solaris Ready USB PCI controllers. For more information, see http://www.sun.com/io.

• The bus can be easily extended by adding low-cost external hubs. Hubs can be connected to hubs to form a tree topology.

Sun Microsystems support for USB devices includes the following:

• USB 1.1 devices are supported in the Solaris 9 environment.

• Sun Blade^TM 100 and Sun Blade 1000 systems that run the Solaris 8 10/00, 1/01, 4/01, 7/01, 10/01, 2/02 and the Solaris 9 releases provide USB device support.

• Netra^TM X1/T1 and Sunfire 280R systems that run the Solaris 9 release.

• IA based systems that run the Solaris 8 and Solaris 9 Intel Platform Editions provide USB support also. For more information, see scsa2usb(7D).

This table lists specific USB devices that are supported in the Solaris environment.

Commonly Used USB Acronyms

The following table describes the USB acronyms that are used in the Solaris environment. For a complete description of USB components and acronyms, go to http://www.usb.org.

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.

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. For more information about hubs, see USB Host Controller and Root Hub.

Figure 28–1 USB Physical Device Hierarchy

Figure 28–1 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 and mouse device connected. One port from the secondary hub has a keyboard with an embedded hub where the mouse is attached.

Figure 28–1 also 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 mouse device 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 figure.

The device tree path name for some of the devices that are displayed in Figure 28–1 are listed in this table.

USB Devices and Drivers

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 http://www.usb.org site.

Solaris USB Architecture (USBA)

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

Driver binding is achieved by using the compatible name properties. For more information, refer to 3.2.2.1 of the IEEE 1275 USB binding and Writing Device Drivers. 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 3.3.2.1 of the 1275 binding.

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

This section describes information you should know about USB in the Solaris environment.

USB Keyboards and Mouse Devices

Only Sun USB keyboards and mouse devices are officially supported. Additionally, 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 details.

• A keyboard and mouse that are connected anywhere on the bus are configured as a console keyboard and mouse. Booting the system is slower if the keyboard and mouse are not on the root hub.

• You can move a console keyboard and mouse to another hub at any time after a system reboot. You cannot move a console keyboard and mouse during a reboot or at the ok prompt. After you plug in a keyboard and mouse, they are fully functional again.

• SPARC – The power key on a USB keyboard behaves differently than the power key on the Sun type 5 keyboard. On a USB keyboard, you can suspend or shut down the system by using the SUSPEND/SHUTDOWN key, but you cannot power up the system.

• The keys just to the left of the keypad do not function on third-party USB keyboards.

• Multiple keyboards are not supported:

  • Multiple keyboards enumerate and are usable, but they are not plumbed as console keyboards.

  • The first keyboard that is probed at boot time becomes the console keyboard. The result of this probing might cause confusion if multiple keyboards are plugged in at boot time.

  • If you unplug the console keyboard, the next available USB keyboard does not become the console keyboard. The next hot-plugged keyboard becomes the console keyboard.

• Multiple mouse devices are not supported:

  • Multiple mouse devices enumerate and are usable, but they are not plumbed as console mouse devices.

  • The first mouse that is probed at boot time becomes the console mouse. The result of this probing might cause confusion if you have multiple mouse devices plugged in at boot time.

  • If you unplug the console mouse, the next available USB mouse does not become the console mouse. The next hot-plugged mouse becomes the console mouse.

• If you have a third-party composite keyboard with a PS/2 mouse, and the composite keyboard/mouse is the first one to be probed, it becomes the console keyboard/mouse even if the PS/2 mouse is not plugged in. Thus, another USB mouse plugged into the system cannot work because it is not configured as the console mouse.

• Only two-button and three-button mouse devices are supported. A wheel-on-wheel mouse acts like a plain-button mouse. A mouse with more than three buttons functions like a three–button mouse.

USB Host Controller and Root Hub

A USB hub is responsible for the following:

• Monitoring the insertion or removal of a device on its ports

• Power-managing individual devices on its ports

• Controlling power to its ports

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

• Directing the USB bus. Individual devices cannot arbitrate for the bus.

• Polling the devices by using a polling interval that is determined by the device. The device is assumed to have sufficient buffering to account for the time between the polls.

• Sending data between the USB host controller and its attached devices. Peer-to-peer communication is not supported.

USB Hub Devices

• Do not cascade hubs beyond four levels on either SPARC based or IA based systems. On SPARC systems, the OpenBoot^TM PROM cannot reliably probe beyond four levels of devices.

• Do not cascade bus-powered hubs. So, you cannot plug a bus-powered hub into another bus-powered hub. A bus-powered hub does not have its own power supply. A USB diskette device derives all its power from the bus and might not work on a bus-powered hub.

SPARC: USB Power Management

Suspending and resuming USB devices are fully supported on SPARC systems. However, do not suspend a devices that is busy and never remove a device when the system is powered off.

If the SPARC based system has power management enabled, the USB framework makes a best effort to power-manage all devices. Power-managing a USB device means that 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 up the device if an application sends an I/O to the device.

All HID (keyboard, mouse, speakers, microphones), hub, and storage devices are power-managed by default if they support 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. Then, 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.

Guidelines for 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.

Using USB Mass Storage Devices (Task Map)

Using USB Mass Storage Devices

Removable mass storage devices such as USB CD-RWs, disks, DVDs, digital cameras, Zip, Jaz, Clik!, SmartMedia, CompactFlash, and ORB are supported, starting with the Solaris 9 release.

For a complete list of USB devices that are supported in the Solaris environment, see http://www.sun.com/io_technologies/storagesolutions.html.

These devices can be managed with or without volume management. For information on managing devices with volume management, see vold(1M).

Using Non-Compliant USB Mass Storage Devices

If you connect a USB mass storage device to a system running the Solaris 9 release and the system is unable to use it, you can check the /kernel/drv/scsa2usb.conf file to see if there is a matching, commented entry for this device. For a listing of recommended USB mass storage devices, go to http://www.sun.com/io.

Some devices might be supported by the USB mass storage driver even though they do not identify themselves as compliant with the USB mass storage class or identify themselves incorrectly. The scsa2usb.conf file contains an attribute-override-list that lists the vendor ID, product ID, and revision for matching mass storage devices, as well as fields for overriding the default device attributes. The entries in this list are commented out by default, and can be copied and uncommented to enable support of particular devices.

Follow the information given in the scsa2usb.conf file to see if a particular device can be supported by using the override information.

For more information, see scsa2usb(7D).

Hot-Plugging USB Devices

Hot-plugging a device means the device is added or removed without shutting down the operating system or powering off the system.

When you hot-plug a USB device, the device is immediately seen in the system's device hierarchy, as displayed in the prtconf 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.

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.

How to Add a Hot-Pluggable USB Mass Storage Device With vold Running

This procedure describes how to add a hot-pluggable USB device with vold running.

1. Insert the USB mass storage device.

2. Restart vold.

   # pkill -HUP vold

3. Verify that the device has been added.

   $ ls device-alias

How to Add a Hot-Pluggable USB Mass Storage Device Without vold Running

This procedure describes how to add a hot-pluggable USB device without vold running.

1. Add a hot-pluggable USB device into the USB port.

2. Verify that the USB device has been added.

   $ ls /dev/rdsk/cntndnsn

How to Remove a Hot-Pluggable USB Mass Storage Device With vold Running

The following procedure uses a Zip drive as an example of removing a hot-pluggable USB device with vold running.

1. Unmount the device.

   $ volrmmount -e zip0

2. Stop any active applications that are using the device.

3. Eject the device.

   $ eject zip0

4. Become superuser and stop vold.

   # /etc/init.d/volmgt stop

5. Remove the USB mass storage device.

6. Start vold.

   # /etc/init.d/volmgt start

How to Remove a Hot-Pluggable USB Mass Storage Device Without vold Running

This procedure describes how to remove a hot-pluggable USB device without vold running.

1. Become superuser.

2. Stop any active applications that are using the device.

3. Remove the hot-pluggable USB device.

   1. Unmount the device.

      # umount /mount-point

   2. Remove the device.

Mounting USB Mass Storage Devices With or Without vold Running

If you are running Solaris Common Desktop Environment (CDE), the USB removable mass storage devices are managed by the Removable Media Manager component of the CDE File Manager. For more information on the CDE File Manager, see dtfile(1).

You must include the /usr/dt/man directory in your MANPATH variable to display the man pages that are listed in this section. You must also have the /usr/dt/bin directory in your path and have CDE running to use these commands, or have a DISPLAY variable set to use these commands remotely.

The following table identifies the commands that Removable Media Manager uses to manage storage devices from the CDE environment.

After the USB device is formatted, it is usually mounted under the /rmdisk/label directory. For more information on configuring removable storage devices, see rmmount.conf(4) or vold.conf(4).

The device nodes are created under the /vol/dev directory. For more information, see scsa2usb(7D).

You can use USB mass storage devices without the volume manager (vold) running. Here are two ways to avoid using the volume manager.

• Stop vold by issuing this command:

  # /etc/init.d/volmgt stop

• Keep vold running, but do not register the USB mass storage devices with vold. Remove volume manager registration of USB mass storage devices by commenting the following line in the /etc/vold.conf file, like this:

  # use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d

  After this line is commented, restart vold.

  # /etc/init.d/volmgt start

  ---

  Caution –

  If you comment out this line and other SCSI or ATAPI Zip or Jaz removable devices are in the system, vold registration for these devices would be disabled as well.

  ---

  For more information, see vold.conf(4).

The following procedures describe how to manage USB mass storage devices without vold running. The device nodes are created under the /dev/rdsk directory for character devices and under the /dev/dsk directory for block devices. For more information, see scsa2usb(7D).

How to Mount or Unmount a USB Mass Storage Device With vold Running

1. Display device aliases for all removable mass storage devices, including USB mass storage devices.

   $ eject -n . . . rmdisk0 -> /vol/dev/rdsk/c4t0d0/clik40 (Generic USB storage) cdrom0 -> /vol/dev/rdsk/c0t6d0/audio_cd (Generic CD device) zip1 -> /vol/dev/rdsk/c2t0d0/fat32 (USB Zip device) zip0 -> /vol/dev/rdsk/c1t0d0/zip100 (USB Zip device) jaz0 -> /vol/dev/rdsk/c3t0d0/jaz1gb (USB Jaz device)

2. Mount a USB mass storage device by using the device aliases listed previously.

   $ volrmmount -i device-alias

   This example shows how to mounts USB Jaz drive (/rmdisk/jaz0).

   $ volrmmount -i jaz0

3. Unmount a USB mass storage device.

   $ volrmmount -e device-alias

   This example shows how to unmount a USB Zip drive (/rmdisk/zip0).

   $ volrmmount -e zip0

4. Eject a USB device from a generic USB drive.

   $ eject device-alias

   For example:

   $ eject rmdisk0

   ---

   Note –

   The eject command also unmounts the device if the device is not unmounted already. The command also terminates any active applications that access the device.

   ---

How to Mount or Unmount a USB Mass Storage Device Without vold Running

1. Become superuser.

2. Mount a USB mass storage device.

   # mount -F fs-type /dev/dsk/cntndnsn /mount-point

   This command might fail if the device is read-only. Use the following command for CD-ROM devices.

   # mount -F fs-type -o ro /dev/dsk/cntndnsn /mount-point

   For example:

   # mount -F hsfs -o ro /dev/dsk/c0t6d0s2 /mnt

3. Unmount a USB mass storage device.

   # umount /mount-point

4. Eject the device.

   # eject /dev/[r]dsk/cntndnsn

How to Add a Hot-Pluggable USB Camera

Use this procedure to add a hot-pluggable USB camera.

1. Become superuser.

2. Plug in and turn on the USB camera.

   The USB subsystem and the SCSA subsystem create a logical device for the camera. After the camera is plugged in, output is written to the /var/adm/messages file.

3. Examine the output that is written to the /var/adm/messages file.

   Examining this output enables you to determine what logical device was created so that you can then use that device to access your images. The output will look similar to the following:

   # more /var/adm/messages Jul 15 09:53:35 buffy usba: [ID 349649 kern.info] OLYMPUS, C-3040ZOOM, 000153719068 Jul 15 09:53:35 buffy genunix: [ID 936769 kern.info] scsa2usb1 is /pci@0,0/pci925,1234@7,2/storage@2 Jul 15 09:53:36 buffy scsi: [ID 193665 kern.info] sd3 at scsa2usb1: target 0 lun 0

4. Mount the USB camera file system.

   The camera's file system is most likely a PCFS file system. In order to mount the file system on the device created, the slice that represents the disk must be specified. The slice is normally s0 for a SPARC system, and p0 for an Intel system.

   For example, to mount the file system on an Intel system, execute the following command:

   # mount -F pcfs /dev/dsk/c3t0d0p0:c /mnt

   To mount the file system on a SPARC system, execute the following command:

   # mount -F pcfs /dev/dsk/c3t0d0s0:c /mnt

   For information on mounting file systems, see “Mounting and Unmounting File Systems (Tasks)” in System Administration Guide: Basic Administration.

   For information on mounting different PCFS file systems, see mount_pcfs(1M).

5. Verify that the image files are available.

   For example:

   # ls /mnt/DCIM/100OLYMP/ P7220001.JPG* P7220003.JPG* P7220005.JPG* P7220002.JPG* P7220004.JPG* P7220006.JPG*

6. View and manipulate the image files created by the USB camera.

   # /usr/dt/bin/sdtimage &

7. Unmount the file system before disconnecting the camera.

   For example:

   # umount /mnt

8. Turn off and disconnect the camera.

Using USB Audio Devices (Task Map)

Using USB Audio Devices

This Solaris release provides USB audio support which is implemented by a pair of cooperating drivers, usb_ac and usb_as. The audio control driver, usb_ac, a USBA (Solaris USB Architecture) compliant client driver provides the controlling interface to user applications. The audio streaming driver, usb_as, is provided to process audio data messages during play and record and set sample frequency, precision, and encoding requests from the usb_ac driver.

Both drivers comply to the USB audio class 1.0 specification.

Solaris supports external USB audio devices that are play-only or record-only. Onboard USB audio devices are not supported. For supported audio data format information, see usb_ac(7D).

• Only USB audio devices with one volume, bass, or treble control are supported. See the USB audio class specification for more information at http://www.usb.org.

• USB audio devices are supported on SPARC Ultra and Intel platforms that provide USB connectors.

• Hot-plugging USB audio devices is supported.

• USB audio devices must support a continuous sample rate of between 8000 and 48000 Hz or must support a 48000 Hz sample rate to play or record on the Solaris 8 10/01, Solaris 8 2/02, or Solaris 9 release.

The primary audio device is /dev/audio. You can verify that /dev/audio is pointing to USB audio by using the following command:

% mixerctl
Device /dev/audioctl:
  Name    = USB Audio
  Version = 1.0
  Config  = external

Audio mixer for /dev/audioctl is enabled

After you connect your USB audio devices, you access them with the audioplay and audiorecord command through the following files:

/dev/sound/N

You can select a specific audio device by setting the AUDIODEV environment variable or by specifying the -d option to the audioplay and audiorecord commands. However, setting AUDIODEV does not work for applications that have /dev/audio hardcoded as the audio file.

When you plug in a USB audio device, it automatically becomes the primary audio device, /dev/audio, unless /dev/audio is in use. For instructions on changing /dev/audio from onboard audio to USB audio and vice versa, refer to How to Change the Primary USB Audio Device and usb_ac(7D).

Hot-Plugging Multiple USB Audio Devices

If a USB audio device is plugged into a system, it becomes the primary audio device, /dev/audio. It remains the primary audio device even after the system is rebooted. If additional USB audio devices are plugged in, the last one becomes the primary audio device.

For additional information on troubleshooting USB audio device problems, see usb_ac(7D).

How to Add Hot-Pluggable USB Audio Devices

Use the following procedure to add hot-pluggable USB audio devices.

1. Plug in the USB speakers and microphone.

   The primary audio device, /dev/audio, usually points to the onboard audio. After you connect USB audio devices, /dev/audio points to the USB audio devices that are identified in the /dev/sound directory.

2. Verify that the audio device files have been created.

   % ls /dev/sound 0 0ctl 1 1ctl 2 2ctl

3. Test the left and right USB speakers.

   % cd /usr/share/audio/samples/au % audioplay -d /dev/sound/1 -b 100 spacemusic.au % audioplay -d /dev/sound/1 -b -100 spacemusic.au

4. Test the USB microphone.

   % cd $HOME/au % audiorecord -d /dev/sound/2 -p mic -t 30 test.au

How to Identify Your System's Primary Audio Device

This procedure assumes that you have already connected USB audio devices.

1. Identify the state of your current audio device links.

   For example:

   % ls -lt /dev/audio* lrwxrwxrwx 1 root root 7 Jul 23 15:41 /dev/audio -> sound/0 lrwxrwxrwx 1 root root 10 Jul 23 15:41 /dev/audioctl -> sound/0ctl % ls -lt /dev/sound/* lrwxrwxrwx 1 root other 66 Jul 23 14:21 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root other 69 Jul 23 14:21 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audioctl %

   The primary audio device, /dev/audio, is currently pointing to the onboard audio, which is /dev/sound/0.

2. (Optional) Add a new USB audio device.

3. Examine your system's new audio links.

   For example:

   % ls -lt /dev/audio* lrwxrwxrwx 1 root root 7 Jul 23 15:46 /dev/audio -> sound/1 lrwxrwxrwx 1 root root 10 Jul 23 15:46 /dev/audioctl -> sound/1ctl % ls -lt /dev/sound/* lrwxrwxrwx 1 root root 74 Jul 23 15:46 /dev/sound/1 -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,audio lrwxrwxrwx 1 root root 77 Jul 23 15:46 /dev/sound/1ctl -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,aud... lrwxrwxrwx 1 root other 66 Jul 23 14:21 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root other 69 Jul 23 14:21 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audioctl %

   Notice that the primary audio device, /dev/audio, is pointing to the newly plugged in USB audio device, /dev/sound/1.

   If you remove the USB audio device now, the primary audio device, /dev/audio, does not revert back to the onboard audio. See the following procedure for instructions on changing the primary audio device back to the system's onboard audio.

   You can also examine your system's USB audio devices with the prtconf command and look for the USB device information.

   % prtconf . . . usb, instance #0 hub, instance #0 mouse, instance #0 keyboard, instance #1 device, instance #0 sound-control, instance #0 sound, instance #0 input, instance #0 . . .

How to Change the Primary USB Audio Device

Follow these steps if you remove or change your USB audio devices and you want to make one particular audio device the primary audio device. The procedure changes the primary audio device to the onboard audio device as an example.

1. Become superuser.

2. Close all audio applications.

3. Determine whether the audio and USB drivers are loaded.

   # modinfo | grep -i audio 124 780e6a69 bb6e - 1 audiosup (Audio Device Support 1.12) # modinfo | grep -i usb 48 13dba67 18636 199 1 ohci (USB OpenHCI Driver 1.31) 49 78020000 1dece - 1 usba (USBA: USB Architecture 1.37) 50 12e5f1f 35f 195 1 hubd (USB Hub Driver 1.4) 51 13ef53d 5e26 194 1 hid (USB HID Client Driver 1.16) 54 13f67f2 1b42 10 1 usbms (USB mouse streams 1.6) 56 127bbf0 2c74 11 1 usbkbm (USB keyboard streams 1.17) #

4. Load and attach the onboard audio driver.

   # devfsadm -i audiocs

   The onboard audio driver is audiocs on a Sunblade 1000, and audiots on a Sunblade 100.

5. Verify that the primary audio device link is pointing to the onboard audio.

   # ls -lt /dev/audio* lrwxrwxrwx 1 root other 7 Jul 23 15:49 /dev/audio -> sound/0 lrwxrwxrwx 1 root other 10 Jul 23 15:49 /dev/audioctl -> sound/0ctl # ls -lt /dev/sound/* lrwxrwxrwx 1 root other 66 Jul 23 14:21 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root other 69 Jul 23 14:21 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audioctl #

6. Confirm the onboard audio is the primary audio device.

   % audioplay /usr/demo/SOUND/sounds/bark.au

   The audioplay command defaults to the onboard audio device.

7. (Optional) Unload all the audio drivers that can be unloaded before plugging in another USB audio device.

   1. Close all the audio applications.

   2. Display the audio driver information to verify that no audio drivers are currently loaded.

      # modinfo | grep -i audio 60 78048000 bb6e - 1 audiosup (Audio Device Support 1.12) 61 78152000 39a97 - 1 mixer (Audio Mixer 1.49) 62 78118000 bf9f - 1 amsrc1 (Audio Sample Rate Conv. #1 1.3) 128 7805e000 14968 54 1 audiocs (CS4231 mixer audio driver 1.21) #

   3. Unload the audio drivers.

      # modunload -i 0 # modinfo | grep -i audio 60 78048000 bb6e - 1 audiosup (Audio Device Support 1.12) 61 78152000 39a97 - 1 mixer (Audio Mixer 1.49) #

      At this point, audiocs, the onboard audio driver, has been unloaded and guaranteed not to be open. However, the primary audio device, /dev/audio, does not change if it is held open by an application.

8. (Optional) Plug in a USB audio device.

9. (Optional) Examine the new audio links.

   % ls -lt /dev/audio* lrwxrwxrwx 1 root root 7 Jul 23 16:12 /dev/audio -> sound/1 lrwxrwxrwx 1 root root 10 Jul 23 16:12 /dev/audioctl -> sound/1ctl % ls -lt /dev/sound/* lrwxrwxrwx 1 root root 77 Jul 23 16:12 /dev/sound/1ctl -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,aud... lrwxrwxrwx 1 root root 74 Jul 23 16:12 /dev/sound/1 -> ../../devices/pci@1f,4000/usb@5/hub@1/device@3/sound-control@0:sound,aud... lrwxrwxrwx 1 root root 66 Jul 23 15:59 /dev/sound/0 -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,audio lrwxrwxrwx 1 root root 69 Jul 23 15:59 /dev/sound/0ctl -> ../../devices/pci@1f,4000/ebus@1/SUNW,CS4231@14,200000:sound,aud... %

How to Remove Unused USB Audio Device Links

Use this procedure if a USB audio device is removed while the system is powered off. It is possible that removing the USB audio device while the system is powered off will leave the /dev/audio device still pointing to a /dev/sound/* device that doesn't exist.

1. Become superuser.

2. Close all audio applications.

3. Remove the unused audio links.

   # devfsadm -C -c audio

Troubleshooting USB Audio Device Problems

This section describes how to troubleshoot USB audio device problems.

Solving USB Speaker Problems

Sometimes USB speakers do not produce any sound even though the driver is attached and the volume is set to high. Hot-plugging the device might not change this behavior.

The workaround is to power cycle the USB speakers.

Key Points of Audio Device Ownership

Keep the following key points of audio device ownership in mind when working with audio devices.

• When you plug in a USB audio device and you are logged in on the console, the console is the owner of the /dev/* entries. This situation means you can use the audio device as long as you are logged into the console.

• If you are not logged into the console when you plug in a USB audio device, root becomes the owner of the device. However, if you log into the console and attempt to access the USB audio device, device ownership changes to the console. For more information, see logindevperm(4).

• When you remotely login with the rlogin command and attempt to access the USB audio device, the ownership does not change. This means that, for example, unauthorized users cannot listen to conversations over a microphone owned by someone else.

Hot-Plugging USB Devices With the cfgadm Command (Task Map)

Hot-Plugging USB Devices With the cfgadm Command

You can add and remove a USB device from a running system without using the cfgadm command. However, a USB device can also be logically hot-plugged without physically removing the device. This scenario is convenient when you are working remotely and you need to disable or reset a non-functioning USB device. The cfgadm command also provides a way to display the USB device tree including manufacturer and product information.

The cfgadm command displays information about attachment points, which are locations in the system where dynamic reconfiguration operations can occur. An attachment point consists of:

• An occupant, which represents a hardware resource that might be configured into the system, and

• A receptacle, which is the location that accepts the occupant.

Attachment points are represented by logical and physical attachment point IDs (Ap_Ids). The physical Ap_Id is the physical pathname of the attachment point. The logical Ap_Id is a user-friendly alternative for the physical Ap_Id. For more information on Ap_Ids, see cfgadm_usb(1M).

The cfgadm command provides the following USB device status information.

The following sections describe how to hot-plugging a USB device with the cfgadm command. All of the sample USB device information in these sections has been truncated to focus on relevant information.

How to Display USB Device Information

Use the prtconf command to display information about USB devices.

$ prtconf
        usb, instance #0
                 hub, instance #2
                     device, instance #8
                         interface (driver not attached)
                     printer (driver not attached)
                     mouse, instance #14
                     device, instance #9
                         keyboard, instance #15
                         mouse, instance #16
                     storage, instance #7
                         disk (driver not attached)
                     communications, instance #10
                         modem (driver not attached)
                         data (driver not attached)
                 storage, instance #0
                     disk (driver not attached)
                 storage, instance #1
                     disk (driver not attached)

Use the cfgadm command to display USB bus information. For example:

% cfgadm
Ap_Id                       Type         Receptacle   Occupant     Condition
usb0/4.5                    usb-hub      connected    configured   ok
usb0/4.5.1                  usb-device   connected    configured   ok
usb0/4.5.2                  usb-printer  connected    configured   ok
usb0/4.5.3                  usb-mouse    connected    configured   ok
usb0/4.5.4                  usb-device   connected    configured   ok
usb0/4.5.5                  usb-storage  connected    configured   ok
usb0/4.5.6                  usb-communi  connected    configured   ok
usb0/4.5.7                  unknown      empty        unconfigured ok
usb0/4.6                    usb-storage  connected    configured   ok
usb0/4.7                    usb-storage  connected    configured   ok

In the preceding example, usb0/4.5.1 identifies a device connected to port 1 of the second-level external hub, which is connected to port 5 of first-level external hub, which is connected to the first USB controller's root hub, port 4.

Use the following cfgadm command to display specific USB device information. For example:

% cfgadm -l -s "cols=ap_id:info"
Ap_Id       Information
usb0/4.5.1  Mfg: Inside Out Networks Product: Edgeport/421 NConfigs: 1 Config: 0  : ...
usb0/4.5.2  Mfg: <undef> Product: <undef>   NConfigs: 1 Config: 0  <no cfg str descr>
usb0/4.5.3  Mfg: Mitsumi Product: Apple USB Mouse NConfigs: 1 Config: 0 <no cfg str descr>
usb0/4.5.4  Mfg: NMB  Product: NMB USB KB/PS2 M NConfigs: 1 Config: 0  
usb0/4.5.5  Mfg: Hagiwara Sys-Com  Product: SmartMedia R/W  NConfigs: 1 Config: 0 : Default
usb0/4.5.6  Mfg: 3Com Inc.  Product: U.S.Robotics 56000 Voice USB Modem  NConfigs: 2 ...
usb0/4.5.7
usb0/4.6    Mfg: Iomega  Product: USB Zip 250  NConfigs: 1  Config: 0  : Default
usb0/4.7    Mfg: Iomega  Product: USB Zip 100  NConfigs: 1  Config: 0  : Default
# 

How to Unconfigure a USB Device

You can unconfigure a USB device that is still physically connected to the system, but a driver will never attach to it. After the USB device is unconfigured, the device is visible in the prtconf output.

1. Become superuser.

2. Unconfigure the USB device.

   # # cfgadm -c unconfigure usb0/4.7 Unconfigure the device: /devices/pci@8,700000/usb@5,3/hub@4:4.7 This operation will suspend activity on the USB device Continue (yes/no)? y

3. Verify that the device is unconfigured.

   # cfgadm Ap_Id Type Receptacle Occupant Condition usb0/4.5 usb-hub connected configured ok usb0/4.5.1 usb-device connected configured ok usb0/4.5.2 usb-printer connected configured ok usb0/4.5.3 usb-mouse connected configured ok usb0/4.5.4 usb-device connected configured ok usb0/4.5.5 usb-storage connected configured ok usb0/4.5.6 usb-communi connected configured ok usb0/4.5.7 unknown empty unconfigured ok usb0/4.6 usb-storage connected configured ok usb0/4.7 usb-storage connected unconfigured ok

How to Configure a USB Device

1. Become superuser.

2. Configure a USB device.

   # cfgadm -c configure usb0/4.7

3. Verify that the USB device is configured.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 usb-storage connected configured ok

How to Logically Disconnect a USB Device

If you want to remove a USB device from the system and the prtconf output, but you are not physically near the system, just logically disconnect the USB device. The device is still physically connected, but it is logically disconnected, unusable, and not visible to the system.

1. Become superuser.

2. Disconnect a USB device.

   # cfgadm -c disconnect -y usb0/4.7

3. Verify that the device is disconnected.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 unknown disconnected unconfigured ok

How to Logically Connect a USB Device

Use this procedure to logically connect a USB device that was previously logically disconnected or unconfigured.

1. Become superuser.

2. Connect a USB device.

   # cfgadm -c configure usb0/4.7

3. Verify that the device is connected.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 usb-storage connected configured ok

   The device is now available and visible to the system.

How to Logically Disconnect a USB Device Subtree

Use this procedure to disconnect a USB device subtree, which is the hierarchy (or tree) of devices below a hub.

1. Become superuser.

2. Remove a USB device subtree.

   # cfgadm -c disconnect -y usb0/4

3. Verify that the USB device subtree is disconnected.

   # cfgadm usb0/4 Ap_Id Type Receptacle Occupant Condition usb0/4 unknown disconnected unconfigured ok

How to Reset a USB Device

If a USB device behaves erratically, use the cfgadm command to reset the device, which logically removes and recreates the device.

1. Become superuser.

2. Make sure the device is not in use.

3. Reset the device.

   # cfgadm -x usb_reset -y usb0/4.7

4. Verify that the device is connected.

   # cfgadm usb0/4.7 Ap_Id Type Receptacle Occupant Condition usb0/4.7 usb-storage connected configured ok