[Mesa-dev] [PATCH 00/10] egl: mixed bag of fixes/cleanups
Emil Velikov
emil.l.velikov at gmail.com
Tue Aug 29 10:28:27 UTC 2017
Hi Dan,
Thanks for having a look.
On 28 August 2017 at 14:50, Daniel Stone <daniel at fooishbar.org> wrote:
>> egl/wayland: plug leaks in dri2_wl_create_window_surface() error path
>> egl/wayland: polish object teardown in dri2_wl_destroy_surface
>
> Reviewed-by: Daniel Stone <daniels at collabora.com>
>
Guessing that the r-b stands for both patches?
>> egl: allow RGB565 formats in eglCreateWaylandBufferFromImageWL
>
> I've been avoiding trying to expand use of this API, in all honesty.
>
Any particular reason?
Quick search on the webs + my system shows no users of the extension,
apart from weston-nested.
Even there it's not a hard requirement.
Any ideas if the extension was ever used [elsewhere], should we
consider deprecating it?
>> egl: add juicy comment about WL_bind_wayland_display +
>> wl_drm/wl_dmabuf
>
> It depends on a couple of things, really. Firstly, on Mesa's general
> feature deprecation schedule. Secondly, on external support
> (Weston/Mutter/Enlightenment are fine, no support yet in
> KWin/WLC/Smithay/...). Thirdly, on how cleanly we can separate it. If
> we can break out all the BindWaylandDisplay code more than we already
> have, it might be easier to maintain. And lastly, on NVIDIA: I believe
> being a Streams provider requires BindWaylandDisplay, so we might need
> that to be replaced before we can rip it out of Mesa.
>
> Having the comment expanded to cover these might be nice.
>
Fully agree on all points, although I think the priority is in the opposite way.
But above all does the extension make sense, or even yet, can it be
implemented with wl_dmabuf?
>> egl/wayland: group wl_win specific code together
>> egl/wayland: make sure HAS_$FORMAT is set for wl_dmabuf
>
> Reviewed-by: Daniel Stone <daniels at collabora.com>
>
As above - I'm guessing the r-b stands for both patches?
Thanks again.
Emil
More information about the mesa-dev
mailing list