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

[Pekka Paalanen]

On Mon, 13 May 2013 11:16:07 +0200
Alexander Larsson <alexl at redhat.com> wrote:

> On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> 
> > Also, we need to figure out how this interacts with the proposed
> > scaling extension.  Information can be found here:
> > http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html
> 
> I don't think it needs much extension. It works as is, although the docs
> refering to wl_surface.set_buffer_transform also needs to mention the
> scaling factor.
> 
> Of course, there is also the question of if we could use the
> wl_surface_scaler interface to do the HiDPI scaling. And, while this
> would be technically possible it seems the wrong approach to me. The
> surface scaler API is much more demanding of the compositor with
> non-integer scaling factors, cropping and aspect ratio changing. I don't
> think we want to force compositors to always support all of that in
> order to work on HiDPI displays where a much simpler subset is needed.
> Also, its a much more complex API to use for something so basic that
> every window will use it.
> 
> Basically, wl_surface_scaler is for scaling of subsurfaces with video,
> and I don't think we should mix the two up.

I agree with your reasoning here.

I haven't read this whole thread in detail, because it seems to contain
so much "marketing speak" and complicated explanations of things that
should be straightforward. So, am I getting the following right?

You basically want a default scaling factor for all surfaces, per
output. And, you want a way for clients to opt-out from that default
scaling.

Is it really that simple? I'm asking because I didn't see it put that
clearly anywhere, but maybe it got lost in between all the 3DTV
discussion and coordinate transforms.

If that is the basic problem statement, then we can start looking at
the protocol and coordinate system details. Now that I'm re-reading
your protocol patch, it's starting to make sense conceptually.


Thanks,
pq