/pps/qnx/device/<device>_ctrl

Control object for devices

Publishers
Any app
Subscribers
Device publishers (e.g., usblauncher)
Note: For more information about all the device publishers and how they interact with PPS, see the Device Publishers Developer's Guide.

Overview

When you start usblauncher, the following PPS object is created:

/pps/qnx/device/usb_ctrl

This object allows apps to perform actions on the USB hardware. Note that this type of object is known as a server object, a special PPS object designed for point-to-point communication between a server and one or more clients. For details, see "Server objects" in the Persistent Publish/Subscribe Developer's Guide.
Note:

The control object's name also includes the stackno if the usblauncher service is started with the -S option (which allows for multiple server objects, one for each instance of usblauncher). For example, if you issue the following command:

usblauncher –S 1

the USB service creates a PPS object named /pps/qnx/device/usb-1_ctrl.

Commands for USB control object

Applications can send the following commands to the /pps/qnx/device/usb_ctrl object:

Command Description
port_power Set a hub's power state. The command takes the form:

port_power::busno,devno,power_state[,portno]

If the optional portno is omitted, then all ports on that hub are controlled by the power level. The power_state can be one of 0 ("off") or 1 ("on").

toggle_port_power Turn a port's power off and back on after a fixed delay. The command takes the form:

toggle_port_power::busno,devno,portno

The numbers for busno,devno,portno can be decimal, hex, or mixed. For example, all three of these forms are valid: 
toggle_port_power::0,10,3
toggle_port_power::0x0,0xa,0x3
toggle_port_power::0x0,0xa,15
Note that the port_power command is useful to repower the port if the upstream hub has disabled it (e.g., as a result of an overcurrent condition and you wish to see if the overcurrent condition still applies).
Note: Disabling the port's power doesn't cause a "removal" event of the downstream device as you might expect, but when it's reenabled, you'll then see a removal event immediately followed by an insertion event.

Responses from usblauncher

When usblauncher executes commands, it publishes these attributes to the control object:
Attribute Description
port_power Latest power setting for the port. Values:
  • 1 ("on")
  • 0 ("off")
  • -1 ("unknown")
cmd_status String giving the errno_number and error condition (see below).

USB control examples

After starting the usblauncher process as usual, enter this command from a terminal: 
cat /pps/qnx/device/usb_ctrl?wait
Then from a second terminal, enter these commands: 
sloginfo -w &
echo toggle_port_power::xx,y,z >>
/ramdisk/pps/qnx/device/usb_ctrl

The first terminal (cat usb_ctrl?wait) will show the command status and the power result of the command for the specified bus, device, and port.

For example: 
# cat usb_ctrl?wait,delta 
@usb_ctrl
port_power::0
@usb_ctrl
port_power::1
@usb_ctrl
cmd_status::0

A value of 0 for cmd_status means no errors.

Possible error conditions

Here is a subset of possible errors:

Command status Meaning
cmd_status::19 No such device.
cmd_status::5 Could not set feature. For example, the specified port number is greater than the maximum number of available ports.
cmd_status::48 Not supported. For example, the specified device isn't a hub.
Note:

If a command isn't recognized, an error message such as the following will be published to stdout or to sloginfo (if usblauncher was started with the -l option):

CMD: unknown cmd_name