[PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote:


>         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).
> Backwards compatibility with what?

With existing wayland clients that don't do sbupixel accuracy. Did you
ever try a current wayland app on a 240 dpi display?

> How would you handle subsurfaces with different scaling factors? What
> coordinates would the subsurface's position be in?

All positions are in the global compositor coordinate space. The one
that e.g. different outputs are positioned in, etc.

>         We can't have the configure event say 2000x2000, because then
>         old
>         clients will not be auto-upscaled as we want.
> In this case our proposals differs. The compositor knows it's not
> resizing the window so it simply passes 2000x2000 along to the
> configure arguments.

How can the compositor know its not resizing the window? Only the app
knows if it can render at a different scaling factor, as it is the app
that allocates and draws to the buffer.

Anyway, its pretty obvious that you're talking about a different design.
I'm growing tired of this discussion, I will just shut up and implement
my design in weston. If you want to implement a competing desing, feel
free.