WhatBlocknCable

WhatBlocknCable shows what Linux can currently tell you about a USB-C connection: cable e-marker details, advertised USB Power Delivery profiles, charging state, attached USB devices, and negotiated USB speed. It has a GTK desktop interface and a command-line interface with text and JSON output.

The important qualification is “what Linux can tell you.” The program reads kernel-provided sysfs data. Firmware and drivers often expose only part of a connection, so an empty field is not evidence that a cable or charger lacks a feature. See Linux telemetry before drawing conclusions from missing data.

This is a standalone, Linux-only project. Its application ID is io.github.aiden0rchad.WhatBlocknCable.

What is available

The GTK4/libadwaita application, whatblockncable-gui, shows:

• USB-C ports registered by the kernel;
• cable and connected-device identity when Discover Identity data is exposed;
• e-marker current, voltage, power, and data-speed claims;
• charger profiles and available live charging information;
• an external USB-device tree and negotiated USB link speeds; and
• clear reduced-data states when Type-C telemetry is absent or unreadable.

The GUI refreshes every two seconds and updates when the snapshot changes. Devices marked fixed by the kernel are treated as internal and omitted from the external-device list.

The command-line tool is installed as whatblockncable (with whatblockncable-cli as an explicit alias). It uses the same backend and formatters as the GUI.

Linux telemetry

WhatBlocknCable reads, but does not write to, these kernel interfaces:

Information	Main source
Connector, role, orientation, partner, and cable identity	/sys/class/typec/
Type-C alternate modes	/sys/bus/typec/devices/
Advertised USB-PD source capabilities	the partner's usb_power_delivery/source-capabilities/ tree
Charger and battery state	/sys/class/power_supply/
USB devices and negotiated speed	/sys/bus/usb/devices/
Limited Thunderbolt/USB4 router data	/sys/bus/thunderbolt/devices/
Limited display/EDID groundwork	/sys/class/drm/

A Type-C provider must populate /sys/class/typec. UCSI is common, but it is not required: TCPM/TCPCI, embedded-controller, and dedicated PD-controller drivers can provide the same kernel class. A visible port0 still does not guarantee that the kernel will publish partner identity, a cable e-marker, or charger PDOs.

Some expected cases look like missing data:

• many cables below 60 W have no e-marker;
• a marked cable may not be queried by the controller on every connection;
• power-supply drivers commonly omit voltage, current, power, or model fields;
• USB and Type-C port numbers are unrelated, so WhatBlocknCable associates a USB device with a connector only when kernel links prove the relationship;
• live DisplayPort lane/rate data is not available through a stable generic interface; and
• current output is not a Thunderbolt fabric or tunnel map.

Missing or ambiguous readings remain unknown rather than being guessed. PORTING.md documents the backend and its compatibility model in more detail.

Requirements

The packaging scripts support native x86_64 and aarch64 builds. Release artifacts are published per architecture; use only one whose filename matches your system. The packages bundle the Swift runtime and use distribution copies of:

• glibc at least as new as the system used to build the package (the Debian package records the exact minimum version);
• GTK4;
• libadwaita 1.4 or newer;
• SQLite;
• libstdc++; and
• libgcc.

Useful results also require readable kernel interfaces for the hardware. No particular distribution, desktop, or laptop model can guarantee that.

The GUI works as a normal window without a tray. A tray icon requires a session D-Bus and an org.kde.StatusNotifierWatcher host. GNOME normally needs the AppIndicator and KStatusNotifierItem Support extension. On Wayland, the compositor positions the application window; an ordinary GTK top-level window cannot be placed at global tray-icon coordinates. The shell-owned tray menu remains anchored.

Install a release package

Available release artifacts are published on the Releases page. A release may contain a Debian package, an RPM, and a generic tarball for one or both supported architectures. Check the architecture in the filename.

Examples for x86_64:

sudo apt install ./whatblockncable_<version>_amd64.deb
sudo dnf install ./whatblockncable-<version>-1.x86_64.rpm
sudo tar -C / -xzf whatblockncable-<version>-linux-x86_64.tar.gz

Use the distribution package manager to remove a .deb or RPM installation. The generic tarball is a system tree under /usr; it is not registered with a package manager.

After installation, start WhatBlocknCable from the application launcher or run:

whatblockncable-gui
whatblockncable

