[RFC PATCH v2] Add xdg-output protocol

Thu Jul 6 14:24:39 UTC 2017

Hi Olivier,

it's very hard for me to wrap my head around this, so the below may
sound a bit harsh, sorry. I don't mean to rant, but I feel there is
something fundamental amiss. I am diving back into the high-level
design which is fairly separated from the xdg_output interface.

On Thu, 6 Jul 2017 07:53:15 -0400 (EDT)
Olivier Fourdan <ofourdan at redhat.com> wrote:

> > > +    <event name="position">  
> > 
> > To mirror logical_size, should this be called logical_position?  
> 
> OK
> 
> > > +      <description summary="Position of the output within the
> > > global compositor space">
> > > +	The position event describes the location of the
> > > wl_output within the
> > > +	global compositor space.
> > > +
> > > +	The event is sent when binding to the xdg_output
> > > interface and whenever
> > > +	the location of the output changes within the global
> > > compositor
> > > +	space.
> > > +      </description>
> > > +      <arg name="output" type="object" interface="wl_output"
> > > +           summary="corresponding wl_output"/>
> > > +      <arg name="x" type="int"
> > > +	   summary="x position within the global compositor
> > > space"/>
> > > +      <arg name="y" type="int"
> > > +	   summary="y position within the global compositor
> > > space"/>
> > > +    </event>
> > > +
> > > +    <event name="logical_size">
> > > +      <description summary="Size of the output in the global
> > > compositor space">  
> > > +	The logical_size event describes the size of the output
> > > in the global
> > > +	compositor space.
> > > +
> > > +	For example, a surface with the size matching the
> > > logical_size will
> > > +	have the same size as the corresponding output when
> > > displayed. +
> > > +	Clients such as Xwayland need this to configure their
> > > surfaces in
> > > +	the global compositor space as the compositor may apply
> > > a different
> > > +	scale from what is advertised by the output scaling
> > > property (to
> > > +	achieve fractional scaling, for example).  
> > 
> > IOW, this event is a different way of sending the output scale,
> > supporting arbitrary fractional values. Except that we expect most
> > clients to ignore this and draw with the integer scale factor,
> > instead of using this information and wp_viewport to realize the
> > fractional scale factor. Is that correct?  
> 
> Yes, but not just that, this is also to cope with the different ways
> weston and mutter (< 3.26) deal with Xwayland surfaces, what you
> mentioned about Xwayland not downscaling the advertised output size
> (needed for weston, but not for mutter).

Right... let me think out loud once again.

X11 essentially uses a single global coordinate space for everything.
Traditionally it has no scaling, so window and output sizes are in the
same units. It must keep a single concept of a unit pixel to be
consistent.

But we could do the scaling two ways: a) consider everything X11 to be
scale=1, or b) consider everything X11 to be scale=N. Both are
consistent. However, using mixed-dpi setup, it would be inconsistent to
advertise all outputs with the hardware resolutions unscaled.

...

Ok, I'm not sure where I was going with that.

> > I suppose we could really use a good write-up (with examples and
> > pictures!) on how Xwayland and compositors are intended to use this
> > information, how it affects RandR parameters and how X11 clients
> > will use this, and how their windows go through Xwayland to the
> > compositor,  
> 
> Well, X11 clients could never use that directly of course.

If this affects what sizes RandR exposes and if X11 apps use RandR as
the base to size and position their windows, then this does fairly
explicitly affect how X11 apps work. But that's only one thing they
might do, they might look at SCREEN dimensions(?) and whatever... does
Xinerama protocol provide yet another way to get "the same" information?

> > to achieve compositor-bypass and hit the direct scanout path in a
> > mixed-dpi environment. I get dizzy when I try to think of that.
> > IOW, I feel I cannot really evaluate the suitability of this
> > solution for the underlying Xwayland issue.  
> 
> The Xwayland issue this is aimed at solving is current, no need to go
> as far as achieving compositor bypass or direct scan out (I am not
> sure either if the logical_size would help at all with that)

Well, when we think about what we should expose in RandR, and assuming
there are apps, e.g. fullscreen games, that use that information for
window size, and window size determines buffer size, which eventually
is related to whether one can scan it out without scaling as
intended... or deliberately with scaling when picking a "non-native"
resolution via RandR... luckily modern hardware is usually capable of
scaling at scanout, so a wrong scale is not a performance-cliff.

Yes, that is not the current issue, but I have a feeling that the
solutions to both issues are intertwined, which makes me fear of an
arbitrary decision making something else impossible. But that's me.

