Re: [RFC PATCH v2] Add xdg-output protocol

[Pekka Paalanen]

On Fri, 14 Jul 2017 16:40:32 +0800
Jonas Ådahl  wrote:

> This E-mail is quite long, but I tried to reply to some parts.

Hi Jonas, Olivier,

appreciated. :-)

TL;DR, I don't think there is anything in this email that would
actually be an opposition to the xdg-output protocol proposal. This
discussion has taken off in an academic direction about everything
surrounding the protocol proposal.


> On Wed, Jul 12, 2017 at 12:07:29PM +0300, Pekka Paalanen wrote:
> > On Fri, 7 Jul 2017 04:21:57 -0400 (EDT)
> > Olivier Fourdan  wrote:
> >   
> > > Hi Pekka,
> > >   
> > > > 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.
> > > 
> > > No worries, but my goal with the protocol proposal (being an Xwayland
> > > specific proposal initially, or merely an additional wl_output event
> > > or now a more generic xdg_output protocol to be extended in the
> > > future with whatever people want for desktop output uses) is to make
> > > Xwayland work with the current existing design/implementations, not
> > > to advocate for or against an existing design or particular
> > > compositor implementation.  
> > 
> > Hi Olivier,
> > 
> > if the intention is not to evaluate whether the current implementations
> > are actually workable in the long run, then should the new interface be
> > named so that we can throw it away if it actually doesn't work? And not
> > design anything else directly on top of it, so that it remains
> > relatively easy to throw away, i.e. stop using?
> >   
> > > 
> > > WRT fractional scaling, my understanding of the design in mutter is
> > > based on this document:
> > > 
> > > https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg0.html
> > > 
> > > I cannot really comment on the design decisions, nor how those
> > > decisions were made, Jonas would probably be in a better position for
> > > this.  
> > 
> > That email talks about a new feature, separated coordinate spaces:
> > logical and physical. I believe that is the correct design.
> > 
> > But I have understood that you want to make Xwayland work with the
> > design before that one, which I cannot see how it could work. Do you
> > really need to make Xwayland work well with that old design?  
> 
> The benefit of the current/old design (in mutter) is that X11 clients
> don't particularly regress in functionality, compared to how it worked
> before. HiDPI aware clients work just as well, and non-HiDPI clients
> works just as bad.

Very well, it's your choice to support two paths there.

> Naturally, if we can make both HiDPI aware and HiDPI unaware X11 clients
> work good, that's the most optimal, but I find it hard to believe we can
> make that happen without adaptations to HiDPI aware X11 clients (like
> mentioned EWMH extensions or something).

Not being a user, that is another design decision I would have hard
time understanding - why enhance modern toolkits to run better via
Xwayland instead of porting apps to Wayland. I suppose the obvious
answer is apps you don't actually control but still use GTK+ et al. But
how many of those are actually also HiDPI aware? And if you implement
that, do you not get into consistency problems with input and output
coordinate systems?

The two paragraph you wrote above talk about two cases, which in my
mind are mutually exclusive.

> > 
> > I fully agree with section 1, Overall approach.
> > 
> > Section 5 mentions a hwdb-alike database but keyed by EDID data. This is
> > something Keith Packard needs for his VR work to identify HMDs and I
> > discussed with him about it a bit. I think the scaling info would be a
> > good fit there.
> > 
> > Section 7 touches the game and fullscreen topic, which I believe is
> > important for deciding how RandR should advertise output resolutions.
> > 
> > Section 8 is exactly what we are talking about in this thread, right?  
> 
> Right. Lets split up Xwayland support into three distinguishable parts:
> 
> (A) Plain old Xwayland support with no HiDPI awareness or anything
> 
> (B) Fullscreen windows with buffer size matching the monitor framebuffer
> it is fullscreen on
> 
> (C) HiDPI aware X11 clients.
> 
> 
> For (A), this protocol solves the problem more or less completely
> without any further changes. No input transformation changes needed
> anywhere, not in Xwayland, not in any compositor. It is just a way to
> communicate the logical layout of the screen to Xwayland so that it can
> position its buffer-scale-1 windows in a grid that matches the global
> compositor coordinate space.

