[igt-dev] [PATCH i-g-t 1/2] tests/kms_plane: Print count of mismatched colors

[Dhinakaran Pandiyan]

On Fri, 2019-03-15 at 13:56 +0200, Martin Peres wrote:
> On 15/03/2019 00:35, Dhinakaran Pandiyan wrote:
> > On Thu, 2019-03-14 at 13:03 +0200, Arkadiusz Hiler wrote:
> > > Currently we are printing one igt_warn for each CRC mismatch,
> > > which
> > > gets
> > > quite overwhelming with having to see the same error 8 times for
> > > each
> > > color tested:
> > > 
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > WARNING: CRC mismatch with format NV12 (0x3231564e) on A.3
> > > 
> > > Since the most interesting information here is which format on
> > > which
> > > pipe/plane is broken we can skip igt_warn just once.
> > > 
> > > For those weirder and rarer case where just certain colors would
> > > fail
> > > we
> > > still provide the count:
> > 
> > IMO it's better to have all the information in the logs,
> > particularly
> > for those 'weirder and rare cases, which are hard to reproduce. And
> > don't see how count is useful. I think, we should be even logging
> > the
> > RGB values for the mismatching cases.
> 
> I definitely stand behind your reasoning here, however I have a
> strong
> requirement that I need to be able to file filters for this, and
> multiple lines are just too hard to file filters when you also need
> to
> check that other formats are also failing and no new one comes in
> without me to get new values.
It would have been nice to include this justification in the commit
message.

> 
> Would you have an idea on how to get the colors failing in one line?
> I
> was initially proposing to just have a bitfield representing the
> colors
> failing in one value, but Arek found it hard to understand.
> 
> What do you think?
A bit mask, like what Petri has done, is still useful to quickly
identify failing patterns; we can always go back and check the color
during debug.