tonarino / just-gl Goto Github PK

It would be nice to get rid of the flicker in the colorful_triangle example.

I'm not sure there is a simple blocking call that waits for the next vsync. There is a DRM page_flip call that can both display a frame and also optionally produce a PageFlip event. We are already using this call but not only for presentation, not vsync.

One is presumably supposed to wait for those events somehow but I haven't found a way with the drm crate.
Existing implementations seem to be doing either a select on the DRM file descriptor [1], [2], or in case of slint they somehow use their event loop together with DRM call receive_events [3].

Alternatively, there is a DRM wait_vblank call that seems to have a blocking version but it also requires some "target sequence" parameter that has something to do with absolute or relative frame scheduling. I am not sure how those are supposed to work.

[1] https://gitlab.freedesktop.org/mesa/kmscube/-/blob/master/drm-legacy.c#L127
[2] https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset-vsync.c#L591
[3] https://github.com/slint-ui/slint/blob/master/internal/backends/linuxkms/display/egldisplay.rs#L136

Currently just-gl refuses to start if specified connector doesn't have a monitor connected.

The ideal behavior is that just-gl checks that the requested connector is valid for requested GPU, but doesn't fail if it is disconnected. It would instead create some kind of a virtual framebuffer (that would be however tied to the specified GPU - perhaps attaching to some of its CRTCs already). Once the monitor connects, it would set the desired mode (failing if it isn't available) and make the framebuffer visible on it.

Xorg can do this, so there should be a way for the underlying technology to support that. (an application just need to go lenghts to achieve this with Xorg - short of hand-crafting xorg.conf and carefully orchestrating xrandr calls).

Definitely not needed for MVP, but this is one of the motivating factors for tonari to move out of Xorg, so it would be nice to demonstrate this is possible.

Based on my investigation so far it should be easiest to support GPU rendering via glium + glutin.

1. We need to create a simple Window struct holding GBM context and implement HasRawWindowHandle & HasRawDisplayHandle for it.
2. Next, it should be possible to initialized glutin with our Window. It should support GBM handles out of box.
3. Finally, glium should work with the glutin context.

Other alternatives require (minor) forking to support GBM RawWindowHandle & RawDisplayHandle.

• wgpu: after forking it should work with our framebuffers directly, just like glutin does.
• winit: after forking we could use its windows for full windowing functionality and provide windows to any compatible graphics API.

I'm struggling a bit with the GL setup. I think it's a bit too much work to figure all these pieces from the first principles, certainly for me, so I decided to get some C program working first and then port it to Rust.

I found this [1] which looks promising but fails in encoder initialization.
I also tried kmscube [2] but that fails when adding a framebuffer with "Invalid argument".

It would be great if anyone could get either one of these or any other similar program running, so we have some real example to learn from.

[1] https://github.com/eyelash/tutorials/blob/master/drm-gbm.c
[2] https://gitlab.freedesktop.org/mesa/kmscube/

Currently we do just .expect(), which doesn't scale.

Do people (@mbernat?) have opinions on "dynamic" errors (anyhow) vs. more statically defined (thiserror)?

If we target being a library, then static thiserror-like errors are more appropriate, but I wonder if that isn't an overkill doing now in the prototyping phase. (we should start with anyhow and eventually convert to thiserror).

And meybe there's some alternative to the 2 mentioned libraries?

Just to track this as an issue rather than PR.

More information in a WIP PR that adds some debugging #1

• Extracting from #6 (comment)

Even for a prototype it would be nice to have a little bit of library code, I'm not super fond of having everything in main.rs.

CC @mbernat

I assume that running just-gl in parallel on 2 different GPUs works already.

A question is: is is possible to run 2 instances of just-gl which both use the same GPU, but different outputs (and CRTCs) of it?

It may work already, or it may be straight impossible. This issue is more about testing what works and mapping the possibilities rather than implementing a solution.

The motivation is tonari's use-case - though it is not a showstopper if just-gl cannot feasibly support this.

• A converse of #8 - also with tonari use-case

The 2 displays would display entirely independent contents (no Xorg-like virtual framebuffer that spans all connected monitors).

Questions:

• Can we still have vsync on each of the connected monitors, even if they differ? (50 Hz vs. 60 Hz)

Definitely post-MVP.