Skip to content
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

Add extra EGL extensions #1668

Merged
merged 1 commit into from
Jun 6, 2024
Merged

Conversation

chrisduerr
Copy link
Contributor

This patch adds multiple new EGL extensions which are useful for
implementing Wayland applications. These have been mostly implemented
manually, since gl_generator lacks support for these newer EGL
extensions (except for EGL_KHR_image_base).

The following extensions were added:

  • EGL_KHR_image_base
  • EGL_WL_bind_wayland_display
  • EGL_WL_create_wayland_buffer_from_image

Currently this PR doesn't really implement a good way to access this new functionality, instead it just exposes the EGL static publicly. Ideally there would be some abstraction that retrieves the Egl object, while automatically making sure it is initialized.

So I see two options, feedback appreciated:

  • Expose method that basically just does EGL.as_ref()? (does not ensure initialization)
  • Add method to Display (requires display creation)

@MarijnS95
Copy link
Member

Fwiw for #1658 I'd also like to use updated EGL bindings from gl_generator, which is very trivial to achieve: brendanzab/gl-rs#546

Unfortunately it seems that efforts to transition ownership of gl-rs (which is still an important cornerstone in the Rust ecosystem) have stalled: brendanzab/gl-rs#524

@kchibisov
Copy link
Member

I'm not sure how we should expose the ref to EGL and similar types, since we should have it for all the platforms where we use loader (so, except macOS).

Maybe we should have a method to manually load(which will return Option) and just a method to get a &'static Egl from the Display(this will always work)? And the manual loading will be present only for EGL, because the rest is a bit special and shouldn't be used anyway in the context of device extensions.

I'm also interested in solving the generator issue upstream, but I'll see what we can do

@chrisduerr
Copy link
Contributor Author

I added some functions to access the APIs for EGL and GLX. This works for my usecase at least, so maybe that's enough to just merge it?

Let me know if you want a cleaner/more elaborate solution.

Copy link
Member

@kchibisov kchibisov left a comment

Choose a reason for hiding this comment

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

Not sure what to do with wgl...

glutin/src/api/egl/mod.rs Show resolved Hide resolved
glutin/src/api/egl/mod.rs Outdated Show resolved Hide resolved
glutin/src/display.rs Outdated Show resolved Hide resolved
glutin_egl_sys/src/egl.rs Show resolved Hide resolved
This patch adds multiple new EGL extensions which are useful for
implementing Wayland applications. These have been mostly implemented
manually, since gl_generator lacks support for these newer EGL
extensions (except for `EGL_KHR_image_base`).

The following extensions were added:
 - EGL_KHR_image_base
 - EGL_WL_bind_wayland_display
 - EGL_WL_create_wayland_buffer_from_image

This also exposes EGL and GLX raw API calls on EGL and GLX displays.
@kchibisov kchibisov merged commit 6af4c60 into rust-windowing:master Jun 6, 2024
43 checks passed
pub const TEXTURE_Y_XUXV_WL: i32 = 0x31D9;
pub const TEXTURE_EXTERNAL_WL: i32 = 0x31DA;
// Accepted in the <attribute> parameter of eglQueryWaylandBufferWL.
pub const EGL_TEXTURE_FORMAT: i32 = 0x3080;
Copy link
Member

Choose a reason for hiding this comment

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

@MarijnS95
Copy link
Member

For completeness, since I mentioned updating EGL headers in gl-generator above, here's a branch showcasing that everything is still there when generated with a newer generator:

https://github.com/MarijnS95/glutin/compare/gl-generator-update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants