[Intel-gfx] [PATCH] drm/i915: The hw does not support source offsets into a YUV linear fb
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed Dec 19 12:56:12 CET 2012
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 at 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 at 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.
> So I think we
> should be able to support source offsets, as long as x is even ...
> Probably not worth the bother though.
The gen4+ plane hardware sucks. The gen3 video overlay handled sub-pixel
precision very nicely.
And we really want to handle source offsets, otherwise pan&scan isn't
possible.
--
Ville Syrjälä
Intel OTC
More information about the Intel-gfx
mailing list