Reverse engineering · USB/HID · Native tooling
EMEET PIXY Controller
EMEET PIXY Controller started as a practical problem — control an undocumented USB camera properly on Linux — and grew into an automation platform for camera discovery, PTZ control, protocol replay, diagnostics, browser interfaces, native UI work, and real-time preview enhancement.
The problem
The camera exposed useful behavior through a vendor application, but not through a clean public protocol. To make it scriptable and agent-friendly, the protocol had to be observed, reduced to confirmed sequences, replayed safely, and wrapped in tooling that could distinguish device failures, transport problems, and unsupported states.
What I built
- Reverse-engineered vendor HID/libusb traffic from a native Qt application and codified confirmed camera mode and PTZ report sequences into reusable Rust tooling.
- Transport seams for HID access, camera discovery, preview orchestration, DirectShow/UVC/V4L2 controls, GStreamer video handling, and Linux
/dev/video*to/dev/hidraw*correlation. - Repeatable observe/replay/verify workflows with protocol fixtures, JSONL capture logs, fakeable transport boundaries, CLI probes, browser controls, and native GTK/libadwaita UI experiments.
- A real-time enhancement architecture using GPU ONNX/TensorRT super-resolution, motion-adaptive temporal denoising, and low-light tone mapping/local contrast enhancement for live-preview constraints.
How it works
I treated the camera like a black box that could be made legible one packet at a time. First, I captured the vendor application's HID/libusb traffic and separated repeatable control sequences from incidental noise. Those captures became JSONL logs and protocol fixtures, so each suspected command could be replayed, compared, and promoted only when the hardware confirmed it.
The control layer then maps that evidence into Rust abstractions: device discovery, HID transport, PTZ commands, camera modes, preview orchestration, and platform-specific video controls. On Linux, the awkward bit is that the video node and the HID control node are separate, so the tooling correlates/dev/video* devices with /dev/hidraw* devices instead of assuming the first camera-shaped object is the right one.
How it achieves the goal
The goal is reliable camera control without depending on the vendor app. It achieves that by keeping the reverse-engineering trail close to the runtime: observe, replay, verify, wrap, and then expose the result through CLI probes, browser controls, native UI experiments, and agent-callable workflows. When a command fails, the system can tell whether the problem is discovery, transport, protocol state, video pipeline, or unsupported hardware behavior.
The enhancement pipeline follows the same philosophy. Super-resolution, temporal denoising, and low-light tone mapping are designed as stages with real-time constraints, not as a magic beautify filter slapped on top. The point is control: know what the device is doing, know what the video path is doing, and make the whole thing scriptable enough to build on.