Right, this is starting to slowly sink in. ;-)


> > What resolution do you want RandR to advertise to X11 apps?
> > 
> > If it is the physical output resolution, the window size in logical
> > units 

Re: [RFC PATCH v2] Add xdg-output protocol

[Jonas Ådahl]

This E-mail is quite long, but I tried to reply to some parts.

On Wed, Jul 12, 2017 at 12:07:29PM +0300, Pekka Paalanen wrote:
> On Fri, 7 Jul 2017 04:21:57 -0400 (EDT)
> Olivier Fourdan  wrote:
> 
> > Hi Pekka,
> > 
> > > 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.  
> > 
> > No worries, but my goal with the protocol proposal (being an Xwayland
> > specific proposal initially, or merely an additional wl_output event
> > or now a more generic xdg_output protocol to be extended in the
> > future with whatever people want for desktop output uses) is to make
> > Xwayland work with the current existing design/implementations, not
> > to advocate for or against an existing design or particular
> > compositor implementation.
> 
> Hi Olivier,
> 
> if the intention is not to evaluate whether the current implementations
> are actually workable in the long run, then should the new interface be
> named so that we can throw it away if it actually doesn't work? And not
> design anything else directly on top of it, so that it remains
> relatively easy to throw away, i.e. stop using?
> 
> > 
> > WRT fractional scaling, my understanding of the design in mutter is
> > based on this document:
> > 
> > https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg0.html
> > 
> > I cannot really comment on the design decisions, nor how those
> > decisions were made, Jonas would probably be in a better position for
> > this.
> 
> That email talks about a new feature, separated coordinate spaces:
> logical and physical. I believe that is the correct design.
> 
> But I have understood that you want to make Xwayland work with the
> design before that one, which I cannot see how it could work. Do you
> really need to make Xwayland work well with that old design?

The benefit of the current/old design (in mutter) is that X11 clients
don't particularly regress in functionality, compared to how it worked
before. HiDPI aware clients work just as well, and non-HiDPI clients
works just as bad.

Naturally, if we can make both HiDPI aware and HiDPI unaware X11 clients
work good, that's the most optimal, but I find it hard to believe we can
make that happen without adaptations to HiDPI aware X11 clients (like
mentioned EWMH extensions or something).

> 
> I fully agree with section 1, Overall approach.
> 
> Section 5 mentions a hwdb-alike database but keyed by EDID data. This is
> something Keith Packard needs for his VR work to identify HMDs and I
> discussed with him about it a bit. I think the scaling info would be a
> good fit there.
> 
> Section 7 touches the game and fullscreen topic, which I believe is
> important for deciding how RandR should advertise output resolutions.
> 
> Section 8 is exactly what we are talking about in this thread, right?

Right. Lets split up Xwayland support into three distinguishable parts:

(A) Plain old Xwayland support with no HiDPI awareness or anything

(B) Fullscreen windows with buffer size matching the monitor framebuffer
it is fullscreen on

(C) HiDPI aware X11 clients.


For (A), this protocol solves the problem more or less completely
without any further changes. No input transformation changes needed
anywhere, not in Xwayland, not in any compositor. It is just a way to
communicate the logical layout of the screen to Xwayland so that it can
position its buffer-scale-1 windows in a grid that matches the global
compositor coordinate space.

> 
> 
> What resolution do you want RandR to advertise to X11 apps?
> 
> If it is the physical output resolution, the window size in logical
> units will be wrong unless XWM can reliably detect the X11 application
> is actually intending to use the physical resolution. How would one do
> that?

This is about part (B).

How? I'd say, probably only using "best effort" emulation strategies,
like detecting fullscreen windows matching the physical resolution set
and assuming anything else should be hidden, then using wp_viewporter or
something to make it to the logical size, which should result in no
scaling being done by the compositor.

> 
> If it is the logical output size, the window size in logical units will
> be correct, but the X11 application cannot provide a buffer of the
> physical output resolution, which means the Wayland compositor must
> scale the image. If the buffer can hit direct scanout, that should be
> no problem, but otherwise it could be a performance issue. (I agree to
> prefer this option.)

