public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 0/5] New pipe level color management tests V5
Date: Tue, 8 Mar 2016 10:42:52 +0000	[thread overview]
Message-ID: <56DEACAC.8080608@intel.com> (raw)
In-Reply-To: <20160308024641.GB5450@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 4261 bytes --]

On 08/03/16 02:46, Matt Roper wrote:
> On Thu, Feb 25, 2016 at 05:16:08PM +0000, Lionel Landwerlin wrote:
>> Hi,
>>
>> This series enables testing pipe level color management using kernel patches
>> from this serie :
>>
>> https://patchwork.freedesktop.org/series/2720/
>>
>> Most of the tests use pipe CRCs to check the results by comparing the output
>> with the expected output drawn using cairo.
> These tests look good.  The only thing that might be worth adding is a
> test that intermixes the legacy gamma ioctl with full color management
> use.  I believe invoking the legacy ioctl should clear the degamma and
> CTM, right?  It might be worth checking that that actually happens.
That's right. We have drm_atomic_helper_legacy_gamma_set helper() to do 
this (https://patchwork.freedesktop.org/patch/75106/).
I'll add a test exercising that back and forth.

>
> Also, there was one misplaced patch hunk that I called out on patch 2/3.
Fixing.

>
> Aside from the final IGT tweaks, I think we're pretty close to merging.
> Here are the final opens I see:
>
>   * I expect we'll just merge this whole thing through the Intel tree,
>     even though patch #3 adds the properties, structures, and helpers to
>     the DRM core, so we need to get an okay from airlied.  Dave, do you
>     have any concerns about this?
>
>   * I know the ChromeOS guys have been reviewing this series
>     independently on their end and putting together the userspace (open
>     source) which will be using this.  We should get someone to formally
>     Ack this on their behalf; I think Rob Bradford has been working with
>     them; adding him to the Cc list to see if he can provide the Ack.
>
>   * I'm not sure if I ever saw a CI report for your final iteration.  I
>     may have just missed the email, or it may have never come out due to
>     the temporary FDO downtime or the CI outage last week.  Could you
>     provide a pointer to the results (with false positives justified with
>     bugzilla entries), or resubmit again for CI if necessary?

It's attached to the patchwork series : 
https://patchwork.freedesktop.org/series/2720/

The usual flaky tests are : suspend-read-crc-pipe-* and 
basic-flip-vs-modeset.
The force-load-detect and error-state-basic were failing for other 
people at the time I posted the v10 series.

>
>   * I'm still a little bit uncomfortable that we (the general DRM
>     community) never really came to a consensus on the whole
>     DRM_MODE_PROP_ATOMIC vs not question (both for this patchset and as a
>     general guideline going forward with similar features).  Emil had a
>     good argument that if we make something atomic-only to start with,
>     it's trivial to change in the future if we decide we actually want to
>     make use of it with a non-atomic userspace; on the other hand, if we
>     make it unrestricted on day one, that's a change we can't reverse
>     down the line since it becomes part of the ABI.  However nobody
>     seemed to really care very strongly either way during the discussion
>     on the color management series, so I'm just putting this here as a
>     final warning in case anyone really wants to see it changed before
>     merging.
I don't mind switching to atomic only.

>
> Thanks!
>
>
> Matt
>
>
>> Cheers,
>>
>> Lionel
>>
>> Lionel Landwerlin (5):
>>    lib: kms: add crtc_id to igt_pipe_t
>>    lib: kms: add helpers for color management properties on pipes
>>    lib: fb: add igt_paint_color_gradient_range
>>    lib: add crc comparison function without an assert
>>    tests/kms_color: New test for pipe level color management
>>
>>   lib/igt_debugfs.c      |   17 +
>>   lib/igt_debugfs.h      |    1 +
>>   lib/igt_fb.c           |   34 ++
>>   lib/igt_fb.h           |    3 +
>>   lib/igt_kms.c          |   75 ++++
>>   lib/igt_kms.h          |   18 +-
>>   tests/Makefile.sources |    1 +
>>   tests/kms_pipe_color.c | 1045 ++++++++++++++++++++++++++++++++++++++++++++++++
>>   8 files changed, 1193 insertions(+), 1 deletion(-)
>>   create mode 100644 tests/kms_pipe_color.c
>>
>> --
>> 2.7.0
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[-- Attachment #1.2: Type: text/html, Size: 5951 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-03-08 10:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-25 17:16 [PATCH i-g-t 0/5] New pipe level color management tests V5 Lionel Landwerlin
2016-02-25 17:16 ` [PATCH i-g-t 1/5] lib: kms: add crtc_id to igt_pipe_t Lionel Landwerlin
2016-02-25 17:16 ` [PATCH i-g-t 2/5] lib: kms: add helpers for color management properties on pipes Lionel Landwerlin
2016-03-08  2:13   ` Matt Roper
2016-03-08 10:29     ` Lionel Landwerlin
2016-02-25 17:16 ` [PATCH i-g-t 3/5] lib: fb: add igt_paint_color_gradient_range Lionel Landwerlin
2016-02-25 17:16 ` [PATCH i-g-t 4/5] lib: add crc comparison function without an assert Lionel Landwerlin
2016-02-25 17:16 ` [PATCH i-g-t 5/5] tests/kms_color: New test for pipe level color management Lionel Landwerlin
2016-03-08  2:46 ` [PATCH i-g-t 0/5] New pipe level color management tests V5 Matt Roper
2016-03-08 10:42   ` Lionel Landwerlin [this message]
2016-03-08 11:50     ` Lionel Landwerlin

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=56DEACAC.8080608@intel.com \
    --to=lionel.g.landwerlin@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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