Re: [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Dec 19, 2012 at 12:03:09PM +0000, Chris Wilson wrote:
> On Wed, 19 Dec 2012 13:56:12 +0200, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Dec 18, 2012 at 11:57:05PM +0100, Daniel Vetter wrote:
> > > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > > As we can only pass in the base address of the first plane, we can not
> > > > control the offset into the subsampled chroma planes. This means that we
> > > > cannot support a source offset into a YUV* linear framebuffer. However,
> > > > for tiled framebuffers we can tell the hardware which pixels to read
> > > > from. So if we see a source offset into a linear YUV framebuffer, report
> > > > the invalid value back to userspace.
> > > >
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > I can't see the original mail with the patch, where did it go?
> > 
> > > Aren't all the yuv formats we support packet planar?
> > 
> > No idea what packet planar means. All we currently support are packed
> > formats. The problem is that our code doesn't handle fb->offsets[].
> > 
> > If you're talking about src_x,src_y then those do work, at least on my
> > atomic branch. I don't remember changing the src_x/src_y related code
> > that much (apart from adding proper clipping), so I'm fairly sure they
> > should work in the upstream code as well.
> 
> They only work with a tiled source, as far as my investigation into the
> current code revealed.

Ah yeah it's the fb->bits_per_pixel problem. I though I submitted the
change to drm_format_plane_cpp() from my atomic branch, but I can't see
it in the upstream code. Either I forgot it, or it never got applied.

-- 
Ville Syrjälä
Intel OTC