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
next prev parent reply other threads:[~2017-11-23 9:46 UTC|newest]
Thread overview: 31+ 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-01 19:46 ` ✗ Fi.CI.BAT: failure for drm: drm_plane_helper_check_state() related stuff Patchwork
2017-11-01 20:10 ` Ville Syrjälä
2017-11-01 21:02 ` ✓ Fi.CI.BAT: success for drm: drm_plane_helper_check_state() related stuff (rev3) Patchwork
2017-11-01 21:52 ` ✓ Fi.CI.IGT: " Patchwork
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.