[igt-dev] [PATCH v3 03/11] fb: Add format conversion routine

[Maxime Ripard]

On Mon, Jun 04, 2018 at 01:13:53PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 04, 2018 at 11:54:03AM +0200, Maxime Ripard wrote:
> > On Thu, May 24, 2018 at 06:40:36PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 24, 2018 at 05:19:04PM +0200, Maxime Ripard wrote:
> > > > On Thu, May 24, 2018 at 05:58:13PM +0300, Ville Syrjälä wrote:
> > > > > On Thu, May 24, 2018 at 04:24:42PM +0200, Maxime Ripard wrote:
> > > > > > The chamelium format subtests will need to convert the reference pattern to
> > > > > > the format to be tested on the DRM device.
> > > > > > 
> > > > > > However, Cairo is very limited when it comes to format, and while pixman
> > > > > > has much more support for formats, it's still falling short compared to
> > > > > > what DRM exposes, especially on the YUV side.
> > > > > 
> > > > > We already have the capability to do format conversions automagically.
> > > > > I'm extending it to handle more YUV stuff here:
> > > > > https://patchwork.freedesktop.org/series/43651/
> > > > > 
> > > > > Can you hook up the pixman stuff in the same way so that we don't
> > > > > have to any explicit conversion stuff in the tests themselves?
> > > > 
> > > > I really think that the assumption that cairo will handle it is not a
> > > > proper fit. Cairo support is very limited, just like pixman is to a
> > > > lesser extent, and we should just break the assumption that we will
> > > > get a cairo surface all the time.
> > > 
> > > Not sure what you're saying here. We don't assume cairo handles all
> > > the formats, well, because it doesn't. We just magically convert
> > > to/from XRGB888 so that cairo doesn't have to handle anything else.
> > 
> > My point was that from what I can tell from your patches, you allow to
> > create an igt_fb with whatever format we want, and then convert it to
> > XRGB8888 when one calls igt_get_cairo_surface.
> > 
> > I need something more generic, but even if we simplify to the
> > operation that I need now, I basically needs the exact opposite: to be
> > able to take an XRGB8888 buffer (that is our pattern) and get an
> > igt_fb in an arbitrary format.
> 
> The current thing (and my patches) converts both ways. Can't get much
> more generic than that.
> 
> > 
> > And that buffer cannot be created by cairo,
> 
> Why not?

In order to have control over the lower bits that would be lost in the
resampling. Let's say you convert the initial XRGB8888 pattern to an
RGB565 one, feed that to the scanout, and capture the frame on the
other end using a chamelium.

The Chamelium will capture a CRC over an XRGB8888 frame internall, and
you will have the CRC of the XRGB8888 pattern. However, since that
pattern was downsampled to RGB565 and the resampled back to 8 bits,
you lost the least significant bits, and without a pattern that was
carefully chosen, the CRCs don't match anymore.

As far as I know, Cairo only allows you to specify a color component
as a float, and tries to map that to a 24bits color components. But
you have no way to force it to use a particular value for the 3 (or
more) lower bits.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/igt-dev/attachments/20180614/efe613fd/attachment.sig>