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 at 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