It'll be a regression quality wise though, as something somewhere will
have to scale up from the logical to the physical resolution. Long term,
this is not acceptable as it'll mean games and other applications where
graphics quality is important that also won't be ported would regress.

Re: [RFC PATCH v2] Add xdg-output protocol

[Pekka Paalanen]

On Fri, 7 Jul 2017 04:21:57 -0400 (EDT)
Olivier Fourdan  wrote:

> Hi Pekka,
> 
> > 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.  
> 
> No worries, but my goal with the protocol proposal (being an Xwayland
> specific proposal initially, or merely an additional wl_output event
> or now a more generic xdg_output protocol to be extended in the
> future with whatever people want for desktop output uses) is to make
> Xwayland work with the current existing design/implementations, not
> to advocate for or against an existing design or particular
> compositor implementation.

Hi Olivier,

if the intention is not to evaluate whether the current implementations
are actually workable in the long run, then should the new interface be
named so that we can throw it away if it actually doesn't work? And not
design anything else directly on top of it, so that it remains
relatively easy to throw away, i.e. stop using?

> 
> WRT fractional scaling, my understanding of the design in mutter is
> based on this document:
> 
> https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg0.html
> 
> I cannot really comment on the design decisions, nor how those
> decisions were made, Jonas would probably be in a better position for
> this.

That email talks about a new feature, separated coordinate spaces:
logical and physical. I believe that is the correct design.

But I have understood that you want to make Xwayland work with the
design before that one, which I cannot see how it could work. Do you
really need to make Xwayland work well with that old design?

I fully agree with section 1, Overall approach.

Section 5 mentions a hwdb-alike database but keyed by EDID data. This is
something Keith Packard needs for his VR work to identify HMDs and I
discussed with him about it a bit. I think the scaling info would be a
good fit there.

Section 7 touches the game and fullscreen topic, which I believe is
important for deciding how RandR should advertise output resolutions.

Section 8 is exactly what we are talking about in this thread, right?


What resolution do you want RandR to advertise to X11 apps?

If it is the physical output resolution, the window size in logical
units will be wrong unless XWM can reliably detect the X11 application
is actually intending to use the physical resolution. How would one do
that?

If it is the logical output size, the window size in logical units will
be correct, but the X11 application cannot provide a buffer of the
physical output resolution, which means the Wayland compositor must
scale the image. If the buffer can hit direct scanout, that should be
no problem, but otherwise it could be a performance issue. (I agree to
prefer this option.)

In any case, there is a single (default) "scaling factor" covering all
X11 clients in an Xwayland instance, because neither Xwayland nor XWM
have per-window knowledge of the scaling the X11 app used. Also, X11
apps are laid out in a global coordinate space spanning all outputs
(within a X11 SCREEN), and also input works in that global coordinate
space with trivial conversions to per-window coordinates. I assume
Xwayland converts per-wl_surface input coordinates to global input
coordinates in the X11 space before dispatching to the X11 windows,
which means that the Wayland server must send input events taking that
into account. How will input work in the proposals?

I do not like the idea of special-casing the Xwayland Wayland client in
the Wayland compositor outside of XWM, even less if it requires special
mangling for input as well. How much special casing do you do? Or maybe
I'm just biased and it would actually be fairly easy to implement in
Weston with a little bit of API... Quentin might have some opinions
here.

> Regarding this particular discussion about the need of xdg_output and
> logical size/position, I am completely open to suggestions, how would
> see Xwayland work with both weston and mutter as they are now and
> mutter in the future when it implements fractional scaling, without
> adding logical size in xdg_output (or even not adding xdg_output at
> all)?

I wouldn't say "without", I just do not understand how it all is
supposed to work in a mixed-dpi hardware setup. If we design an
interface that just cannot work in a mixed-dpi setup, we should be
able to throw it away later.

So I'm starting to think that the way forward is to design the new
interface such that it is easy to deprecate if it turns out to be a
dead end, or keep it if turns out future-proof.

Yeah, I'm going in circles here as I'm trying to find out what the
goals are.


> 
> Mixed dpi doesn't work in GNOME/x11, does it?

I guess - do you want to keep that status quo?

> GNOME implementation of HiDPI on x11 uses an 

