com.apple.security.device.usb
Lg slim portable dvd writer driver download. entitlement in order to access USB devices./Developer/Examples/Kernel/IOKit/usb
.USB device class | USB devices in class |
---|---|
Audio class | Speakers, microphones |
Chip Card Interface Device Class | Smart cards, chip cards |
Communication class | Speakerphone, modem |
Composite class | A device in which all class-specific information is embedded in its interfaces |
HID class | Keyboards, mice, joysticks, drawing tablets |
Hub class | Hubs provide additional attachment points for USB devices |
Mass storage class | Hard drives, flash memory readers, CD Read/Write drives, digital cameras, and high-end media players |
Printing class | Printers |
Vendor specific | A device that doesn’t fit into any other predefined class or one that doesn’t use the standard protocols for an existing class |
Video class | Digital camcorders, webcams, digital still cameras that support video streaming |
bDeviceClass
field in the device descriptor and the bNumInterfaces
field in the configuration descriptor, and each field is associated with a value. For a complete listing of all descriptor fields, see the USB specification at www.usb.org. The USB family defines structures that represent the descriptors defined by the USB specification. For the definitions of these structures, see USB
in Kernel Framework Reference.bDeviceClass
) and device subclass (bDeviceSubClass
) both have the value 0
. A composite class device appears to the system as a USB device using a single bus address that may present multiple interfaces, each of which represents a separate function. A good example of a composite class device is a multifunction device, such as a device that performs printing, scanning, and faxing. In such a device, each function is represented by a separate interface. In OS X, the I/O Kit loads the AppleUSBComposite
device driver for composite class devices that do not already have vendor-specific device drivers to drive them. The AppleUSBComposite
driver configures the device and causes drivers to be loaded for each USB interface.IOUSBDevice
nub object (described in USB Devices on OS X), is used when a driver such as the AppleUSBComposite
driver configures the device or when device-specific control and status information is needed. For example, your application would use the default control pipe if it needs to set or choose a configuration for the device. The default control pipe is connected to the default endpoint (endpoint 0). Note that endpoint 0 does not provide an endpoint descriptor and it is never counted in the total number of endpoints in an interface.IOUSBInterface
nub objects (described in USB Devices on OS X). Your application can query the interface descriptors of a device to select the pipe most suited to its needs.IOUSBDevice
. This nub object is attached to the IOService
plane of the I/O Registry as a child of the driver for the USB controller. The IOUSBDevice
nub object is then registered for matching with the I/O Kit.AppleUSBComposite
driver matches against it and starts as its provider. The AppleUSBComposite
driver then configures the device by setting the configuration in the device’s list of configuration descriptors with the maximum power usage that can be satisfied by the port to which the device is attached. This allows a device with a low power and a high power configuration to be configured differently depending on whether it’s attached to a bus-powered hub or a self-powered hub. In addition, if the IOUSBDevice
nub object has the “Preferred Configuration” property, the AppleUSBComposite
driver will always use that value when it attempts to configure the device. IOUSBInterface
nub object. These nub objects are attached to the I/O Registry as children of the original IOUSBDevice
nub object and are registered for matching with the I/O Kit.AppleUSBComposite
driver, setting the configuration again from your application will result in the destruction of the IOUSBInterface
nub objects and the creation of new ones. In general, the only reason to set the configuration of a composite class device that’s matched by the AppleUSBComposite
driver is to choose a configuration other than the first one.IOUSBDevice
nub object) and its interfaces (each represented by an IOUSBInterface
nub object). A multifunction USB device, for example, is represented in the I/O Registry by one IOUSBDevice
object and one IOUSBInterface
object for each interface.IOUSBInterfaceInterface
to communicate with it. An application that needs to communicate with the USB device as a whole, on the other hand, would need to find the device in the I/O Registry and get an IOUSBDeviceInterface
to communicate with it. For more information on finding devices and interfaces in the I/O Registry, see Finding USB Devices and Interfaces; for more information on how to get the proper device interface to communicate with a device or interface, see Using USB Device Interfaces.Key | Notes |
---|---|
idVendor + idProduct + bcdDevice | bcdDevice contains the release number of the device |
idVendor + idProduct | |
idVendor + bDeviceSubClass + bDeviceProtocol | Use this key only if the device’s bDeviceClass is $FF |
idVendor + bDeviceSubClass | Use this key only if the device’s bDeviceClass is $FF |
bDeviceClass + bDeviceSubClass + bDeviceProtocol | Use this key only if the device’s bDeviceClass is not $FF |
bDeviceClass + bDeviceSubClass | Use this key only if the device’s bDeviceClass is not $FF |
Key | Notes |
---|---|
idVendor + idProduct + bcdDevice + bConfigurationValue + bInterfaceNumber | |
idVendor + idProduct + bConfigurationValue + bInterfaceNumber | |
idVendor + bInterfaceSubClass + bInterfaceProtocol | Use this key only if bInterfaceClass is $FF |
idVendor + bInterfaceSubClass | Use this key only if bInterfaceSubClass is $FF |
bInterfaceClass + bInterfaceSubClass + bInterfaceProtocol | Use this key only if bInterfaceSubClass is not $FF |
bInterfaceClass + bInterfaceSubClass | Use this key only if bInterfaceSubClass is not $FF |
IOUSBDevice
nub in the I/O Registry. This is because there is no key in Table 1-2 that combines the idVendor
, idProduct
, and bDeviceProtocol
elements.IOUSBDeviceInterface
object you use to communicate with a USB device as a whole and an IOUSBInterfaceInterface
object you use to communicate with an interface in a USB device. There are a number of different versions of the USB family, however, some of which provide new versions of these interface objects. (One way to find the version of the USB family installed in your computer is to view the Finder preview information for the IOUSBFamily.kext
located in /System/Library/Extensions
.) This section describes how to make sure you use the correct interface object and how to view the documentation for the interface objects. IOUSBDeviceInterface
and IOUSBInterfaceInterface
. When new versions of the USB family introduce new functions for an interface object, a new version of the interface object is created, which gives access to both the new functions and all functions defined in all previous versions of that interface object. For example, the IOUSBDeviceInterface197
object provides two new functions you can use with version 1.9.7 of the USB family (available in OS X v10.2.3 and later), in addition to all functions available in the previous device interface objects IOUSBDeviceInterface187
, IOUSBDeviceInterface182
, and IOUSBDeviceInterface
.IOUSBDeviceInterface
and IOUSBInterfaceInterface
objects. If, however, you develop an application to run in OS X v10.4 and later, you use the IOUSBDeviceInterface197
object to access the device as a whole and the IOUSBInterfaceInterface220
object to access an interface in it. This is because IOUSBDeviceInterface197
is available in OS X version 10.2.3 and later and IOUSBInterfaceInterface220
is available in OS X v10.4 and later. IOUSBDeviceInterface197
contains information about the two new functions introduced in this version, but does not repeat the documentation for the functions introduced in IOUSBDeviceInterface187
, IOUSBDeviceInterface182
, and IOUSBDeviceInterface
.ClearPipeStall
ClearPipeStallBothEnds
ClearPipeStall
function operates exclusively on the host controller side, clearing the halt feature and resetting the data toggle bit to zero. If the endpoint’s halt feature and data toggle bit must be reset as well, your application must do so explicitly, using one of the ControlRequest
functions to send the appropriate device request. See the documentation for the USB.h
header file in I/O Kit Framework Reference for more information about standard device requests.ClearPipeStallBothEnds
function which, as its name suggests, clears the halt and resets the data toggle bit on both sides at the same time.LowLatencyReadIsochPipeAsync
and LowLatencyWriteIsochPipeAsync
functions. These functions update the frame list information (including the transfer status and the number of bytes actually transferred) at primary interrupt time. Using these functions, an application can request that the frame list information be updated as frequently as every millisecond. This means an application can retrieve and begin processing the number of bytes actually transferred once a millisecond, without waiting for the entire transaction to complete.LowLatencyCreateBuffer
function to create them. Similarly, you must use the LowLatencyDestroyBuffer
function to destroy the buffers after you are finished with them. This restricts all necessary communication with kernel entities to the USB family.IOUSBLib.h
documentation in I/O Kit Framework Reference.IOUSBLib.h
in I/O Kit Framework Reference.ReadIsochPipeAsync
and WriteIsochPipeAsync
. Both functions include the following two parameters:ReadIsochPipeAsync
and WriteIsochPipeAsync
functions also have the frameStart parameter in common, but it does not get reinterpreted. This is because all isochronous transactions, including high-speed isochronous transactions, start on a frame boundary, not a microframe boundary.GetFrameListTime
function, which returns the number of microseconds in a frame. By examining the result (kUSBFullSpeedMicrosecondsInFrame
or kUSBHighSpeedMicrosecondsInFrame
) you can tell in which mode the device is operating.GetBusMicroFrameNumber
function which is similar to the GetBusFrameNumber
function, except that it returns both the current frame and microframe number and includes the time at which that information was retrieved.GetBandwidthAvailable
(available in OS X version 10.2 and later) to determine how much bandwidth is currently available for allocation to isochronous endpoints.GetEndpointProperties
(available in OS X version 10.2 and later) to examine the alternate settings of an interface and find one that uses an appropriate amount of bandwidth.SetAlternateInterface
(available in OS X version 10.0 and later) to create the desired interface and allocate the pipe objects.GetPipeProperties
(available in OS X version 10.0 and later) on the chosen isochronous endpoint. This is a very important step because SetAlternateInterface
will succeed, even if there is not enough bandwidth for the endpoints. Also, another device might have claimed the bandwidth that was available at the time the GetBandwidthAvailable
function returned. If this happens, the maximum packet size for your chosen endpoint (contained in the maxPacketSize
field) is now zero, which means that the bandwidth is no longer available.SetPipePolicy
function, which allows you to relinquish bandwidth that might have been specified in an alternate setting.USB.h
). The Kernel framework also provides byte-swapping macros and functions you can use in high-level applications (see the OSByteOrder.h
header file in libkern
). If you use these macros in your application, you shouldn't have any trouble developing a universal binary version of your application. This is because these macros determine at compile time if a swap is necessary. If, however, your application uses hard-coded swaps from little endian to big endian, your application will not run correctly in an Intel-based Macintosh. As you develop a universal binary version of your application, therefore, be sure to use the USB family swapping macros or the macros in libkern/OSByteOrder.h
for all byte swapping.