Dev's Log

Chapter Two: Talking to the Silicon

· piot5

Software-side display management (resolution and position) is only half the battle. To truly control a workspace, we need to talk to the monitor’s internal firmware. This is where DDC/CI (Display Data Channel Command Interface) comes into play.

1. The Physical Monitor Bridge

In Windows, a “Logical Monitor” (GDI) is not the same as a “Physical Monitor” (The actual plastic and glass hardware). As seen in ddc.rs, we must first bridge this gap using the GetPhysicalMonitorsFromHMONITOR API.

// Snippet from ddc.rs
let mut count = 0;
if GetNumberOfPhysicalMonitorsFromHMONITOR(h_monitor, &mut count).is_ok() {
    let mut phys_monitors = vec![PHYSICAL_MONITOR::default(); count as usize];
    if GetPhysicalMonitorsFromHMONITOR(h_monitor, &mut phys_monitors).is_ok() {
        // We now have a handle to the actual hardware
    }
}

2. VCP Codes: The Language of Monitors

Once we have a physical handle, we send VCP (Virtual Control Panel) codes. These are standard hex codes that every modern monitor understands:

  • 0x10: Luminance (Brightness)
  • 0x12: Contrast
  • 0x60: Input Source (HDMI, DisplayPort, etc.)

Currently, DisplayFlow uses raw Win32 calls like SetMonitorBrightness. However, to increase reliability and cross-platform potential, we are transitioning to the ddc-ci crate, which provides a more “Rusty” abstraction over these I2C transactions.

3. The Latency Bottleneck

Monitor firmware is notoriously slow. Sending a command to change brightness can take anywhere from 40ms to 200ms. If we ran this on the main thread, the CLI would feel laggy.

To solve this, DisplayFlow uses an Asynchronous Command Queue in display_controller.rs. We offload DDC tasks to a dedicated background worker:

// The DDC Worker Loop
while let Ok(cmd) = rx.recv() {
    // This happens in the background, keeping the CLI snappy
    ddc::set_monitor_vcp(cmd.h_monitor, cmd.brightness, cmd.contrast);
}

4. Future Proofing: Moving to ddc-ci

By refactoring the current ddc.rs to use the ddc and ddc-winapi crates, we gain better error handling for “Ghost Commands” (commands sent to monitors that support DDC but ignore specific VCP codes). This transition marks the move from a pure Windows utility to a structured hardware controller.

Back to Project: GitHub | Official Website | Demo Video