Crate embedded_graphics_gop 

embedded-graphics DrawTargets for the UEFI Graphics Output Protocol (GOP).

Supports using the UEFI block transfer (BLT) routines or utilizing direct framebuffer access, and supports the common framebuffer pixel formats. Naturally is no_std, and also supports no-alloc (with reduced functionality).

BLT routines require alloc and require UEFI boot services; while the framebuffer routines don’t require alloc in single-buffered mode, and (in practice) will still function even after exiting UEFI boot services.

The BLT target allows on-the-fly switching between single- and double-buffered modes with one type while the framebuffer targets don’t, because the BLT implementation always requires an allocated backbuffer and always needs to do damage tracking; it’s just a matter of choosing when to transfer it to the primary framebuffer. However, the framebuffer implementations can write directly into the framebuffer and as such don’t need an allocated buffer, and they also don’t normally need to perform damage tracking which significantly reduces per-pixel draw overhead.

See Also

• uefi::proto::console::gop
• embedded-graphics
• UEFI Specification § 12.9

Crate Features

• alloc (default) — adds dependency on the alloc crate. Enables BltDrawTarget and fb::FbDbDrawTarget.
• nightly — only used to enable the doc_cfg feature when documenting with a nightly toolchain.

Prior Art

uefi-graphics, uefi-graphics-driver, and uefi-graphics2 already exist and provide somewhat similar functionality.

However, they all exclusively support the framebuffer and not BLT routines, and generally seem implemented with minimal regard for the actual content of the embedded-graphics documentation and the UEFI specification. For instance, none of those check if the framebuffer’s pixel format actually matches what they implicitly expect (and as such exclusively support PixelFormat::Bgr framebuffers and will otherwise silently write garbage to the framebuffer); and uefi-graphics returns an error when the pixel is out of bounds in DrawTarget::draw_iter, which one is specifically not supposed to do (the pixels should be silently ignored).

They also all feel fairly hastily implemented: e.g. if double-buffering is supported, performing zero damage tracking and copying the entire framebuffer every commit; or all but uefi-graphics2 wantonly convert integer types without any previously-performed range/bounds checks nor explicit checked conversions which could lead to out-of-bounds ptr::writes; or uefi-graphics2 doesn’t respect the horizontal stride and will write garbage to the framebuffer; etc.

Modules

fb

DrawTargets directly writing to the hardware framebuffer.

Structs

BltDrawTargetalloc

A DrawTarget using only BLT routines to write to the framebuffer.