[RFC v2] surface crop & scale protocol extension

[Bill Spitzak]

Pekka Paalanen wrote:

> Yes, you cannot use non-integer surface sizes. You cannot express a
> surface size, that would result in a 1024x1024 area in output pixels,
> because 1024 is not divisible by output_scale=3.

Thanks. That is indeed exactly the problem I am concerned about.

> This limitation exists also before crop & scale. Crop & scale cannot
> remove this limitation, because the whole Wayland protocol has been
> built on surface coordinates and especially surface sizes are integers.

I thought the proposed crop+scale used fixed point to specify the 
destination rectangle, which is a solution. I don't like it but I 
thought it was done on purpose for this.

The buffer size sent with attach is also in buffer pixels. So a client 
can make a surface any size. But because the offset is in "surface 
coordinates" they cannot resize the origin corner except in multiples of 
buffer_scale. However they *can* resize the opposite corner in pixels. 
This seems pretty inconsistent and it would be nice to fix it too.