Re: [RFC PATCH v2] Add xdg-output protocol

[Olivier Fourdan]

Hi Pekka,

> 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.

No worries, but my goal with the protocol proposal (being an Xwayland specific 
proposal initially, or merely an additional wl_output event or now a more 
generic xdg_output protocol to be extended in the future with whatever people 
want for desktop output uses) is to make Xwayland work with the current 
existing design/implementations, not to advocate for or against an existing 
design or particular compositor implementation.

WRT fractional scaling, my understanding of the design in mutter is based on 
this document:

https://mail.gnome.org/archives/gnome-shell-list/2017-June/msg0.html

I cannot really comment on the design decisions, nor how those decisions were 
made, Jonas would probably be in a better position for this.

Regarding this particular discussion about the need of xdg_output and logical 
size/position, I am completely open to suggestions, how would see Xwayland work 
with both weston and mutter as they are now and mutter in the future when it 
implements fractional scaling, without adding logical size in xdg_output (or 
even not adding xdg_output at all)?
 
> > > [...]
> > > 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.

Mixed dpi doesn't work in GNOME/x11, does it?

GNOME implementation of HiDPI on x11 uses an xsettings, which by definition is 
per screen (in x11 terminology), thus not per monitor.

  https://wiki.gnome.org/HowDoI/HiDpi

So fixing mixed DPI in Xwayland will require additional mechanisms (possibly 
new EWMH properties?), but this is not part of this proposal.

However, nothing would stop an x11 client or toolkit from querying the 
monitor's mode and physical size (using xrandx), computing the current DPI 
depending on the monitor it resides and adapting its rendering based on that. 
X11 has all the mechanisms in place for that, it's just that most clients won't 
do that (iirc, Firefox has something like that at some point, not sure it's 
still used though)

That makes a wide range of different x11 clients who behave differently:

 - Plain old x11 clients, who don't know anything about DPI
 - gtk+/GNOME clients, who base their rendering on a specific xsettings 
Gdk/WindowScalingFactor and/or a envvar read by clutter,
 - Some other app trying to compute DPI themselves (very few, I think of 
Firefox, LibreOffice maybe? not sure at all about those)

I'm don't see how Xwayland could change its behavior for each app, xrandr is 
not per client. I guess we could come up with a new window property that 
Xwayland could monitor and set the buffer scale accordingly, maybe? Anyhow, 
that's going off topic wrt the xdg_output protocol, I'm afraid.

The "benefit" I see in "lying" to the clients in xrandr by advertising a lower 
mode than actual is that it solves the problem in a consistent way for all 
these cases even those clients who try to compute the DPI themselves).

There are some additional discussions in 
https://bugs.freedesktop.org/show_bug.cgi?id=93315

> > > 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 

Re: [RFC PATCH v2] Add xdg-output protocol

[Pekka Paalanen]

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  wrote:

> > > +  
> > 
> > To mirror logical_size, should this be called logical_position?  
> 
> OK
> 
> > > +  
> > > + 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.
> > > +  
> > > +   > > +   summary="corresponding wl_output"/>
> > > +   > > +summary="x position within the global compositor
> > > space"/>
> > > +   > > +summary="y position within 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 

Re: [RFC PATCH v2] Add xdg-output protocol

[Olivier Fourdan]

Hi Pekka,

> I think I can offer only mostly mechanical comments, as I am still
> quite confused about how this will actually be used.

Well, for now, it will be used by Xwayland, might be of some interest for other 
clients who might need to know about the output "logical" size (e.g. screencast 
maybe? not even sure...).
 
> Would it be good to explain here, that on desktop the outputs are
> expected to form a single connected 2D region? Exactly like RandR
> outputs inside a single X11 SCREEN are, IOW window spanning and input
> (pointer traveling) wise. Essentially this is that "global compositor
> space" implies in practice.
> 
> And that each output is rectangular, able to show the complete
> described area?
> 
> Or are these not actually always true?

Yes, I kind of took for granted that those concepts where defined in wl_output, 
but considering this protocol is aimed at complementing wl_output for the 
desktop concept of an ouptut, it indeed makes sense to clarify further in 
xdg_output.

