public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: intel-gfx@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 11/11] drm/i915: Calling rotate and inverse rotate transformations after clipping
Date: Tue, 11 Feb 2014 16:56:15 +0200	[thread overview]
Message-ID: <20140211145615.GT3891@intel.com> (raw)
In-Reply-To: <1392118351.28501.21.camel@sagar-desktop>

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

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2014-02-11 14:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1392017478-4945-1-git-send-email-sagar.a.kamble@intel.com>
2014-02-10  7:31 ` [PATCH v5 01/11] drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 02/11] drm: Add support_bits parameter to drm_property_create_bitmask() sagar.a.kamble
2014-02-10 13:43   ` Ville Syrjälä
2014-02-10 14:05     ` [PATCH v2 " ville.syrjala
2014-02-11 11:02       ` Sagar Arun Kamble
2014-02-10  7:31 ` [PATCH v5 03/11] drm: Add drm_mode_create_rotation_property() sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 04/11] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property() sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 05/11] drm: Add drm_rect rotation functions sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 06/11] drm: Add drm_rotation_simplify() sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 07/11] drm/i915: Add 180 degree sprite rotation support sagar.a.kamble
2014-02-10 13:31   ` Ville Syrjälä
2014-02-10  7:31 ` [PATCH v5 08/11] drm/i915: Make intel_plane_restore() return an error sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 09/11] drm/i915: Add rotation property for sprites sagar.a.kamble
2014-02-10  7:31 ` [PATCH v5 10/11] drm/i915: Add 180 degree primary plane rotation support sagar.a.kamble
2014-02-10 13:32   ` [Intel-gfx] " Ville Syrjälä
2014-02-10  7:31 ` [PATCH v5 11/11] drm/i915: Calling rotate and inverse rotate transformations after clipping sagar.a.kamble
2014-02-10 13:32   ` [Intel-gfx] " Ville Syrjälä
     [not found]     ` <1392118351.28501.21.camel@sagar-desktop>
2014-02-11 11:59       ` Daniel Vetter
2014-02-11 12:09         ` Sagar Arun Kamble
2014-02-11 14:56       ` Ville Syrjälä [this message]
2014-02-11 17:36         ` Sagar Arun Kamble

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140211145615.GT3891@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sagar.a.kamble@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox