Thanks for careful review.
1. My mistake for the XXXXs, we can remove it.
There is MESA_FORMAT_YCBCR_REV for UYVY, so MESA_FORMAT_YCBCR is
exactly for YUYV format.
GL_LUMINANCE should be ok since YUYV is an luminance format.
2. as to intel_image_target_texture_2d(), an error is added for YUYV region.
Updated patch see below.
3. A test case is added to demonstrate the usage:
http://lists.freedesktop.org/archives/mesa-dev/2012-June/022487.html
As to the case when hw overlay is not available, it is considered in
following way:
3.1) when client connect to wayland-server, it gets which formats are
supported from server in drm_handle_format(). Client sends YUYV buffer to
server only when the server supports it.
Client can convert a YUYV/NV12 buffer to XRGB format through
libva: http://lists.freedesktop.org/archives/libva/2012-May/000845.html
(YUYV<-->NV12/YV12 are supported)
3.2) if Weston want to support YUYV internally, it can depend on
libva's color conversion or some special shader to do it.
>From 5356270a25a300bbe7e0d36a79b031d2fb108a88 Mon Sep 17 00:00:00 2001
From: Zhao halley <halley.z...@intel.com>
Date: Fri, 25 May 2012 11:36:48 +0800
Subject: [PATCH 2/7] mesa intel driver:
add YUYV format for dri image
YUYV image doesn't use for texture
---
src/mesa/drivers/dri/intel/intel_screen.c | 5 +++++
src/mesa/drivers/dri/intel/intel_tex_image.c | 6 ++++++
2 files changed, 11 insertions(+), 0 deletions(-)
mode change 100644 => 100755 src/mesa/drivers/dri/intel/intel_screen.c
mode change 100644 => 100755 src/mesa/drivers/dri/intel/intel_tex_image.c
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
old mode 100644
new mode 100755
index 458178f..b8d44ba
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen *screen,
image->internal_format = GL_RGB;
image->data_type = GL_UNSIGNED_BYTE;
break;
+ case __DRI_IMAGE_FORMAT_YUYV:
+ image->format = MESA_FORMAT_YCBCR;
+ image->internal_format = GL_LUMINANCE;
+ image->data_type = GL_UNSIGNED_BYTE;
+ break;
default:
free(image);
return NULL;
diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
b/src/mesa/drivers/dri/intel/intel_tex_image.c
old mode 100644
new mode 100755
index 094d3cd..8b94cb1
--- a/src/mesa/drivers/dri/intel/intel_tex_image.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_image.c
@@ -388,6 +388,12 @@ intel_image_target_texture_2d(struct gl_context *ctx,
GLenum target,
if (image == NULL)
return;
+ if (image->format == MESA_FORMAT_YCBCR) {
+ _mesa_error(&intel->ctx,
+ GL_INVALID_OPERATION, "glEGLImageTargetTexture2DOES, attach
YUYV region to texture is not supported");
+ return;
+ }
+
intel_set_texture_image_region(ctx, texImage, image->region,
target, image->internal_format,
image->format);
}
--
1.7.5.4
> -----Original Message-----
> From: Eric Anholt [mailto:e...@anholt.net]
> Sent: Saturday, June 02, 2012 5:33 AM
> To: Zhao, Halley; mesa-dev@lists.freedesktop.org
> Cc: Barnes, Jesse; Zhao, Halley
> Subject: Re: [PATCH 2/6] mesa intel driver:
>
> On Thu, 31 May 2012 17:23:59 +0800, Zhao halley <halley.z...@intel.com>
> wrote:
> > add YUYV format for dri image
> > YUYV image doesn't use for texture
> > ---
> > src/mesa/drivers/dri/intel/intel_screen.c | 5 +++++
> > src/mesa/drivers/dri/intel/intel_tex_image.c | 3 +++
> > 2 files changed, 8 insertions(+), 0 deletions(-) mode change 100644
> > => 100755 src/mesa/drivers/dri/intel/intel_screen.c
> > mode change 100644 => 100755
> > src/mesa/drivers/dri/intel/intel_tex_image.c
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
> > b/src/mesa/drivers/dri/intel/intel_screen.c
> > old mode 100644
> > new mode 100755
> > index 458178f..5ff2e49
> > --- a/src/mesa/drivers/dri/intel/intel_screen.c
> > +++ b/src/mesa/drivers/dri/intel/intel_screen.c
> > @@ -216,6 +216,11 @@ intel_create_image_from_name(__DRIscreen
> *screen,
> > image->internal_format = GL_RGB;
> > image->data_type = GL_UNSIGNED_BYTE;
> > break;
> > + case __DRI_IMAGE_FORMAT_YUYV:
> > + image->format = MESA_FORMAT_YCBCR; // XXXX no detailed
> YUV format in mesa yet
> > + image->internal_format = GL_LUMINANCE; // XXXX no detailed
> YUV format in gles2 yet
> > + image->data_type = GL_UNSIGNED_BYTE;
> > + break;
> > default:
> > free(image);
> > return NULL;
>
> I don't like seeing these XXXs added that suggest that this commit isn't
> ready.
>
> > diff --git a/src/mesa/drivers/dri/intel/intel_tex_image.c
> > b/src/mesa/drivers/dri/intel/intel_tex_image.c old mode 100644 new
> > mode 100755 index 094d3cd..e5c3bdc ---
> > a/src/mesa/drivers/dri/intel/intel_tex_image.c +++
> > b/src/mesa/drivers/dri/intel/intel_tex_image.c @@ -388,6 +388,9 @@
> > intel_image_target_texture_2d(struct gl_context *ctx, GLenum target,
> > if (image == NULL) return;
> >
> > + if (image->format == MESA_FORMAT_YCBCR)
> > + return;
> > +
> > intel_set_texture_image_region(ctx, texImage, image->region,
> > target, image->internal_format,
> > image->format); }
>
> So, you don't actually attach the region to the texture? If you don't support
> rendering from the format as a texture, why is this not throwing an error?
>
> I don't understand yet how this series really gets used. As far as I
> understand,
> wayland likes to use the image directly as an overlay if possible, but
> sometimes
> it can't. At that point, it needs to be able to do GL rendering using that
> image
> as a source, right? So, how is the compositor supposed to handle the format
> in that case, if it can't texture from it?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
