lkml.org 
[lkml]   [2014]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Intel-gfx] [PATCH v5 11/11] drm/i915: Calling rotate and inverse rotate transformations after clipping
From
Date
On Tue, 2014-02-11 at 16:56 +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2014 at 05:02:31PM +0530, Sagar Arun Kamble wrote:
> > On Mon, 2014-02-10 at 15:32 +0200, Ville Syrjälä wrote:
> > > On Mon, Feb 10, 2014 at 01:01:18PM +0530, sagar.a.kamble@intel.com wrote:
> > > > From: Sagar Kamble <sagar.a.kamble@intel.com>
> > > >
> > > > With clipped sprites these transformations are not working. these
> > > > functions transform complete sprite irrespective of clipping present.
> > > > This leads to invisible portion of sprite show up when rotate 180 if
> > > > it was out of visible area before.
> > > >
> > > > v4: Moved rotate transform for source rectangle after clipping.
> > > > Added rotate and inverse rotate transform for destination rect.
> > >
> > > Still NAK.
> > >
> > > I just pushed rotation support to my glplane test app [1], and with
> > > with that my rotated clipping code works exactly as intended.
> > >
> > > [1] git://gitorious.org/vsyrjala/glplane.git
> > I tried this app. I think I am considering 180 degree rotation of
> > clipped sprite plane differently. I have captured output with these
> > rotate transforms moved before(clip-rotated) and after(rotate-clipped)
> > clipping code.
> >
> > Which is valid? Rotating entire sprite and then clipping or Rotating
> > clipped portion?
> >
> > Reference and Rotated output is attached FYI.
> >
> > If rotating entire sprite is correct then this patch 11/11 is not needed
> > and can be abandoned.
>
> The way I think of these things is roughly this:
>
> You have the user specified source rectangle, where the coordinates specify
> the viewport into the framebuffer. This coordinate space is oriented the
> same was as the framebuffer itself, ie. the first pixel of the
> framebuffer is at coordinates 0,0. So plane rotation doesn't affect this
> at all.
>
> Then you have the user specified destination/crtc rectangle, where the
> coordinates specify the position of the plane within the crtc coordinate
> space. So the first visible pixel the pipe will push out is at
> coordinates 0,0. So again plane rotation doesn't affect this.
>
> Then you have the rotation which simply specifies the transformation to
> be applied to the pixels when they "move" from the source rectangle to
> the destination rectangle. So w/ 0 degree rotation the pixel at
> src_x,src_y in the framebuffer will appear at position crtc_x,crtc_y
> on the crtc output. With 180 degree rotation the pixel at src_x,src_y
> will appear at crtc_x+crtc_w-1,crtc_y+crtc_h-1.
>
> As clipping happens in the crtc coordinate space, we need to orient
> the source coordindates the same way to get the correct clipping result.
> So for example with 0 degrees rotation clipping the left side of the
> destination rectangle must result in clipping the left side of the source
> rectangle as well. And with 180 degree rotation clipping the destination
> rectangle on the left side must result in clipping the source rectangle
> on the right side. Left and right in each case referring to the original
> unrotate coordinates.
>
> So let's say we have the following situation w/ 180 degree rotation.
> The letters inside the rects represented specific named pixels,
> the FB rectangle represents the FB as specified by addfb2 ioctl,
> the CRTC rectangle represents the pipe output (0,0 -> PIPESRC.w,h):
>
> FB: CRTC:
> 0,0 ___________ 0.0 __________
> | abcd | | |
> | efgh | | |
> |_________| |hgfe |
> |dcba_____|
> unclipped coordinates specified by user:
> src_x=2,src_y=0 crtc_x=0,crtc_y=2
> src_w=4.src_h=2 crtc_w=4,crtc_h=2
>
> clipped coordinates:
> src_x=2,src_y=0 crtc_x=0,crtc_y=2
> src_w=4.src_h=2 crtc_w=4,crtc_h=2
>
>
> Then the user moves the sprite one pixel to the left resulting on some
> clipping (the X pixels). Note that the unclipped source coordinates do
> not change here at all, in fact crtc_x is the only thing changed by the
> user:
>
> FB: CRTC:
> 0,0 ___________ 0.0 __________
> | abcX | | |
> | efgX | | |
> |_________| Xgfe |
> Xcba______|
> unclipped coordinates specified by user:
> src_x=2,src_y=0 crtc_x=-1,crtc_y=2
> src_w=4.src_h=2 crtc_w= 4,crtc_h=2
>
> clipped coordinates:
> src_x=2,src_y=0 crtc_x=0,crtc_y=2
> src_w=3.src_h=2 crtc_w=3,crtc_h=2
>


Understood this now. Thank you Ville for providing this elaborate
graphical view of the rotation cases.

-Sagar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-02-11 19:21    [W:0.134 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site