Re: [PATCH 06/11] drm/i915: Check the framebuffer offset

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

On Thu, Nov 01, 2012 at 03:18:04PM +0100, Daniel Vetter wrote:
> On Thu, Nov 1, 2012 at 3:09 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >> Userspace doesn't use this today at all even in the panning case?
> >
> > If it does, then the user is going to be upset when nothing happens.
> > Only the x/y offsets are effective with the current code.
> >
> >> I
> >> know it worked at one point at least, but that may have been back in
> >> the UMS days...
> >
> > Before my time.
> 
> Afaik the fb->offsets have been added to support planar formats with
> all planes smashed into the same buffer object (where the fourcc alone
> doesn't specify anything about inter-plane offsets). We don't support
> planar buffers, so enforcing an offset of 0 is imo totally ok.

There's also another use case for it. That is, if you specify a source
rectangle for a plane, which is smaller than the full fb, then it's
perfectly legal for the plane to access the pixels outside the source
rectangle to produce good looking filtered edges. But when the source
rectangle edge matches the fb edge, then it's clearly not OK to do
that. So if you want to cut the edges of your source rectangle sharply,
then you can do it through fb->offsets[].

It's similar to texturing w/ GL_CLAMP_TO_EDGE. The texture coordinates
are clamped so that nothing outside the texture is sampled, but
when sampling inside the texture, the filter can blend in texels that
are not inside the area specified by the texture coordinates.

But I supose doing this could be easier if we just added a property
to the plane which specifies how the filtering is done at the edges
of the source rectangle. Then you at least wouldn't need to create
a new fb every time the source rectangle changes.

-- 
Ville Syrjälä
Intel OTC