Skip to content

Conversation

ardera
Copy link
Owner

@ardera ardera commented Jun 21, 2025

  • ci: add CodeChecker static analysis workflow
  • fix: lots of CodeChecker warnings
  • add script for rolling flutter_embedder.h
  • Roll flutter_embedder.h (flutter stable 3.24.0)
  • kms: split drmdev into drm_resources and drmdev
  • fix: inverted modifiers check in DRM plane allocation
  • feat: use gbm_surface_create_with_modifiers2
  • fix: properly initialize drm drm_resources
  • feat: frame scheduling
  • drmdev: call release callback before scanout callback
  • kms req builder: rename destroy_cb -> release_cb
  • fix: don't use drmIsKMS
  • fix: frame scheduler: fix incorrect tracking of waiting_for_scanout
  • frame scheduling: forward flutter vsync requests to frame scheduler
  • WIP: feat: implement frame timing

@ardera ardera force-pushed the feat/frame-scheduling branch 2 times, most recently from 09fa863 to 54cc8fd Compare June 21, 2025 22:47
@ardera ardera changed the base branch from master to devel September 13, 2025 14:48
Only diagnose flutter-pi sources by default.

The diagnosis results are uploaded as an HTML workflow artifact for
debugging.

Also, remove the old (unused) CodeQL workflow, which had a lot of
hard to disable false positives.
Mostly double-float casts, functions without arguments without an
explicit `void` in the parameter list, but in platformchannel.c there
were actually some memory leaks on error paths, which are now fixed.

Also enable -pedantic for even more diagnostics.
drmdev: (mostly) non-stateful part. Basically a better wrapper around a drm fd.
Fully mt-safe.

Also properly separate kms_req from drmdev. kms_req now mostly
accesses public drmdev API, instead of having access to hidden
drmdev state.

drm_resources: the DRM state / resources. Is stateful, but does not update itself.
To keep it in sync with kernel state, one needs to listen to kernel events with drm_monitor and call drm_resources_update.
drm_resources is not mt-safe and only supposed to be used on a single thread.

Also add a bunch of QoL stuff to drm_resources.
To be able to specify more surface usage hints, i.e. `GBM_BO_USE_SCANOUT`
and `GBM_BO_USE_RENDERING`.
Always do non-blocking atomic commits.

To resolve issues with flutter trying to present frames too soon,
while another frame was already sent to the kernel (i.e. comitted via
KMS atomic commit), we either have to discard subsequent, too-early
frames or queue them.

In this case, we basically keep a 1-frame deep queue (or 2-frames,
if you count the in-kernel waiting-for-scanout frame), with the 1 queued
frame being displaced whenever a newer frame is available.

(Similar to vulkans MAILBOX swapchain presentation mode)
Call the release callback for the commit that is no longer visible on screen before calling the scanout callback.

The scanout callback might already start a new frame, and the release callback releases some resources that could be useful for building the new frame, so this helps avoid resource exhaustion.
libdrm's drmIsKMS was added in libdrm 2.4.105:
    https://gitlab.freedesktop.org/mesa/libdrm/-/commit/523b3658aa8efa746417e916c987de23740ce313

Debian bullseye is still on 2.4.104, so it's unfortunately not present
there.
Fix waiting_for_scanout not being set when a frame is presented
directly in the on_scanout callback, sometimes causing another frame
to be presented, resulting in an EBUSY from drmModeAtomicCommit.
Make frame_scheduler able to time frames, e.g. tell flutter when to
start rendering a frame when it receives a frame request.

For now, if no frame is currently waiting to be scanned out, this
just responds to the frame request with the current frame and a 60Hz
frame interval, i.e. starts the frame immediately.

If a frame is waiting to be scanned out, this waits until the scanout
to reply to the frame timings request. (With the timestamp of the
scanout being used as the frame start time in the reply to the frame
timings request)

If another frame is already queued after that, the scheduler will
wait until that other queued frame is scanned out to reply to the frame
timings request.
@ardera ardera force-pushed the feat/frame-scheduling branch from 54cc8fd to 63a72af Compare September 14, 2025 11:20
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.

1 participant