> > +
> > +Some of the information provided in this protocol might be identical
> > +to their counterpart already available from wl_output, in which case
> > +the information provided by this protocol should be preferred to their
> > +equivalent in wl_output. The goal is to move the desktop specific
> > +concepts (such as output location within the global compositor space,
> > +the connector name and types, etc.) out of the core wl_output
> > protocol.
> 
> Good.
> 
> > +
> > +Warning! The protocol described in this file is experimental and
> > +backward incompatible changes may be made. Backward compatible
> > +changes may be added together with the corresponding interface
> > +version bump.
> > +Backward incompatible changes are done by bumping the version
> > +number in the protocol and interface names and resetting the
> > +interface version. Once the protocol is to be declared stable,
> > +the 'z' prefix and the version number in the protocol and
> > +interface names are removed and the interface version number is
> > +reset.
> > +  
> > +
> > +  
> > +
> > +  An xdg_output describes part of the compositor geometry.
> > +
> > +  This typically corresponds to a monitor that displays part of the
> > +  compositor space.
> > +
> > +  This object is published during start up, when a monitor is hot
> > +  plugged or when the logical size of a wl_output is changed.
> 
> Do you mean that zxgd_output interface is a global interface advertised
> via wl_registry?
> 
> Can you explain why picked this design instead of the (IMO) more
> conventional design of advertising a global factory interface in
> wl_registry, and the factory interface having a request
> get_xdg_output(xdg_output new_id, wl_output base)?

Mostly because it started as an additional wl_output event I guess, but I agree 
a "conventional" design is more appropriate for a separate xdg_output protocol.

> I see some inconveniences with the design of using wl_output as an
> event argument:
> 
> A client may bind to the same wl_output global many times. This may
> happen from independent software components (libraries). The compositor
> cannot know which events should be sent with which wl_output
> wl_resource, so it must send events for all wl_resources pointing to
> the same output. Likewise, client components then must be able to cope
> with getting a wl_output proxy they did not create or set up, the first
> issue there being identifying whether the user data of the proxy is of
> the expected type.
> 
> Every single event in the interface must carry an explicit wl_output
> argument, while this could be implicit from the xdg_output proxy
> instance if it was created for a specific wl_output proxy instance to
> begin with.
> 
> 
> The more conventional design I mentioned above does impose any
> additional roundtrips, the client binding to a wl_output and also
> create a xdg_output immediately without waiting for any reply. The
> events from both wl_output and xdg_output still come to the client in
> the same burst.

Right.

> > +
> > +
> > +
> 
> To mirror logical_size, should this be called logical_position?

OK

> > +  
> > +   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.
> > +  
> > +   > +   summary="corresponding wl_output"/>
> > +   > +  summary="x position within the global compositor space"/>
> > +   > +  summary="y position within 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
> > +   

Re: [RFC PATCH v2] Add xdg-output protocol

[Pekka Paalanen]

On Tue,  4 Jul 2017 14:13:43 +0200
Olivier Fourdan  wrote:

> This protocol aims at describing outputs in way which is more in line
> with the concept of an output on desktop oriented systems.
> 
> Some information are more specific to the concept of an output for a
> desktop oriented system and may not make sense in other applications,
> such as IVI systems for example.
> 
> The goal is to gradually move the desktop specific concepts out of the
> core wl_output protocol.
> 
> For now it just features the position and logical size which describe
> the output position and size in the global compositor space.
> 
> Signed-off-by: Olivier Fourdan 
> ---
>  v2: use "destroy" instead of "release" for destructor
> 
>  Makefile.am|   1 +
>  unstable/xdg-output/README |   4 +
>  unstable/xdg-output/xdg-output-unstable-v1.xml | 135 
> +
>  3 files changed, 140 insertions(+)
>  create mode 100644 unstable/xdg-output/README
>  create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml

Hi Olivier,

I think I can offer only mostly mechanical comments, as I am still
quite confused about how this will actually be used.