Build and install from source

You need Swift 5.9 or newer, SQLite development files, GTK4 development files, and libadwaita development files. Common package names are:

# Fedora family
sudo dnf install swift-lang sqlite-devel gtk4-devel libadwaita-devel

# Debian family, when the distribution provides a suitable Swift compiler
sudo apt install swiftlang libsqlite3-dev libgtk-4-dev libadwaita-1-dev

A Swift toolchain is also available from swift.org.

Build and install for the current user:

git clone https://github.com/aiden0rchad/WhatBlocknCable.git
cd WhatBlocknCable
swift build
./linux/install.sh

The installer defaults to ~/.local, follows the relevant XDG data and config locations, installs both executables and desktop metadata, and bundles the required Swift runtime libraries. It may offer to create an autostart entry; that entry opens the normal application window.

To remove the source installation, run from the same checkout and with the same PREFIX value, if one was used:

./linux/install.sh --uninstall

To build only one executable without installing it:

swift build --product whatblockncable-cli
swift build --product whatblockncable-gui

Maintainers can create the three native package formats after a release build. Packaging also requires patchelf, GNU strip, and rpmbuild:

swift build -c release
./linux/package.sh

Artifacts are written under dist/. The script packages the architecture on which it runs; it does not cross-compile the other architecture.

CLI usage

whatblockncable                 print one human-readable snapshot
whatblockncable --raw           include raw connector sysfs properties
whatblockncable --json          print structured JSON
whatblockncable --watch         redraw text when the snapshot changes
whatblockncable --watch --json  emit one JSON document per changed snapshot
whatblockncable --report        print cable-report Markdown and an issue URL
whatblockncable --version
whatblockncable --help

Warnings about unavailable Type-C data go to stderr, so JSON on stdout remains usable. Watch mode polls every two seconds and suppresses unchanged snapshots. --raw means raw sysfs properties; the program does not perform USB control transfers.

Troubleshooting and diagnostics

Start with the CLI and a small set of targeted checks while the relevant cable and device are attached:

whatblockncable --version
uname -srmo
ls -la /sys/class/typec
ls -la /sys/bus/typec/devices
whatblockncable --json --raw

An absent or empty /sys/class/typec means no Type-C provider registered a port. On confirmed ACPI UCSI hardware, typec_ucsi and ucsi_acpi may be relevant; they are not universal requirements. If ports exist but are unreadable, check file permissions and local security policy. Running as root may help diagnose a permission problem, but it cannot create telemetry that a driver does not export and should not be needed for normal use.

For tray problems, include the desktop, XDG_SESSION_TYPE, tray extension or panel plugin, and reviewed stderr from whatblockncable-gui. For data problems, include the exact connection order, expected result, distribution, kernel, architecture, and the targeted output above. Use the bug form rather than uploading a recursive copy of /sys.

Privacy

All hardware inspection is local. The application and CLI do not upload telemetry or make automatic network requests. --report only prepares text and prints a URL; nothing is submitted until you choose to post an issue.

Review every diagnostic before sharing it publicly. JSON and sysfs output can contain USB serial numbers, product strings, firmware or DMI identifiers, Thunderbolt IDs, UUIDs, hostnames, usernames, and identifying paths. Replace sensitive values with consistent markers such as <redacted-serial> while leaving field names and directory relationships intact. Never post credentials, tokens, full environment dumps, or unrelated logs.

Contributing

Bug reports, hardware observations, translation corrections, and focused pull requests are welcome. Read PORTING.md before changing sysfs handling and TRANSLATIONS.md before editing retained localization resources. Keep fixtures faithful to real kernel filenames, units, and symlink structure; do not add an inferred association merely to make a fixture produce a fuller result.

Current development and issue tracking take place in this repository: https://github.com/aiden0rchad/WhatBlocknCable.

Origin and license

WhatBlocknCable was inspired by Darryl Morley's original WhatCable project. It reuses and adapts MIT-licensed Core components for USB-PD decoding, diagnostics, formatting, localization data, and cable/vendor data.

WhatBlocknCable's Linux backend, GTK interface, tray integration, packaging, and ongoing Linux development are maintained here. Darryl Morley and the original project do not maintain or endorse this project.

See CONTRIBUTORS.md for retained upstream attribution and LICENSE for the MIT terms.