Handle client EGL-backed buffers

[elinorbgr]

This will require:

• Understanding the mesa<->wayland compositor integration
• Expose a way to fetch the contents of an EGL buffer in a way directly usable to render on OpenGL backends

[elinorbgr]

Ooookay, looks like we'll encounter user_data issues again, this time with mesa. It uses it in its wl_buffers.

sigh Designing these rust bindings is really not easy.

[Timidger]

:( I do wish Wayland was more amendable to the Rust memory model. Doubly so because compositors control so much, I would feel much more secure letting my all-knowing compositor be written in something like Rust that is much less likely to have memory exploits than in C.

[Drakulix]

Mesa puts data into wl_buffers user data and expects the compositor to read it? This sounds completely broken and like something that should be handled by a real protocol. How is the compositor supposed to use this "user data", if it has to rely on it for communication..

[elinorbgr]

No, mesa do not expect anyone to read its user data, but rather uses it internally.

However, wayland_server (and wayland_client) rely so much on the user_data field to maintain the safety of the bindings that I had to make the assumption that these libs would be the only source of object creation, and thus that I would exclusively control this field.

With mesa, this assumption is obviously false. I'm thinking about how I can relax it.

[Drakulix]

This is still unreasonable. How are you expected to ever use the user_data field on a wl_buffer, if almost any compositor needs to work together with mesa.

With mesa, this assumption is obviously false. I'm thinking about how I can relax it.

My best idea is a giant global HashMap.

[elinorbgr]

Hmm, actually I think I found a way to discriminate between objects managed by my crates vs other crates.

I'll need to refactor a bit wayland-client/server (and release a new breaking version I think), but this would solve it once and for all. And probably solve the compability with WLC issues, maybe. I need to dig into that more.

[elinorbgr]

I think this would work: Smithay/wayland-rs#98.

[elinorbgr]

Okay. This will be funky. From what I gathered from weston and WLC, the magic stuff comes from the EGL_WL_bind_wayland_display extension (implying that we require an EGL context).

From this, we can retreive the contents of a wl_buffer coming from an OpenGL client into an EGLImage.

Looks like this EGLImage must then be drawn onto an EGL texture using glEGLImageTargetTexture2DOES...

To be honest, I'm completely discovering all this :D

I think, as a first step, I'll setup an API to expose the EGLImages.

[Drakulix]

And probably mark it unsafe as a EGLContext is required.

[elinorbgr]

Yes, as a first step, exposing a few unsafe functions will be the easiest I think.

However, while working on this yesterday, I realised that the glutin backend, while good for first startup of the project, will probably not be viable in the long term:

• To handle opengl clients, we need to use this EGL mechanism, which means the OpenGlGraphicsBackend of the compositor must be EGL-based, even on X11 (and not GLX), which glutin does not guarantee us.
• The trait OpenGLGraphicsBackend as we define it currently (inspired by glutin) is probably a little too high-level, and we need it to expose methods to query the OpenGL extensions, and get access to tje EGLDisplay, which glutin does not provide.

[Drakulix]

Then we refactor it to use winit directly, setup an EGLContext manually and extend the OpenglGraphicsBackend (maybe rename it EglGraphicsBackend then) to provide the required additional functions. That way we can still keep the glium::Backend implementation.

[elinorbgr]

Oh right. Didn't think about that. This would probably be the easiest way forward, the logic for handling EGL in glutin is pretty small. This would allow it to build an EglGraphicsBackend more customized to our needs.

Not sure how high priority it'd be though. There is a lot of other stuff we can improve on with more immediate results using the glutin backend, and I'm definitely not familiar enough with EGL.