dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org,
	VMware Graphics <linux-graphics-maintainer@vmware.com>,
	Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping
Date: Thu, 23 Nov 2017 11:46:54 +0200	[thread overview]
Message-ID: <2946934.SbCksEAum8@avalon> (raw)
In-Reply-To: <20171106180437.GM10981@intel.com>

Hi Ville,

On Monday, 6 November 2017 20:04:38 EET Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> >> On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> 
> >>> Try to fix the code to actually clip the plane to the crtc bounds
> >>> instead of the user provided crtc coordinates (which would be a no-op
> >>> since those are exactly the coordinates before clipping).
> >>> 
> >>> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> >>> Cc: Sinclair Yeh <syeh@vmware.com>
> >>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> 
> >> I kinda wonder whether we shouldn't push this down into the helper ...

I think that would be nice.

> > Would require quite going through all drivers making sure they are
> > happy with using the adjusted_mode.crtc_ timings. I think most drivers
> > use the other adjusted_mode timings currently, and some even use the
> > user mode timings (which could be an actual bug).
> 
> Let me take that back. What we want is to clip to the user mode
> timings. Stereo 3D needs the special treatment from
> drm_mode_get_hv_timing(). I'm getting confused by all these
> different timings we have all over the place.
> 
> I think for i915 all we would need is to change the double wide/dual
> link adjustent for pipe_src_w to simply reject odd widths instead.
> That would guarantee that the user mode timings match the pipe_src_w/h
> 100%.
> 
> For the other driver we'd need to figure out why they're using
> adjusted_mode timings for clipping. I guess that's just a mistake,
> which I repeated here with vmwgfx after getting confused by looking
> at the other drivers.

I suppose it's a mix of cargo-cult and the fact that adjusted_mode hints that 
it contains the timings that should be applied to the hardware. That's why I 
use it in rcar-du.

Are drivers allowed to adjust the hdisplay and vdisplay values though ? I 
thought unsupported values there had to be rejected with an error at atomic 
check time, not adjusted.

> I guess I just volunteered myself to do this. Just needs plenty of
> acks from driver maintainers I suppose.

I'll review and test the rcar-du patch :-)

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-11-23  9:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 18:29 [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff Ville Syrjala
2017-11-01 18:29 ` [PATCH 1/5] drm/vmwgfx: Remove bogus crtc coords vs fb size check Ville Syrjala
2017-11-02 10:04   ` Daniel Vetter
2017-11-23  9:54   ` Laurent Pinchart
2017-11-01 18:29 ` [PATCH 2/5] drm/vmwgfx: Use drm_plane_helper_check_state() Ville Syrjala
2017-11-02 10:06   ` Daniel Vetter
2017-11-23  9:54   ` Laurent Pinchart
2017-11-01 18:29 ` [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping Ville Syrjala
2017-11-02 10:12   ` Daniel Vetter
2017-11-02 13:19     ` Ville Syrjälä
2017-11-06 18:04       ` [Intel-gfx] " Ville Syrjälä
2017-11-07 12:30         ` Daniel Vetter
2017-11-23  9:46         ` Laurent Pinchart [this message]
2017-11-01 18:29 ` [PATCH 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state() Ville Syrjala
2017-11-01 20:15   ` [PATCH v2 " Ville Syrjala
2017-11-02 10:15     ` Daniel Vetter
2017-11-23  9:52   ` [PATCH " Laurent Pinchart
2017-11-01 18:29 ` [PATCH 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c Ville Syrjala
2017-11-01 20:16   ` [PATCH v2 " Ville Syrjala
2017-11-02 10:16     ` Daniel Vetter
2017-11-23  9:53   ` [PATCH " Laurent Pinchart
2017-11-10 21:26 ` [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff Sinclair Yeh
2017-11-10 21:42   ` Ville Syrjälä
2017-11-20  7:34     ` Daniel Vetter
2017-11-20 17:32       ` Sinclair Yeh
2017-11-20 19:36         ` Ville Syrjälä
2017-11-23  9:56           ` Laurent Pinchart

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=2946934.SbCksEAum8@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=thellstrom@vmware.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;
as well as URLs for NNTP newsgroup(s).