Skip to content

Continuous framebuffer refresh: display new frames as they arrive on stdin#13

Merged
eichenberger merged 3 commits into
mainfrom
copilot/add-refresh-framebuffer-on-new-image
May 24, 2026
Merged

Continuous framebuffer refresh: display new frames as they arrive on stdin#13
eichenberger merged 3 commits into
mainfrom
copilot/add-refresh-framebuffer-on-new-image

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented May 23, 2026

  • Review current README usage sections
  • Add a section showing how to generate an output.fb file with ImageMagick
  • Commit and push README update

Copilot AI linked an issue May 23, 2026 that may be closed by this pull request
Copilot AI changed the title [WIP] Add refresh functionality for framebuffer on new image Continuous framebuffer refresh: display new frames as they arrive on stdin May 23, 2026
Copilot AI requested a review from eichenberger May 23, 2026 12:40
@eichenberger eichenberger force-pushed the copilot/add-refresh-framebuffer-on-new-image branch from 1c0edd6 to b856dea Compare May 23, 2026 14:52
@eichenberger eichenberger force-pushed the copilot/add-refresh-framebuffer-on-new-image branch from 6bffe8e to f701031 Compare May 24, 2026 13:55
@eichenberger eichenberger marked this pull request as ready for review May 24, 2026 13:56
@eichenberger eichenberger requested a review from Copilot May 24, 2026 13:56
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates drm-framebuffer to support continuously reading frames from stdin and updating the display as each full frame arrives, and documents how to stream multiple frames and generate .fb files.

Changes:

  • Refactors display logic into a helper and adds a select() + signalfd() driven loop to read and display multiple frames from stdin.
  • Updates README with a “Streaming multiple frames” example and an ImageMagick command for producing BGRA .fb files.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File Description
README.md Documents multi-frame streaming usage and ImageMagick conversion to .fb.
main.c Implements continuous frame ingestion from stdin and signal-driven termination.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread main.c
Comment thread main.c
Comment thread main.c
Comment thread README.md Outdated
Comment thread README.md
Comment thread main.c
Copy link
Copy Markdown
Contributor Author

Copilot AI commented May 24, 2026

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • dl.google.com
    • Triggering command: /usr/lib/apt/methods/https /usr/lib/apt/methods/https (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Copilot AI requested a review from eichenberger May 24, 2026 14:06
Copilot AI and others added 3 commits May 24, 2026 16:10
Instead of blocking with sigwait() after displaying the first frame,
use signalfd() + select() to simultaneously monitor:
- stdin for new frame data
- SIGINT/SIGTERM for clean shutdown

When a new complete frame is received on stdin it is immediately
displayed. When stdin reaches EOF the last frame stays on screen
and the program continues waiting for a signal. SIGINT or SIGTERM
still causes a clean exit (restoring the original CRTC state).

The display logic is extracted into a separate display_framebuffer()
helper to avoid duplication.

Co-authored-by: Stefan Eichenberger <eichest@gmail.com>
Co-authored-by: Stefan Eichenberger <eichest@gmail.com>
…andle pitch

The inner read loop used `dumb_framebuffer.size` as the number of bytes
to collect before displaying a frame.  The kernel's DRM_IOCTL_MODE_CREATE_DUMB
may align the pitch (row stride) beyond `width * bpp/8`, making `size`
(`= pitch * height`) larger than the packed pixel data users actually
supply.  The code would therefore block waiting for phantom padding bytes
until more data arrived, causing the "need 2 KB extra" symptom.

Fix:
- Compute `row_stride = width * bpp/8` (packed bytes per row).
- Compute `image_size = row_stride * height` (bytes the user provides).
- Read row-by-row: each `read()` targets at most the remaining bytes in
  the current row, written to `fb->data + row * pitch + col`.  This
  places every row at the correct pitched offset in the mapped buffer,
  fixing the silent display corruption that would occur when pitch >
  row_stride.
- Stop after `image_size` bytes, so a complete frame is displayed as
  soon as the last pixel byte arrives, with no extra data needed.

Co-authored-by: Stefan Eichenberger <eichest@gmail.com>
@eichenberger eichenberger force-pushed the copilot/add-refresh-framebuffer-on-new-image branch from 01577c0 to 8b048b6 Compare May 24, 2026 14:10
@eichenberger eichenberger merged commit 44799af into main May 24, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cool stuff for drm connectors on same framebuffer

3 participants