> 
> diff --git a/Makefile.am b/Makefile.am
> index e693afa..6c696aa 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -12,6 +12,7 @@ unstable_protocols =
> \
>   unstable/tablet/tablet-unstable-v2.xml  
> \
>   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> \
>   unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
> \
> + unstable/xdg-output/xdg-output-unstable-v1.xml  
> \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
> new file mode 100644
> index 000..e42b711
> --- /dev/null
> +++ b/unstable/xdg-output/README
> @@ -0,0 +1,4 @@
> +xdg_output protocol
> +
> +Maintainers:
> +Olivier Fourdan 
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> new file mode 100644
> index 000..09d03eb
> --- /dev/null
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -0,0 +1,135 @@
> +
> +
> +
> +  
> +Copyright © 2017 Red Hat Inc.
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +This protocol aims at describing outputs in way which is more in line
> +with the concept of an output on desktop oriented systems.
> +
> +Some information are more specific to the concept of an output for
> +a desktop oriented system and may not make sense in other applications,
> +such as IVI systems for example.

Would it be good to explain here, that on desktop the outputs are
expected to form a single connected 2D region? Exactly like RandR
outputs inside a single X11 SCREEN are, IOW window spanning and input
(pointer traveling) wise. Essentially this is that "global compositor
space" implies in practice.

And that each output is rectangular, able to show the complete
described area?

Or are these not actually always true?

> +
> +Some of the information provided in this protocol might be identical
> +to their counterpart already available from wl_output, in which case
> +the information provided by this protocol should be preferred to their
> +equivalent in wl_output. The goal is to move the desktop specific
> +concepts (such as output location within the global compositor space,
> +the connector name and types, etc.) out of the core wl_output protocol.

Good.

> +
> +Warning! The protocol described in this file is 

[RFC PATCH v2] Add xdg-output protocol

[Olivier Fourdan]

This protocol aims at describing outputs in way which is more in line
with the concept of an output on desktop oriented systems.

Some information are more specific to the concept of an output for a
desktop oriented system and may not make sense in other applications,
such as IVI systems for example.

The goal is to gradually move the desktop specific concepts out of the
core wl_output protocol.

For now it just features the position and logical size which describe
the output position and size in the global compositor space.

Signed-off-by: Olivier Fourdan 
---
 v2: use "destroy" instead of "release" for destructor

 Makefile.am|   1 +
 unstable/xdg-output/README |   4 +
 unstable/xdg-output/xdg-output-unstable-v1.xml | 135 +
 3 files changed, 140 insertions(+)
 create mode 100644 unstable/xdg-output/README
 create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..6c696aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols =  
\
unstable/tablet/tablet-unstable-v2.xml  
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
\
+   unstable/xdg-output/xdg-output-unstable-v1.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
new file mode 100644
index 000..e42b711
--- /dev/null
+++ b/unstable/xdg-output/README
@@ -0,0 +1,4 @@
+xdg_output protocol
+
+Maintainers:
+Olivier Fourdan 
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
b/unstable/xdg-output/xdg-output-unstable-v1.xml
new file mode 100644
index 000..09d03eb
--- /dev/null
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -0,0 +1,135 @@
+
+
+
+  
+Copyright © 2017 Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+This protocol aims at describing outputs in way which is more in line
+with the concept of an output on desktop oriented systems.
+
+Some information are more specific to the concept of an output for
+a desktop oriented system and may not make sense in other applications,
+such as IVI systems for example.
+
+Some of the information provided in this protocol might be identical
+to their counterpart already available from wl_output, in which case
+the information provided by this protocol should be preferred to their
+equivalent in wl_output. The goal is to move the desktop specific
+concepts (such as output location within the global compositor space,
+the connector name and types, etc.) out of the core wl_output protocol.
+
+Warning! The protocol described in this file is experimental and
+backward incompatible changes may be made. Backward compatible
+changes may be added together with the corresponding interface
+version bump.
+Backward incompatible changes are done by bumping the version
+number in the protocol and interface names and resetting the
+interface version. Once the protocol is to be declared stable,
+the 'z' prefix and the version number in the protocol and
+interface names are removed and the interface version number is
+reset.
+  
+
+  
+
+  An xdg_output describes part of the compositor geometry.
+
+  This typically corresponds to a monitor that displays part of the
+  compositor space.
+
+  This object is published during start up, when a monitor is hot
+  plugged or when the logical size of a wl_output is changed.
+
+
+
+