-
Notifications
You must be signed in to change notification settings - Fork 342
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't looked into this in detail, but here are some general comments.
Something quite similar has been worked on for the DRM backend. I think ti would make sense to use the renderer v6's wlr_swapchain
here too. See #2240
GBM buffer allocation. Would it be better to get the render node from DRM if the renderer belongs to DRM?
It may make sense to add wlr_renderer_get_fd
. See #1376 (comment)
@@ -164,6 +164,14 @@ bool wlr_renderer_blit_dmabuf(struct wlr_renderer *r, | |||
return r->impl->blit_dmabuf(r, dst, src); | |||
} | |||
|
|||
GLuint wlr_renderer_renderbuffer_from_image(struct wlr_renderer *r, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This leaks EGL/GL implementation details into the generic renderer interface.
render/egl.c
Outdated
@@ -419,6 +419,9 @@ void wlr_egl_save_context(struct wlr_egl_context *context) { | |||
} | |||
|
|||
bool wlr_egl_restore_context(struct wlr_egl_context *context) { | |||
if (!context->display) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't correctly restore EGL_NO_DISPLAY
.
#1376 now has |
5454eaf
to
0db4b75
Compare
0db4b75
to
55abc24
Compare
This is very much work in progress, but it does work quite well.
Things I'd like some feedback on:
glEGLImageTargetRenderbufferStorageOES
into the backend is rather ugly. Suggestions?