[PATCH] protocol: Modes are specified in HW pixels

[Bill Spitzak]

On 05/28/2013 07:20 AM, alexl at redhat.com wrote:

> The only complexity is the FILL mode where it can happen that the user
> specifies a buffer of the same size as the screen, but the output has scale
> 2 and the buffer scale 1. Just scanning out this buffer will work, but
> effectively this is a downscaling operation, as the "real" size of the surface
> in pels is twice the size of the output. We solve this by allowing FILL to
> downscale (but still not upscale).

The client can certainly make a surface larger than the output in lots 
of ways, not just by using the buffer scale, and not just in FILL mode. 
They could specify a 1000x1000 surface with a scale of 1 on an output of 
scale 1.

I think the result for *all* modes should be compositor/driver defined. 
It could scale down exactly, it could scale down by the next larger 
integer and do "fill", or only clip an output-sized rectangle from 
inside the surface, or some combination of scaling and clipping. The 
reason it can be left up to the compositor is that this should be 
considered a client error.

I think the only rule is that the behavior for larger-than-necessary 
surfaces should be the same for all fullscreen modes.

This kind of means buffer scale is relevant for all the modes, too, 
since it determines whether the surface fits. Though you are right that 
once it fits, only the FILL mode will change it's result depending on 
the buffer scale.