Skip to main content

USB file system abstraction API

This module provides a USB file system abstraction API which can be used to gain information of the physical USB bus structure on a Linux System.

The USB file system (Taken from http://www.linux-usb.org/FAQ.html)

# ls  /sys/bus/usb/devices/
1-0:1.0      1-1.3        1-1.3.1:1.0  1-1:1.0
1-1          1-1.3.1      1-1.3:1.0    usb1

The names that begin with “usb” refer to USB controllers. More accurately, they refer to the “root hub” associated with each controller. The number is the USB bus number. In the example there is only one controller, so its bus is number 1. Hence the name “usb1”.

“1-0:1.0” is a special case. It refers to the root hub’s interface. This acts just like the interface in an actual hub an almost every respect; see below.

All the other entries refer to genuine USB devices and their interfaces. The devices are named by a scheme like this:

bus-port.port.port ...

In other words, the name starts with the bus number followed by a ‘-’. Then comes the sequence of port numbers for each of the intermediate hubs along the path to the device.

For example, “1-1” is a device plugged into bus 1, port 1. It happens to be a hub, and “1-1.3” is the device plugged into port 3 of that hub. That device is another hub, and “1-1.3.1” is the device plugged into its port 1.

The interfaces are indicated by suffixes having this form:

:config.interface

That is, a ‘:’ followed by the configuration number followed by ‘.’ followed by the interface number. In the above example, each of the devices is using configuration 1 and this configuration has only a single interface, number 0. So the interfaces show up as:

1-1:1.0        1-1.3:1.0        1-1.3.1:1.0

A hub will never have more than a single interface; that’s part of the USB spec. But other devices can and do have multiple interfaces (and sometimes multiple configurations). Each interface gets its own entry in sysfs and can have its own driver.

Usage

The API consists of a USB root object, from which all children can be accessed like python container types.

>>> from usbid import USB
>>> usb = USB()
>>> usb
<usbid.fs.USB [/sys/bus/usb/devices] at ...>

>>> usb.keys()
['1', '2']

Get a specific bus.

>>> bus = usb['1']
>>> bus
<usbid.fs.Bus [usb1] at ...>

Get port from bus.

>>> port = bus['1']
>>> port
<usbid.fs.Port [1-1] at ...>

Get interface from port.

>>> port.interfaces
[<usbid.fs.Interface [1-1:1.0] at ...>]

Interfaces might have tty associated.

>>> port.interfaces[0].tty
'ttyUSB0'

It’s not a good idea to refer to a USB interface by its tty mount name. But it’s a good idea to remember the file system name for unique identification, lookup interface by this name and then connect to corresponding tty.

>>> interface = usb.get_interface('1-1:1.0')
>>> interface.tty
'ttyUSB0'

For debugging you can print the USB structure.

>>> usb.printtree()
<usbid.fs.USB [/sys/bus/usb/devices] at ...>
  <usbid.fs.Bus [usb1] at ...>
      - Linux 3.13.0-48-generic xhci_hcd
      - xHCI Host Controller
    <usbid.fs.Interface [1-0:1.0] at ...>
    <usbid.fs.Port [1-1] at ...>
        - FTDI
        - FT232R USB UART
      <usbid.fs.Interface [1-1:1.0] at ...>
        - ttyUSB0

Source Code

The sources are in a GIT DVCS with its main branches at github.

Contributors

Changelog

2.2 (2023-05-15)

  • Officially support Python 3.7 - 3.11. [rnix]

  • CI Integration. [rnix]

  • Convert doctests to unittests. [rnix]

2.1 (2022-07-18)

  • Python 3 Support [rnix, 2022-07-17]

2.0 (2015-04-09)

  • Complete rewrite. [rnix, 2015-04-08]

1.0.3 (2014-03-03)

  • concrete ttyXXX device might live in tty subdirectory. [rnix, 2014-02-26]

1.0.2 (2014-02-26)

  • Rename usbid.device.devicelist to usbid.device.device_list. B/C import available. [rnix, 2014-02-26]

  • Introduce usbid.device.device_by_path utility. [rnix, 2014-02-26]

  • use latest usb.id file version 2014.02.03 from http://www.linux-usb.org/usb.ids [jensens, 2014-02-20]

1.0.1 (2014-02-20)

  • fix device node hierarchy [rnix, 2014-02-17]

  • housekeeping, fix tests [rnix, 2014-02-17]

1.0 (2013-12-19)

  • initial work [benniboy, jensens, 2013-12-19]

License

Copyright (c) 2013-2023, BlueDynamics Alliance, Austria, Germany, Switzerland All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

  • Neither the name of the BlueDynamics Alliance nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY BlueDynamics Alliance AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BlueDynamics Alliance BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Metadata

Release files for usbid 2.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for usbid 2.2
File Size Uploaded Provenance
usbid-2.2.tar.gz 429.0 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for usbid 2.2
File Interpreter ABI Platform
usbid-2.2-py3-none-any.whl Python 3 none any Details

Total release size: 854.1 kB

Release files / usbid-2.2.tar.gz

Download URL usbid-2.2.tar.gz
Size 429.0 kB
Tags Source
SHA-256 checksum
How to use checksums
5a6298939289ef1416c6c26e57d9dfadcb59a6412de39c9fbc03611963ddcb03
BLAKE2b-256 checksum
How to use checksums
08713a78bee9e0af7c69ca9913ff1a0bbd0d02a496fd0eeca18898233543f0bb
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.2 CPython/3.9.2

Release files / usbid-2.2-py3-none-any.whl

Download URL usbid-2.2-py3-none-any.whl
Size 425.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
ccba93a9cf97a2ab8e7f853608aa1a69d9da2bdff36bfe932ee2159fd09371ec
BLAKE2b-256 checksum
How to use checksums
d284c54c85050312501d163a50f6cf95e628b590eb80860b4b02978cf9da62fc
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.2 CPython/3.9.2

Security for usbid 2.2

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page