[PATCH 0/2] Support for high DPI outputs via scaling
Alexander Larsson
alexl at redhat.com
Tue May 14 06:19:49 PDT 2013
On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote:
> On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson
> <alexl at redhat.com>
>
> I don't think it should really be allowed to not apply the
> scaling.
> Users may want to disable scaling as it's not very good looking. I
> don't think we should enforce a policy about that.
What do you mean? Scaling is done by the compositor. The user is who
tells the compositor to use scaling (by setting a scale on the
wl_outputs), just like he sets the resolution.
> Right now buffer sizes define surface sizes, and that makes
> surface
> sizes not really well defined.
> They're defined as the same as buffer sizes (ignoring the trivial
> transformations). They should still be the same if the scaling factor
> is not 1.0. Clients should scale both buffers and surfaces. The only
> thing that should decouple these sizes more are the scaling extension.
Obviously they are defined as such right now, since there is no scaling.
But, the patch I proposed changes this, because otherwise we can't
cleanly handle backwards compatibility (and also it makes sense).
In the canonical example of 2x scaling you have some lcd panel at say
2000x2000, and we want naive apps to be automatically upscaled as if it
was a 1000x1000 monitor. If a window in the naive app is maximized this
means it must get a configure reply from maximize that says 1000x1000,
which cause it to attach a buffer of 1000x1000 (with scale factor 1) to
it. This is how existing wayland clients work.
Now, a non-naive client will get the same maximize reply of 1000x1000,
but in this case we want it to create a buffer of 2000x2000 (with scale
2) since it knows the window is on a high-dpi monitor. So, there is a
natural separation of the surface size (1000x1000) and the buffer size
(2000x2000).
We can't have the configure event say 2000x2000, because then old
clients will not be auto-upscaled as we want.
More information about the wayland-devel
mailing list