Hi,
Apologies if the mobile client mangles formatting. I've heard this new
version is better, so let's see if it's really true.

On Thu, 13 Jul 2017 at 5:20 pm, Jason Ekstrand <[email protected]> wrote:

> On July 13, 2017 4:13:53 AM Daniel Stone <[email protected]> wrote:
> > @@ -650,21 +650,23 @@ create_wl_buffer(struct dri2_egl_display *dri2_dpy,
> >     dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_FOURCC,
> &fourcc);
> >
> >     if (dri2_dpy->capabilities & WL_DRM_CAPABILITY_PRIME) {
> > +      struct wl_drm *wl_drm =
> > +         dri2_surf ? dri2_surf->wl_drm_wrapper : dri2_dpy->wl_drm;
>
> If the previous patch had dropped the dri2_surf parameter in favor of
> wl_drm, this wouldn't be needed.  Let's do that.


Except that the final patch uses zwp_linux_dmabuf_v1 instead of wl_drm. As
we don't need a proxy wrapper for dmabuf (since the intermediate 'params'
builder object can have a proxy set on it without being prone to races), we
really do need the surface: for wl_drm this selects between proxy objects,
and for dmabuf it selects between event queues. Maybe a lookup helper
function is in order? Dunno.


> > @@ -820,70 +822,19 @@
> dri2_wl_create_wayland_buffer_from_image(_EGLDriver *drv,
> >     struct dri2_egl_image *dri2_img = dri2_egl_image(img);
> >     __DRIimage *image = dri2_img->dri_image;
> >     struct wl_buffer *buffer;
> > -   int width, height, format, pitch;
> > -   enum wl_drm_format wl_format;
> >
> > -   dri2_dpy->image->queryImage(image, __DRI_IMAGE_ATTRIB_FORMAT,
> &format);
> > -
> > -   switch (format) {
> > -   case __DRI_IMAGE_FORMAT_ARGB8888:
> > -      if (!(dri2_dpy->formats & HAS_ARGB8888))
> > -         goto bad_format;
>
> These checks suddenly go away.  Is that intended?  Given that this entry
> point exists to let the user move a client wl_buffer to a different server,
> I think we want some checks here.


Good catch! Will do in v3, thanks.

Cheers,
Daniel


>
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to