[Pixman] [PATCH v3] test: Add cover-test

[Ben Avison]

On Fri, 04 Sep 2015 11:18:03 +0100, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> I think we may have a problem with sizes/coordinates.
>
> With 64 kB page size, the minimum fenced image width for r5g6b5 image
> is 32768 pixels. GDB tells me src_img->bits.width << 16 is negative.
>
> Similarly the minimum width of an a8 image becomes 64k pixels. These
> coordinates do not fit in pixman_fixed_t.

This is a good point.

However, I have thought of a workaround. Only the image width is
constrained to be < 65536 (or < 32768 if we want to avoid signed issues,
since pixman_fixed_t is defined to be a signed quantity). The *stride*
isn't.

In other words, if we accept that any one fenced image can only be
guaranteed to detect accesses off the right of an image, or the left of
an image, but not both, then we can construct a page layout of
* 1 protected page
* enough unprotected pages to hold at least the specified minimum number
   of pixels
* 1 protected page
* more unprotected pages
* 1 protected page

and so on.

In the case where the page size is much larger than a row, this amounts to
alternating protected and unprotected pages. Then we set the stride to
the distance between protected pages, and set image->bits.bits such that
either the left or right edge of each row lines up with the page boundary.

For example, if we wanted a fenced 8bpp image of width 16384 pixels on a
system where the page size is 64K, then a left-fenced image would be laid
out like this:

  pixels:             **              **
  stride:             <-------------->
  protected?  YYYYYYYYnnnnnnnnYYYYYYYYnnnnnnnnYYYYYYYY
              ^       ^       ^       ^       ^
              0       64K     128K    192K    256K

and a right-fenced one would look like:

  pixels:                   **              **
  stride:                   <-------------->
  protected?  YYYYYYYYnnnnnnnnYYYYYYYYnnnnnnnnYYYYYYYY
              ^       ^       ^       ^       ^
              0       64K     128K    192K    256K

Obviously that would require work to the fence image code as well as to
cover-test, so I thought I'd ask for opinions - is it worth the added
complexity, or should we just bail out if the page size is > 32K as Pekka
suggests?

Ben