This repository contains a community-maintained, AI-assisted, and heavily patched version of the AVerMedia GC573 Linux driver. It has been modernized for the latest kernels and stabilized for advanced experimental testing.
Kernel Compatibility: Successfully builds and runs on Kernel 6.19.10+ (CachyOS / Arch / Gentoo).
| Feature | Status | Description |
|---|---|---|
| Module Loading | ✅ [OK] | STABLE — No longer crashes the kernel upon loading |
| Signal Detection | ✅ [OK] | FUNCTIONAL — Hardware syncs via forced 1080p EDID handshake |
| IRQ / Interrupts | ✅ [OK] | WORKING — MSI interrupt allocation with INTx fallback |
| System Stability | I2C read-locks during streaming cause system freezes | |
| DMA Transfer | ✅ [OK] | FUNCTIONAL — Data flow confirmed via ffplay/xxd |
| Capture Content | First frames visible, continuous streaming incomplete | |
| Driver Unload | ❌ [BROKEN] | rmmod often fails, may require reboot |
| General Use | ❌ [NOT REC] | For development/testing only — NOT FOR DAILY USE |
| Phase | Status | Description |
|---|---|---|
| Phase 1 | ✅ DONE | Builds on modern kernels, module loads stable |
| Phase 2 | ✅ DONE | HDMI lock, first DMA data, format recognized |
| Phase 3 | 🔄 IN PROGRESS | Continuous streaming, buffer lifecycle, IRQ completion |
| Phase 4 | ⏳ PENDING | Robust start/stop, suspend/resume, OBS/GStreamer support |
- V4L2 Callback Bridge: Discovered and fixed a critical issue where the hardware initialization logic was disconnected from the active V4L2
STREAMONpath. The driver now correctly triggers FPGA and HDMI-Receiver configuration when a capture starts. - MSI Interrupts: Migrated from legacy INTx to proper MSI (Message Signaled Interrupts), eliminating the "interrupt storm" system freezes.
- EDID Override: Patched multiple locations to force the card to identify as a 1080p-max device. This prevents signal handshake failures with modern consoles.
- Timing Correction: Fixed a Hz vs. kHz mismatch in the
pixel_clockcalculation, ensuring stable 1080p60 targeting.
We have confirmed through buffer analysis (xxd) that the hardware delivers YUV 4:2:2 data (10 80). The driver now forces a consistent YUV path across all layers:
- V4L2 Layer: Restricted to
YUYVonly to prevent color interpretation errors. - FPGA Layer: Forced
AVER_XILINX_FMT_YUYVin the video process pipeline. - ITE68051 Layer: Synchronized inputs and TTL output to YUV mode.
Fixed issues where players like ffplay reported "unknown range/csp" or washed-out colors:
- Explicit Metadata: The driver now explicitly reports BT.709, Limited Range (16-235), and correctly encoded YCbCr flags to the OS.
- AVI InfoFrame Sync: Register
0x2ais now synchronized with the V4L2 state to ensure the HDMI receiver and OS agree on the signal type.
- Video Unmute Sequence: Implemented the official Windows driver 3-stage sequence (
0xb0 -> 0xa0 -> 0x02) to "wake up" the video output buffers on the HDMI receiver. - I2C Safety (Critical): Discovered that reading ITE68051 registers (I2C) while DMA is active causes instant system freezes. The driver now uses a Write-Only initialization path during streaming to maintain kernel stability.
- TTL Pixel Mode: Identified and implemented true TTL bus configuration (Registers
0xc0-0xc4) for Single-Pixel/SDR output.
| Test | 0x6b | 0x6c | 0x6e | 0x23 | 0xc0 | 0xc1 | 0x2a | Result |
|---|---|---|---|---|---|---|---|---|
| D | 0x02 | 0x02 | 0x01 | - | 0x00 | 0x00 | 0x3a | LOCKED YUV |
| Unmute | 0x02 | 0x02 | 0x01 | 0xb0-a0-02 | 0x00 | 0x00 | 0x3a | Success |
| TTL | 0x02 | 0x02 | 0x01 | 0xb0-a0-02 | 0x02 | 0x00 | 0x3a | FLICKERING DATA |
| Phase | 0x02 | 0x02 | 0x01 | 0xb0-a0-02 | 0x03 | 0x20 | 0x3a | FREEZE / BLACK |
Note
Conclusion: The configuration 0xc0=0x02 and 0xc1=0x00 is the current stable baseline for data flow.
Runtime-configurable module parameter (force_input_mode) to manually set the HDMI input colorspace:
| Value | Mode | Description |
|---|---|---|
0 |
Auto | ITE6805 detection (default) |
1 |
YUV 4:2:2 | BT.709 Limited Range |
2 |
YUV 4:4:4 | BT.709 Limited Range |
3 |
RGB Full | 0-255, BT.709 |
4 |
RGB Limited | 16-235, BT.709 |
Important
Kernel Parameters: You must add these to your boot command line (GRUB / systemd-boot):
ibt=off iommu=ptibt=off— Disables Intel Indirect Branch Tracking (required for proprietary blob compatibility).iommu=pt— Sets IOMMU passthrough mode (required for DMA access).
- Build Tools:
base-devel,cmake,llvm,clang
1. Load Required Kernel Modules:
sudo modprobe videobuf2-v4l2 videobuf2-dma-sg videobuf2-dma-contig videobuf2-vmalloc2. Build & Load:
cd driver
make clean && make LLVM=1 CC=clang
sudo rmmod cx511h || true
sudo insmod cx511h.ko force_input_mode=1# Check if device is blocked by another process
sudo lsof /dev/video0
# Kill any blocking processes
sudo fuser -k /dev/video0
# Test with ffplay (1080p60 YUYV)
ffplay -f v4l2 -input_format yuyv422 -video_size 1920x1080 -framerate 60 /dev/video0
# Analyze raw buffer content
v4l2-ctl --stream-mmap --stream-count=1 --stream-to=/tmp/test.raw
xxd /tmp/test.raw | head -30
# Check handshake and color logs
sudo dmesg | grep -iE "cx511h-hdmi|cx511h-v4l2|cx511h-color"| State | Hex Pattern | Meaning |
|---|---|---|
| Black Screen | 10 80 10 80... |
Valid YUV stream, but Y=16 (black). |
| Color Signal | 85 7a 90 85... |
Active video flowing. |
| Green Tint | 80 10 80 10... |
UYVY/YUYV swap. Byte alignment issue. |
The driver often fails to unload cleanly.
- Symptom:
sudo rmmod cx511hreturnsDevice or resource busy. - Cause: V4L2 device file references or DMA memory buffers are not fully released.
- WARNING: Do NOT use
rmmod -f(forced removal). This triggers a Kernel Freeze, requiring a hard reset.
Accessing the I2C bus (reading registers) while the HDMI pixel stream is active triggers system-wide freezes.
- Solution: Avoid
hdmirxrd()calls instream_on/stream_off. The driver is currently configured for write-only control during these phases.
- ❌ Do NOT use
v4l2-ctl --stream-mmapfor testing. - Reason: Triggers unexpected I2C status reads during stream_off sequence, which causes a total System Freeze due to bus contention.
- Alternative: Use
ffplayfor safe testing.
This driver is based on community reverse engineering efforts to enable Linux support for hardware without official vendor drivers.
Caution
Legal Notice:
- This project does NOT distribute any proprietary binaries.
- No copyrighted code from vendor drivers is included.
- Purpose: Interoperability and Linux hardware support.
- Non-commercial, community-driven project.
| Register | Type | Value | Purpose | Priority |
|---|---|---|---|---|
| MMIO 0x10 | FPGA | 0x02 |
IRQ ACK after EACH buffer | CRITICAL |
| MMIO 0x304 | FPGA | Bit set | Doorbell re-queue (next buffer ready) | CRITICAL |
| I2C 0x20 | ITE68051 | 0x40 |
Video Output Enable (Bit 6) | CRITICAL |
| I2C 0x86 | ITE68051 | 0x01 |
Global Enable | HIGH |
| I2C 0x90 | ITE68051 | 0x8f |
IRQ Enable | HIGH |
| I2C 0xA0-A2 | ITE68051 | 0x80 |
DMA Channel Enable | HIGH |
| I2C 0xA4 | ITE68051 | 0x08 |
DMA Enable | HIGH |
| I2C 0xB0 | ITE68051 | 0x01 |
Buffer Enable | HIGH |
All missing registers have been identified. Testing will focus on implementation of the re-queue (MMIO 0x304) and interrupt acknowledgment (MMIO 0x10) mechanisms to achieve continuous data flow.
-
Register Discovery ≠ Problem Solved
- Missing registers identified, but timing/sequence may vary.
- Edge-triggered vs level-triggered bits unknown.
- Read-modify-write behavior not fully documented.
-
I2C Freeze May Be Deeper
- Could be locking issues between ISR/workqueue/stream thread.
- Power-state dependencies not fully understood.
- Race conditions with reset/mute/unmute possible.
-
ffplay Success ≠ Full Driver Success
- v4l2-ctl, OBS, GStreamer may still fail.
- V4L2 state machine lifecycle needs work.
- Buffer queue management incomplete.
- Community-driven register probing and analysis.
- V4L2 callback chain tracing.
- Iterative testing with actual hardware.
This is an unofficial community project for educational and interoperability purposes only. AVerMedia does not endorse or support this driver. Use at your own risk.
Maintained by Everlite. Special thanks to original work by derrod.