PIAF

A Rust library for decoding binary capability data into a clean, typed model, specialized for EDID.

PIAF reads raw EDID bytes — from a file, a kernel sysfs node, or a direct I²C read — and produces a DisplayCapabilities value with all the information a display or HDMI-adjacent application typically needs: identity, input type, supported modes, color characteristics, HDR metadata, audio capabilities, and more.

Decoding happens in two steps. parse_edid validates the raw bytes and returns a ParsedEdidRef<'_> — a zero-copy view that borrows the block structure directly from the input slice. capabilities_from_edid then runs the registered extension handlers over that structure and produces a DisplayCapabilities — the typed, stable model your application works with. Keeping these steps separate means you can inspect the raw parse result for debugging, or run multiple handler configurations over the same parsed data without re-parsing. Use parse_edid_owned to get an owned ParsedEdid that can outlive the input buffer.

use piaf::{parse_edid, capabilities_from_edid, ExtensionLibrary, ScreenSize};

let bytes = std::fs::read("/sys/class/drm/card0-HDMI-A-1/edid")?;
let library = ExtensionLibrary::with_standard_handlers();
let parsed = parse_edid(&bytes, &library)?;
let caps = capabilities_from_edid(&parsed, &library);

println!("Display: {}", caps.display_name.as_deref().unwrap_or("unknown"));
if let Some(ScreenSize::Physical { width_cm, height_cm }) = caps.screen_size {
    println!("{}×{} cm", width_cm, height_cm);
}
for mode in &caps.supported_modes {
    println!("  {}×{}@{}", mode.width, mode.height, mode.refresh_rate);
}

See examples/inspect_displays.rs for a more complete example.

flowchart LR
    bytes["&[u8]"]
    ref["ParsedEdidRef<'_>"]

    bytes -->|"parse_edid"| ref

    ref -->|"capabilities_from_edid\n+ ExtensionLibrary"| dc["DisplayCapabilities\nalloc / std"]
    ref -->|"capabilities_from_edid_static\n+ STANDARD_HANDLERS"| sc["StaticDisplayCapabilities<N>\nall tiers"]

Why PIAF

Deep CEA-861 coverage. Most EDID libraries decode the base block and stop. PIAF decodes 20+ CEA-861 data block types, including HDR static and dynamic metadata, HDMI 1.x and HDMI Forum VSDBs, colorimetry, speaker allocation, video timing blocks, and the HDMI Forum Sink Capability block. If the information is in the EDID, PIAF exposes it as typed fields rather than raw bytes.

Pluggable handlers. The extension handler system lets you register your own handler for any extension block tag — override the built-in CEA-861 handler, add support for a proprietary block, or attach typed custom data to DisplayCapabilities for downstream consumers. Base block parsing is pluggable too.

Honest diagnostics. PIAF distinguishes between hard parse errors (invalid header, checksum failure, truncated input) and non-fatal warnings (unknown extension block, malformed data block, out-of-range manufacturer ID). You decide how strict to be; nothing is silently discarded.

no_std support. The library runs on bare metal. The static extension handler pipeline — capabilities_from_edid_static with STANDARD_HANDLERS — works at all build tiers, including bare no_std without an allocator. Custom handlers implement StaticExtensionHandler using static references instead of Box — see no_std builds below.

Stable consumer model. ParsedEdidRef and ParsedEdid preserve raw bytes; DisplayCapabilities is the typed, stable output. Both implement EdidSource and work directly with the capability pipelines. Parser improvements don't change the consumer-facing API.

Extension system

Cea861Handler covers the common case. Write your own handler to support a proprietary extension block, augment CEA-861 decoding with application-specific logic, or attach typed custom data to DisplayCapabilities for downstream consumers.

Dynamic handlers (std/alloc)

Register via ExtensionLibrary. Uses Box<dyn ExtensionHandler> internally, so requires heap allocation:

use piaf::{ExtensionHandler, DisplayCapabilities, ParseWarning, ExtensionLibrary};

#[derive(Debug)]
struct MyHandler;

impl ExtensionHandler for MyHandler {
    fn process(&self, block: &[u8; 128], caps: &mut DisplayCapabilities, warnings: &mut Vec<ParseWarning>) {
        // inspect block, set fields on caps
    }
}

let mut library = ExtensionLibrary::new();
library.register(ExtensionMetadata {
    tag: 0xAB,
    display_name: String::from("My Extension"),
    handler: Some(Box::new(MyHandler)),
});

Typed data can be attached to DisplayCapabilities and retrieved by tag:

caps.set_extension_data(0xAB, MyCeaData { version: block[1] });

if let Some(data) = caps.get_extension_data::<MyCeaData>(0xAB) {
    println!("version: {}", data.version);
}

Static handlers (no-alloc)

Use StaticExtensionHandler when heap allocation is unavailable. Pass a static slice to capabilities_from_edid_static:

use piaf::{StaticExtensionHandler, ModeSink, StaticDisplayCapabilities, STANDARD_HANDLERS};

struct MyHandler;

impl StaticExtensionHandler for MyHandler {
    fn tag(&self) -> u8 { 0xAB }
    fn process(&self, block: &[u8; 128], sink: &mut dyn ModeSink) {
        // push modes via sink.push_mode(...)
    }
}

static MY_HANDLER: MyHandler = MyHandler;
static HANDLERS: &[&dyn StaticExtensionHandler] = &[STANDARD_HANDLERS[0], &MY_HANDLER];

let caps: StaticDisplayCapabilities<64> =
    piaf::capabilities_from_edid_static(&parsed, HANDLERS);

Static handlers extract modes only — audio, VSDB, colorimetry, and similar rich metadata require the dynamic pipeline.

Features

no_std builds

Bare no_std (neither std nor alloc) is supported. The dynamic extension handler pipeline (ExtensionLibrary, capabilities_from_edid) requires alloc or std. The static pipeline (capabilities_from_edid_static) is available unconditionally.

In bare no_std, parse_edid returns a ParsedEdidRef<'_> that borrows extension blocks directly from the input slice — no allocator needed. Both base-block fields and extension-block modes are available through capabilities_from_edid_static at all build tiers.

parse_edid_owned returns a ParsedEdid that copies block bytes into owned storage; in bare no_std the extension block field is absent (alloc-gated), so prefer ParsedEdidRef from parse_edid when extension block access matters.

Fields in DisplayCapabilities available in all build configurations

These fields are absent from DisplayCapabilities without alloc or std:

For supported modes without heap allocation, use capabilities_from_edid_static instead. It returns StaticDisplayCapabilities<N>, which holds all the scalar fields above plus a fixed-capacity [Option<VideoMode>; N] array accessible via iter_modes().

Fixed-length string fields (MonitorString, ManufacturerId) use fixed-size byte array newtypes with Display and Deref<Target = str> impls, so they behave like strings in all build configurations without requiring heap allocation.

Base block decoding

Fields decoded by BaseBlockHandler:

CEA-861 coverage

Data blocks decoded by Cea861Handler:

Documentation

Design and architecture notes live under doc/:

• doc/architecture.md — pipeline and layer overview
• doc/model.md — data model and type design
• doc/extensibility.md — extension system guide
• doc/static-pipeline.md — static pipeline design and API reference
• doc/scope.md — scope and evolution strategy
• doc/testing.md — testing strategy and fuzzing
• doc/cea861-vsdb.md — VSDB wire formats (HDMI 1.x and HDMI Forum)
• doc/cea861-extended-tags.md — extended tag block wire formats
• doc/roadmap.md — planned features and future work