Show HN: WhatCable, a tiny menu bar app for inspecting USB-C cables

Original Article ↗ Hacker News Discussion ↗

Overall reception and purpose

  • Tool inspects USB‑C ports and cables using Mac-specific interfaces, displaying capabilities and connection details.
  • Many commenters find it immediately useful for identifying “mystery” USB‑C cables and plan to label their cables.
  • Some see it as life‑changing or particularly helpful where hardware testers are impractical (e.g., blind users).

Functionality, UX, and feature requests

  • Initial version was a menu bar app; several users dislike menu bar clutter and prefer a standard window or on‑demand tool.
  • In response, the app gained:
    • A setting to disable the menu bar icon and run as a normal Dock/window app.
    • A command‑line interface.
    • Homebrew installation, with MacPorts support requested.
  • Some suggest a widget (e.g., desktop or taskbar widget) as a better always‑on display model than a menu bar item.

Bugs, hardware limits, and weird behaviors

  • Multiple reports of “No USB‑C ports detected” despite connected USB‑C devices.
    • One issue is “won’t fix” for Intel Macs because the southbridge reportedly doesn’t expose needed data.
    • Some Apple Silicon systems initially failed but were later fixed in updates.
  • One user saw both USB‑C ports showing the same set of devices; cause is unclear.
  • Early versions flagged cables as “plugged upside down,” which confused users; this behavior was later corrected.

Cross‑platform interest and ports

  • Strong demand for Linux and Windows versions.
  • Several community efforts emerged:
    • A KDE Plasma widget plus Linux CLI using /proc and USB tools.
    • A separate Linux-only CLI version without Qt dependencies.
    • References to existing Linux utilities (e.g., lsusb wrappers and PD‑aware tools).
  • A Windows version is reportedly in progress.

USB‑C, e‑markers, and technical limits

  • Discussion of USB‑C orientation handling: devices (not cables) generally manage lane swapping; some low‑end gear may fail in one orientation.
  • USB‑C complexity is highlighted (power delivery levels, data protocols, wire gauges, pinouts), with frustration that the connector standard is marketed as if it implied consistent cable capabilities.
  • The app reads e‑marker data; multiple commenters note:
    • Many cables lack e‑markers.
    • E‑markers can misreport capabilities.
    • The tool can only show what the marker and host report, not actual wire gauge, shielding, or signal integrity.
    • True quality or counterfeit detection would require specialized test hardware, bandwidth tests, or destructive analysis.
  • ChromeOS is mentioned as another platform that can read e‑markers via a discovery message; typical Windows machines often cannot due to firmware limitations.

Development process

  • The developer iterated rapidly, shipping many releases within hours, largely guided by HN feedback.
  • Some praise this responsiveness; others worry the pace leads to “vibe‑coded,” under‑tested software and urge slowing down.
  • LLMs (e.g., code assistants) are credited with enabling fast prototyping, ports (e.g., KDE widget), and CLIs, prompting a brief meta‑discussion about reduced cognitive friction in software creation.