> Let's take an example, a hidpi monitor 3840×2160 at scale 2.
> 
> Right now, advertised as its mode resolution in Xwayland (which
> doesn't take into account the wl_output scale), so Xrandr reports:
> 
>   XWAYLAND1 connected 3840x2160+0+0
>      3840x2160     60*+
> 
> In weston, an X client trying to configure its window the size based
> on what Xrandr reports for the monitor ends up with a window of size
> 7860×4320 because weston will scale the Xwayland surface buffer by 2,
> whereas in mutter, the resulting window is 3840×2160 because mutter
> (up to 3.26) doesn't scale Xwayland surfaces. But that will
> eventually be configurable in mutter, so there is no "one fits all"
> solution other than the compositor itself telling the "logical"
> output size.

Ok, I get that. It the difference in the chosen global scale factor
between X11 coordinate system and the compositor logical coordinate
system.

> In such a case, weston would set the "logical_size" as 1920×1080
> whereas mutter current or future version without
> "scale-monitor-framebuffer" set would set a logical size of 3840×2160.

Don't forget that it will also affect input coordinates. Setting the
logical_size effectively chooses a single scale factor for all X11, and
even in a mixed-dpi setting, outputs must not disagree on what the
scale factor is, otherwise I would expect e.g. input to become nearly
impossible to get right.

> With mutter implementing fractional scaling and using a scale of 1.5
> (for example), it would set a wl_output.scale of 2 and set a logical
> size of 2560×1620.

RandR would advertise 2560×1620, X11 apps will create windows and
buffers of that size, and then mutter will... scale them how?

If it assumes the Xwayland windows are already in scale=2, the
wl_surface size becomes 1280×810, and that scaled up to the output
factor 1.5 gets us to 1920×1215.

If it assumes Xwayland windows are not to be scaled at all, the surface
size becomes 2560×1620, which on the 1.5 output will be 3840×1620. That
means that the compositor is up-scaling for the output, not
down-scaling as I understood was intended.

If it assumes Xwayland windows are literally not to be scaled at all,
the size on the 1.5 output will be 2560×1620, which calculating
backwards would mean surface size 1706.7×1080.

I am so confused, because it feels like you are inventing scaling
factors here and there to get the numbers you want, without any design
on what the coordinate systems actually are. OTOH, I always think in
coordinate systems and how to map from one to another, how you move on
the 2D plane and how that motion translates to the other one,
especially when crossing from a low-dpi output to a high-dpi output. I
would love to see the coordinate systems drawn out, and the mappings
between them written down, parametrized with what we intend to have in
protocol and in compositor scaling modes.

I also cherish the idea of a chain of coordinate transformations. Start
with coordinate system 1, apply transformation A, end up in coordinate
system 2, apply transformation B, end up in coordinate system 3. All
transformations are invertible. If there is more than one chain of
transformations between two coordinate systems, the total
transformations must be identical. The less exceptions on when each
coordinate system applies, the better. This might be obvious, but it
must also hold when traveling in a coordinate system and crossing
window and output boundaries, and that is where I think we will hit
problems. The transformations do not apply only to points, they must
also apply to vectors (motion).

I still think that handling Xwayland as a special client that does not
obey the normal Wayland protocol semantics like how the size of a
wl_surface is determined from buffer size, buffer_scale and
buffer_transform, maybe via wp_viewport, is not a good design. I'm not
sure if Mutter does that or not.

> I'll add that example in the description for logical_size.

I think this would need a separate design document with pictures,
cramming it into the protocol doc doesn't seem feasible to me. Ideally
we'd have it in the Wayland docbook. I see no problem having
desktop-specific chapters there.

> > > +
> > > +	The logical size being in global compositor space
> > > implies that the
> > > +	client does not need to apply any wl_output.scale or
> > > wl_output.rotation
> > > +	to the given logical_size to figure the size of a
> > > surface when
> > > +	displayed on the output.  
> > 
> > The only way you can actually directly set the size of a surface is
> > via wp_viewport, and in all other cases the surface size is
> > computed from the buffer size via the client-set buffer_scale and
> > buffer_transform.  
> 
> Yes, but that's for "regular" Wayland clients, Xwayland surface
> aren't scaled in mutter even though Xwayland doesn't use
> wl_surface.set_buffer_scale (mutter doesn't support
> set_buffer_transform, either)

Right, I think that's a mistake. Or at least it makes me not understand
at all how Mutter can work in a mixed-dpi setup.

> > I think you wanted to talk about the output size here, somehow, that
> > you are given it directly and not need to take into account
> > output_scale and output_transform. If one then arranges a
> > wl_surface to have that size, it will be the same size as the
> > output area. So it's about finding out what size a client wants to
> > have, not how the size of a wl_surface is determined. Can you see
> > what I mean?  
> 
> I think I kinda see what you mean, I would remove that sentence
> altogether (it's convoluted and confusing) and rephrase the
> introductory sentence as:
> 
>  "For example, a surface without any buffer scale, transformation
>   nor rotation set, with the size matching the logical_size will
>   have the same size as the corresponding output when displayed."

I think it could be simplified even further. A wl_surface whose size
equals the logical_size of an output, will be shown at the size of the
output.

There is no reason to rule out buffer_scale, buffer_transform, or
wp_viewport, because all they do is affect what size the wl_surface
will be based on the buffer size. A client can set all those any way it
wants if the resulting wl_surface size equals the output logical_size.

> > > +    <event name="done">
> > > +      <description summary="Sent all information about output">
> > > +	This event is sent after all other properties have
> > > been	sent, after
> > > +	binding to an xdg_output interface and after any other
> > > property changes
> > > +	done after that.
> > > +
> > > +	This allows changes to the xdg_output properties to be
> > > seen as atomic,
> > > +	even if they happen via multiple events.  
> > 
> > A good idea.  
> 
> Not mine of course, this is from wl_output :)

Yes, it is good to not make the same mistake twice. ;-)

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170706/4b81d3ff/attachment.sig>