[PATCH 2/2] protocol: Support scaled outputs and surfaces

[Alexander Larsson]

On tor, 2013-05-16 at 10:57 -0700, Bill Spitzak wrote:
> alexl at redhat.com wrote:
> 
> > Coordinates
> > in other parts of the protocol, like input events, relative window
> > positioning and output positioning are still in the compositor space
> > rather than the scaled space. However, input has subpixel precision
> > so you can still get input at full resolution.
> 
> If I understand this correctly, this means that a client that is aware 
> of the high-dpi is still unable to make a surface with a size that is 
> not a multiple of the scale, or to move the x/y by an amount that is not 
> a multiple of the scale, or position subsurfaces at this level of accuracy.

You can make a surface of any integer size (and it has to be integer due
to existing APIs on surface coordinates/sizes), however the *buffer* has
to be an integer multiple of the surface size. In other words, surface
sizes and positions are described in the global compositor space, with
integer sizes. (This is already true, although currently the
buffer<->surface mapping is just reflections and rotations.)

Its true that this limits subsurface positioning, but i'm not sure that
is a huge issue. If nothing else it makes it so that subsurfaces are
always positioned on integer positions on non-scaled displays, which
makes things easier when monitor of differen scales are mixed.

> The only way I can see to make it work is that all protocol must be in 
> buffer space (or perhaps in buffer space after the rotation/reflection 
> defined by buffer_transform). This also has the advantage (imho) of 
> getting rid of one of the coordinate spaces a client has to think about.

I see it the other way. We currently have *two* coordinate spaces that
the client has to think about. The buffer coordinates (it has to know
this when rendering), and the surface coordinates (these are basically
what all wayland APIs atm use, like in damage, positioning and input).
The transform between two is currently the buffer_transform only. With
the buffer_scale the transform is extended to also scale, but no
additional coordinate space is added.

However, if we make the protocol work in post-translation but pre-scale
space we're adding a new coordinate space. And, we can't make the
protocol work in fully buffer coordinates, because that would break
existing clients since current APIs work in post-translation
coordinates.