Skip to content

Multiview Support #446

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 32 commits into
base: master
Choose a base branch
from
Open

Multiview Support #446

wants to merge 32 commits into from

Conversation

ardera
Copy link
Owner

@ardera ardera commented Sep 17, 2024

No description provided.

- add codechecker workflow
- enable `-pedantic`
- fix a lot of warnings
- only report error from `gbm_surface_create_with_modifiers` if `gbm_surface_create` fails too
@eu-erwin
Copy link

eu-erwin commented Oct 8, 2024

@ardera

does this PR support multi display? I would like to help on testing, I have DSI and HDMI displays.

is this run on single flutter engine or multiple engines?

@vanlooverenkoen
Copy link

@ardera can you maybe add a video or a linked ticket, in case we want to test this so we know what to actually test?

ardera added 6 commits June 21, 2025 11:31
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`.
ardera added 17 commits June 21, 2025 12:20
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.
- add multidisplay plugin stub
- make compositor multiview capable
  - use klib (khash) to implement the
    view id -> window mapping
- use evloop as platform and raster thread
  event loop (mt-safe wrapper around sd-event)
- add own mutex type & fns with thread safety annotations
- generally refactor flutter-pi.c and drmdev
- fix function mixup in sentry plugin
- kms: add drm device monitor
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.

3 participants