From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
Matthew Auld <matthew.william.auld@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Reject non-canonical rotations
Date: Wed, 23 Mar 2016 15:30:48 +0200 [thread overview]
Message-ID: <1458739848.31507.4.camel@linux.intel.com> (raw)
In-Reply-To: <20160323085831.GK28483@phenom.ffwll.local>
On ke, 2016-03-23 at 09:58 +0100, Daniel Vetter wrote:
> On Tue, Mar 22, 2016 at 02:14:38PM +0000, Matthew Auld wrote:
> >
> > Hi Daniel,
> >
> > >
> > > >
> > > > I thought we do normalize this somewhere.
> > I did write an i-g-t test which submits such a rotation value and it
> > is not rejected.
> Normalize = the drm core makes sure drivers don't see all the
> combinations, but only canonical values. Userspace can still submit values
> with too many bits set. I'm not sure we want (or can, it's ABI) change
> that.
>
> >
> > >
> > > >
> > > > Your patch lacks motivation
> > As in I haven't properly conveyed the motivation behind the patch in
> > the commit message?
> >
> > >
> > > >
> > > > Yes I can usually guess when
> > it's due to static analyzer checks, but you need to explain that. And you
> > need to explain what exactly the analyzer is complaining about.
> >
> > erm, no static analyser, for this patch or any prior, promise, but duly noted ;)
> >
> > Joonas actually suggested this patch, and some of the preceding ones
> > as beginner tasks for me.
> Oh surprising, spotting all these random things all over tends to be stuff
> only static analyzers manage ;-) Patch still needs some motivation, since
> if your igt passes and the driver behaves correctly it's all fine.
I'm happy to mention that the motivation this was on my backlog is that
it was *YOU* who asked me to implement it along with the IGT tests :P
But I guess, now if it's implemented in DRM layer already, matter of
making sure the kms_rotation_crc tests the current expected behaviour.
And by what you described (drivers won't see bad values, ABI accepts
them), it would mean to just attempt to send invalid combinations, they
should be happily accepted but resulting rotation will be undefined. I
myself would reject invalid bit combinations, but if the ABI has
already grown that way, not much to be done at this point.
Regards, Joonas
> -Daniel
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-23 13:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 10:35 [PATCH] drm/i915: Reject non-canonical rotations Matthew Auld
2016-03-22 10:43 ` Ville Syrjälä
2016-03-22 10:48 ` Matthew Auld
2016-03-22 10:59 ` Ville Syrjälä
2016-03-22 11:36 ` Daniel Vetter
2016-03-22 14:14 ` Matthew Auld
2016-03-23 8:58 ` Daniel Vetter
2016-03-23 13:30 ` Joonas Lahtinen [this message]
2016-03-23 16:18 ` Daniel Vetter
2016-03-23 16:24 ` Matthew Auld
2016-03-23 16:30 ` Ville Syrjälä
2016-03-22 12:32 ` ✗ Fi.CI.BAT: warning for " Patchwork
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=1458739848.31507.4.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.william.auld@gmail.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).