Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Am Dienstag, den 16.05.2017, 12:28 +0300 schrieb Pekka Paalanen:
> On Mon, 15 May 2017 17:31:57 +0200
> Philipp Kerling  wrote:
> 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> > > On Sun, 14 May 2017 14:43:44 +0200
> > > Philipp Kerling  wrote:  
> > > > To start off:
> > > >  * Kodi should offer the user the opportunity to select inside
> > > > the
> > > >application on which monitor he/she wants to have Kodi
> > > > displayed
> > > > on
> > > >when in full-screen mode. Now I see that I can do this with
> > > > either
> > > >wl_shell_surface::set_fullscreen and
> > > > zxdg_toplevel::set_fullscreen,
> > > >which expect a wl_output to display the window on. But I am
> > > > not
> > > > sure
> > > >how I should match the wl_output instance I get from Wayland
> > > > with
> > > >the monitor that the user selected. As far as I can see, I
> > > > can
> > > > only
> > > >identify the monitor by way of "make" and "model". This
> > > > seems
> > > >reasonable enough at first glance, but I think that in
> > > > multi-
> > > > monitor 
> > > >configurations it is not so uncommon to buy the same monitor
> > > > model
> > > >multiple times - I personally have done this. Naturally, the
> > > > "make"
> > > >and "model" of both monitors are identical, so I cannot
> > > > discern
> > > >which is which by looking at the wl_output metadata. Am I
> > > > missing
> > > >something here?  
> > > 
> > > That is all true, you are not missing anything.
> > > 
> > > It is a missing piece of protocol - I believe no-one has had both
> > > the
> > > need and the time to work on getting anything better yet.
> > >   
> > > > Why isn't e.g. the connector the output is connected
> > > >to exported?  
> > > 
> > > Because connector names are specific to DRM while Wayland (core
> > > protocol at least) is not.  
> > 
> > I'm not sure I agree. See further below.
> > 
> > > Also, would you not want to identify the
> > > monitor rather than which connector it happens to be plugged
> > > in?   
> > 
> > I think that it's not quite decided yet what we want the user
> > experience to be on the Kodi side, i.e. do we want to bind output
> > to
> > the physical monitor (however it is identified) or the GPU
> > connector?
> > You can probably find use cases for both, so it's not an easy
> > decision
> > to make. With X11 it was limited to the latter, so my first
> > approach
> > was to mimic that. Ideally, both would be possible with Wayland and
> > the
> > application can decide what is best for its specific use case. I
> > realize that this might be too much to ask for all at once, so I'll
> > talk to my mentor to decide which case we want to focus on for
> > Kodi.
> > There are also two different points involved in this discussion:
> >I. How the *user* identifies which output/monitor the fullscreen
> >   display should be on (e.g. with make+model+connector name, or
> > by
> >   compositor-specific numbering).
> >   II. How *Kodi* or any other application then stores this, re-
> > identifies
> >   this output/monitor and maps it to a wl_output on application
> > start
> >   and hotplug. Possiblities include saving information
> > pertaining to
> >   the output, the connector, the physical device, or any
> > combination.
> 
> Hi,
> 
> very much agreed.
> 
> > > Would
> > > a user even know which connector name matches to which monitor?  
> > 
> > Yes, I also thought about this. Tech-savvy users might actually be
> > able
> > to identify the connector name, but you are absolutely right that
> > usually users should not be expected to. In fact, having make and
> > model
> > available actually is an improvement in that regard (on X11, Kodi
> > *only* displays connector since that is what's available via
> > RANDR).
> > So: How do you suggest to identify a particular monitor then? As I
> > said, make and model are not sufficient - but serial number will
> > not
> > help the user in identification. If there are multiple monitors of
> > the
> > same model, I do not think that they (i.e. the physical devices)
> > can be
> > reasonably discerned in a way that is transparent to the user.
> > That's
> > why I suggested the connector name.
> 
> One idea coming to mind is that in the DE's (compositor's) display
> configuration dialog, the user would be allowed to identify monitors
> by
> visual clues, and would be given the opportunity to give the monitors
> (or connectors!) custom names. An application could then show all the
> information plus the custom names so that the user can pick the one
> he
> wants.
What do you think makes more sense here - having the compositor provide
this information such as the custom names to the application which can
then display a selection box to the user (with the option to ask the
compositor to briefly display said information on all screens as
overlay), or having the compositor provide the 

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Pekka Paalanen]

On Mon, 15 May 2017 17:31:57 +0200
Philipp Kerling  wrote:

> Thanks for your answers! See reply below.
> 
> 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> > On Sun, 14 May 2017 14:43:44 +0200
> > Philipp Kerling  wrote:  
> > > To start off:
> > >  * Kodi should offer the user the opportunity to select inside the
> > >    application on which monitor he/she wants to have Kodi displayed
> > > on
> > >    when in full-screen mode. Now I see that I can do this with
> > > either
> > >    wl_shell_surface::set_fullscreen and
> > > zxdg_toplevel::set_fullscreen,
> > >    which expect a wl_output to display the window on. But I am not
> > > sure
> > >    how I should match the wl_output instance I get from Wayland
> > > with
> > >    the monitor that the user selected. As far as I can see, I can
> > > only
> > >    identify the monitor by way of "make" and "model". This seems
> > >    reasonable enough at first glance, but I think that in multi-
> > > monitor 
> > >    configurations it is not so uncommon to buy the same monitor
> > > model
> > >    multiple times - I personally have done this. Naturally, the
> > > "make"
> > >    and "model" of both monitors are identical, so I cannot discern
> > >    which is which by looking at the wl_output metadata. Am I
> > > missing
> > >    something here?  
> > 
> > That is all true, you are not missing anything.
> > 
> > It is a missing piece of protocol - I believe no-one has had both the
> > need and the time to work on getting anything better yet.
> >   
> > > Why isn't e.g. the connector the output is connected
> > >    to exported?  
> > 
> > Because connector names are specific to DRM while Wayland (core
> > protocol at least) is not.  
> I'm not sure I agree. See further below.
> 
> > Also, would you not want to identify the
> > monitor rather than which connector it happens to be plugged in?   
> I think that it's not quite decided yet what we want the user
> experience to be on the Kodi side, i.e. do we want to bind output to
> the physical monitor (however it is identified) or the GPU connector?
> You can probably find use cases for both, so it's not an easy decision
> to make. With X11 it was limited to the latter, so my first approach
> was to mimic that. Ideally, both would be possible with Wayland and the
> application can decide what is best for its specific use case. I
> realize that this might be too much to ask for all at once, so I'll
> talk to my mentor to decide which case we want to focus on for Kodi.
> There are also two different points involved in this discussion:
>I. How the *user* identifies which output/monitor the fullscreen
>   display should be on (e.g. with make+model+connector name, or by
>   compositor-specific numbering).
>   II. How *Kodi* or any other application then stores this, re-identifies
>   this output/monitor and maps it to a wl_output on application start
>   and hotplug. Possiblities include saving information pertaining to
>   the output, the connector, the physical device, or any combination.

Hi,

very much agreed.

> > Would
> > a user even know which connector name matches to which monitor?  
> Yes, I also thought about this. Tech-savvy users might actually be able
> to identify the connector name, but you are absolutely right that
> usually users should not be expected to. In fact, having make and model
> available actually is an improvement in that regard (on X11, Kodi
> *only* displays connector since that is what's available via RANDR).
> So: How do you suggest to identify a particular monitor then? As I
> said, make and model are not sufficient - but serial number will not
> help the user in identification. If there are multiple monitors of the
> same model, I do not think that they (i.e. the physical devices) can be
> reasonably discerned in a way that is transparent to the user. That's
> why I suggested the connector name.

One idea coming to mind is that in the DE's (compositor's) display
configuration dialog, the user would be allowed to identify monitors by
visual clues, and would be given the opportunity to give the monitors
(or connectors!) custom names. An application could then show all the
information plus the custom names so that the user can pick the one he
wants.

> > To expose such a name in the protocol, we should define the space or
> > meaning of the names. Human-readable? That's not the connector name,
> > IMHO. Machine-parseable? Needs a very strict definition to work.
> > Both?  
> RANDR output names (which are somewhat close to what I refer to as
> connector names - it's a matter of debate whether output or connector
> name would be more fitting for the Kodi use case) are specifically
> meant to be "presented to the user", but I can see your point. I think
> that machine-parseable is doable, also considering that RANDR did have
> a "ConnectorType" property which is probably part of what we'd want
> here. 

I think 

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Hi,

Am Dienstag, den 16.05.2017, 11:30 +0300 schrieb Pekka Paalanen:
> On Mon, 15 May 2017 17:51:16 +0200
> Philipp Kerling  wrote:
> 
> > 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> > > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:  
> > > > On Sun, 14 May 2017 14:43:44 +0200
> > > > Philipp Kerling  wrote:  
> > > > >  * Am I correct in that if I use zxdg_toplevel (i.e. give
> > > > > this
> > > > > role to
> > > > >a surface), I cannot also use wl_shell_surface? If so,
> > > > > this
> > > > > would be  
> > > > 
> > > > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > > > mutually
> > > > exclusive, you cannot use both for the same wl_surface.
> > > > wl_shell is
> > > > the
> > > > deprecated one, and xdg_shell suite is the replacement waiting
> > > > to
> > > > be
> > > > decleared stable.
> > > >   
> > > > >quite a problem. I can see that zxdg_toplevel
> > > > > functionality is
> > > > >mostly superior to that of wl_shell_surface, but it has
> > > > > one
> > > > > omission
> > > > >that is crucial for Kodi: the ability to request a
> > > > > specific
> > > > > refresh
> > > > >rate for fullscreen display. This is needed for closely
> > > > > matching the
> > > > >display and video FPS so duplicated and skipped frames are
> > > > > kept to a
> > > > >minimum. Is this an intentional omission and/or is there
> > > > > anything
> > > > >that provides this functionality?  
> > > > 
> > > > Hopefully the xdg_shell designers would answer that, but I
> > > > believe
> > > > it
> > > > has been omitted for now to make it easier to declare the first
> > > > fundamental parts of xdg_shell stable. It is missing a lot, but
> > > > the
> > > > foundation must agreed upon first before building more on
> > > > top.  
> > > 
> > > Rather than combining the FPS request with fullscreening,
> > > wouldn't it
> > > be
> > > better to let applications set FPS as a property of the surface?
> > > 
> > > That way the client would make a promise that is is going to
> > > update
> > > surface contents with periodic commits of the specified rate,
> > > completely
> > > independent of the actual output hardware or fullscreen state.
> > > 
> > > The server could use that information to choose the best display
> > > refresh
> > > rate even if not in fullscreen mode.  
> > 
> > I would not want my compositor to do that, since changing the
> > refresh
> > rate means that the monitor will go blank for a while while
> > resyncing
> > on most hardware.
> 
> Hi,
> 
> I get the feeling that you are assuming the server would always obey
> the
> client refresh rate. The protocol should not be designed like that.
I actually don't and I think I explicitly stated that in an earlier
email. I know that Wayland has nothing like RANDR (i.e. where every
application can mess around with the output modes as it pleases) on
purpose. Sorry if I gave the impression that this or something similar
is what I'd want.

> Wayland protocol design principle for the desktops is that clients
> describe what they would want to do (and why), and the server
> implements the policy on when and how that actually happens - if at
> all. This is very much the opposite from X11. A typical example is
> input grabs: a client has to provide both the reason (the input event
> they are acting on) and the context (the surface a grab will be tied
> to). The server decides if it grants a grab or not, and if yes, it
> can
> also revoke the grab at any time.
> 
> The reason the framerate was in the fullscreen request in wl_shell is
> that fullscreen offers fairly clear conditions on when the server
> should or could switch the video mode:
> - when the fullscreen window becomes top-most and active, switch
> video
>   mode to the client requested one
> - when the fullscreen window becomes inactive, is hidden, or some
> other
>   top-level window comes on top of it; a condition that is not just
>   transient; switch video mode back to the default one
> - do not switch back to default one for insignificant actions, e.g. a
>   notification window appearing, window switcher starter but not yet
>   chosen the next active window
> 
> If a custom video mode request can be made on any kind of window, it
> becomes more hard to figure out the right situations when to switch -
> if switching at all. The server always has to have the choice to not
> switch at all, ever, e.g. if the hardware is incapable, would make
> the
> screen blank for too long that it's annoying, or simply a policy set
> by
> the user.
That's perfectly OK. I don't think it necessarily becomes more
difficult by attaching the information to all surfaces as opposed to
only full-screen surfaces though. As you said, the compositor should
not be obligated to do anything at all and the arguably most common use
case which is the old set_fullscreen behaviour that only considers
fullscreen surfaces is still possible 

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Zabel]

On Mon, 2017-05-15 at 17:51 +0200, Philipp Kerling wrote:
> 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:
> > > On Sun, 14 May 2017 14:43:44 +0200
> > > Philipp Kerling  wrote:
> > > >  * Am I correct in that if I use zxdg_toplevel (i.e. give this
> > > > role to
> > > >a surface), I cannot also use wl_shell_surface? If so, this
> > > > would be
> > > 
> > > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > > mutually
> > > exclusive, you cannot use both for the same wl_surface. wl_shell is
> > > the
> > > deprecated one, and xdg_shell suite is the replacement waiting to
> > > be
> > > decleared stable.
> > > 
> > > >quite a problem. I can see that zxdg_toplevel functionality is
> > > >mostly superior to that of wl_shell_surface, but it has one
> > > > omission
> > > >that is crucial for Kodi: the ability to request a specific
> > > > refresh
> > > >rate for fullscreen display. This is needed for closely
> > > > matching the
> > > >display and video FPS so duplicated and skipped frames are
> > > > kept to a
> > > >minimum. Is this an intentional omission and/or is there
> > > > anything
> > > >that provides this functionality?
> > > 
> > > Hopefully the xdg_shell designers would answer that, but I believe
> > > it
> > > has been omitted for now to make it easier to declare the first
> > > fundamental parts of xdg_shell stable. It is missing a lot, but the
> > > foundation must agreed upon first before building more on top.
> > 
> > Rather than combining the FPS request with fullscreening, wouldn't it
> > be
> > better to let applications set FPS as a property of the surface?
> > 
> > That way the client would make a promise that is is going to update
> > surface contents with periodic commits of the specified rate,
> > completely
> > independent of the actual output hardware or fullscreen state.
> > 
> > The server could use that information to choose the best display
> > refresh
> > rate even if not in fullscreen mode.
> I would not want my compositor to do that, since changing the refresh
> rate means that the monitor will go blank for a while while resyncing
> on most hardware. Doing this on a regular basis would be very
> disturbing.

I agree, non-fullscreen vrefresh rate changes would only be useful for
outputs that are known to change modes quickly without blanking.
For generic desktop compositors this probably should be limited to
fullscreen surfaces. However, there may be other things that could be
done with this information, like using it for compositing decisions, if
it is known in advance that the application will not change buffer until
the next screen update. Or for changing encoder parameters for outputs
that end up being encoded and streamed.

regards
Philipp

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:
> > On Sun, 14 May 2017 14:43:44 +0200
> > Philipp Kerling  wrote:
> > >  * Am I correct in that if I use zxdg_toplevel (i.e. give this
> > > role to
> > >    a surface), I cannot also use wl_shell_surface? If so, this
> > > would be
> > 
> > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > mutually
> > exclusive, you cannot use both for the same wl_surface. wl_shell is
> > the
> > deprecated one, and xdg_shell suite is the replacement waiting to
> > be
> > decleared stable.
> > 
> > >    quite a problem. I can see that zxdg_toplevel functionality is
> > >    mostly superior to that of wl_shell_surface, but it has one
> > > omission
> > >    that is crucial for Kodi: the ability to request a specific
> > > refresh
> > >    rate for fullscreen display. This is needed for closely
> > > matching the
> > >    display and video FPS so duplicated and skipped frames are
> > > kept to a
> > >    minimum. Is this an intentional omission and/or is there
> > > anything
> > >    that provides this functionality?
> > 
> > Hopefully the xdg_shell designers would answer that, but I believe
> > it
> > has been omitted for now to make it easier to declare the first
> > fundamental parts of xdg_shell stable. It is missing a lot, but the
> > foundation must agreed upon first before building more on top.
> 
> Rather than combining the FPS request with fullscreening, wouldn't it
> be
> better to let applications set FPS as a property of the surface?
> 
> That way the client would make a promise that is is going to update
> surface contents with periodic commits of the specified rate,
> completely
> independent of the actual output hardware or fullscreen state.
> 
> The server could use that information to choose the best display
> refresh
> rate even if not in fullscreen mode.
I would not want my compositor to do that, since changing the refresh
rate means that the monitor will go blank for a while while resyncing
on most hardware. Doing this on a regular basis would be very
disturbing. Kodi can get away with it since
 * it only does it when starting to play a video,
 * it only does it in full-screen mode when nothing else is on the
   screen anyway, and
 * it has the option to wait a configurable amount of time before
   starting playback to ensure that the mode switch is complete.
But I can see how this is the more general solution and also supports
the video playback use case. If this operation would include a
recommendation that the compositor should try to closely match the
requested framerate of currently displayed full-screen surfaces to the
vertical refresh rate of the corresponding output, I guess it would be
fine.

- Philipp
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Thanks for your answers! See reply below.

2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> On Sun, 14 May 2017 14:43:44 +0200
> Philipp Kerling  wrote:
> > To start off:
> >  * Kodi should offer the user the opportunity to select inside the
> >    application on which monitor he/she wants to have Kodi displayed
> > on
> >    when in full-screen mode. Now I see that I can do this with
> > either
> >    wl_shell_surface::set_fullscreen and
> > zxdg_toplevel::set_fullscreen,
> >    which expect a wl_output to display the window on. But I am not
> > sure
> >    how I should match the wl_output instance I get from Wayland
> > with
> >    the monitor that the user selected. As far as I can see, I can
> > only
> >    identify the monitor by way of "make" and "model". This seems
> >    reasonable enough at first glance, but I think that in multi-
> > monitor 
> >    configurations it is not so uncommon to buy the same monitor
> > model
> >    multiple times - I personally have done this. Naturally, the
> > "make"
> >    and "model" of both monitors are identical, so I cannot discern
> >    which is which by looking at the wl_output metadata. Am I
> > missing
> >    something here?
> 
> That is all true, you are not missing anything.
> 
> It is a missing piece of protocol - I believe no-one has had both the
> need and the time to work on getting anything better yet.
> 
> > Why isn't e.g. the connector the output is connected
> >    to exported?
> 
> Because connector names are specific to DRM while Wayland (core
> protocol at least) is not.
I'm not sure I agree. See further below.

> Also, would you not want to identify the
> monitor rather than which connector it happens to be plugged in? 
I think that it's not quite decided yet what we want the user
experience to be on the Kodi side, i.e. do we want to bind output to
the physical monitor (however it is identified) or the GPU connector?
You can probably find use cases for both, so it's not an easy decision
to make. With X11 it was limited to the latter, so my first approach
was to mimic that. Ideally, both would be possible with Wayland and the
application can decide what is best for its specific use case. I
realize that this might be too much to ask for all at once, so I'll
talk to my mentor to decide which case we want to focus on for Kodi.
There are also two different points involved in this discussion:
   I. How the *user* identifies which output/monitor the fullscreen
  display should be on (e.g. with make+model+connector name, or by
  compositor-specific numbering).
  II. How *Kodi* or any other application then stores this, re-identifies
  this output/monitor and maps it to a wl_output on application start
  and hotplug. Possiblities include saving information pertaining to
  the output, the connector, the physical device, or any combination.

> Would
> a user even know which connector name matches to which monitor?
Yes, I also thought about this. Tech-savvy users might actually be able
to identify the connector name, but you are absolutely right that
usually users should not be expected to. In fact, having make and model
available actually is an improvement in that regard (on X11, Kodi
*only* displays connector since that is what's available via RANDR).
So: How do you suggest to identify a particular monitor then? As I
said, make and model are not sufficient - but serial number will not
help the user in identification. If there are multiple monitors of the
same model, I do not think that they (i.e. the physical devices) can be
reasonably discerned in a way that is transparent to the user. That's
why I suggested the connector name.

> To expose such a name in the protocol, we should define the space or
> meaning of the names. Human-readable? That's not the connector name,
> IMHO. Machine-parseable? Needs a very strict definition to work.
> Both?
RANDR output names (which are somewhat close to what I refer to as
connector names - it's a matter of debate whether output or connector
name would be more fitting for the Kodi use case) are specifically
meant to be "presented to the user", but I can see your point. I think
that machine-parseable is doable, also considering that RANDR did have
a "ConnectorType" property which is probably part of what we'd want
here. 

> A simple numbering with a way in the compositor to identify the
> monitors? Maybe.
What exactly do you mean by "a way in the compositor to identify the
monitors"? Like you can tell the compositor to display the output names
(briefly) on the outputs so the user knows which is which?
If so, couldn't this also be done by the application at least with more
or less arbitrarily assigned numbers by mapping a surface to each known
output that displays said number?
I'm beginning to think that something along those lines might be one of
the more user-friendly options of solving I. above.

> > This would allow way better matching and also give the
> >    user a 

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Pekka Paalanen]

On Mon, 15 May 2017 12:19:47 +0200
Philipp Zabel  wrote:

> On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:
> > On Sun, 14 May 2017 14:43:44 +0200
> > Philipp Kerling  wrote:
> >   
> > >quite a problem. I can see that zxdg_toplevel functionality is
> > >mostly superior to that of wl_shell_surface, but it has one omission
> > >that is crucial for Kodi: the ability to request a specific refresh
> > >rate for fullscreen display. This is needed for closely matching the
> > >display and video FPS so duplicated and skipped frames are kept to a
> > >minimum. Is this an intentional omission and/or is there anything
> > >that provides this functionality?  
> > 
> > Hopefully the xdg_shell designers would answer that, but I believe it
> > has been omitted for now to make it easier to declare the first
> > fundamental parts of xdg_shell stable. It is missing a lot, but the
> > foundation must agreed upon first before building more on top.  
> 
> Rather than combining the FPS request with fullscreening, wouldn't it be
> better to let applications set FPS as a property of the surface?
> 
> That way the client would make a promise that is is going to update
> surface contents with periodic commits of the specified rate, completely
> independent of the actual output hardware or fullscreen state.
> 
> The server could use that information to choose the best display refresh
> rate even if not in fullscreen mode.

Hi,

that's a pretty good reason to not have it in the xdg_shell fullscreen
request. ;-)

There are lots of this kind of details to consider for every single
feature added, which is why people tend to prefer not adding features
to xdg_shell until the foundation is stabilized, I believe.


Thanks,
pq


pgpztCj7G8gir.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Zabel]

On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:
> On Sun, 14 May 2017 14:43:44 +0200
> Philipp Kerling  wrote:
> 
> > Hi Wayland team and community,
> > 
> > allow me to quickly introduce myself first, since this is my first post
> > on this list.
> > I'm Philipp, studying Computer Engineering and currently working on
> > getting Wayland support (back) in Kodi as Google Summer of Code project
> > [1] [2].I might have to ask some questions about specific aspects of
> > Wayland over the next few months. I'll try not to be too annoying
> > though :-)
> > Please tell me if this is not the right place to ask this kind of stuff
> > or if anything is unclear.
> 
> Hi,
> 
> you are exactly in the right place. :-)
> 
> > To start off:
> >  * Kodi should offer the user the opportunity to select inside the
> >application on which monitor he/she wants to have Kodi displayed on
> >when in full-screen mode. Now I see that I can do this with either
> >wl_shell_surface::set_fullscreen and zxdg_toplevel::set_fullscreen,
> >which expect a wl_output to display the window on. But I am not sure
> >how I should match the wl_output instance I get from Wayland with
> >the monitor that the user selected. As far as I can see, I can only
> >identify the monitor by way of "make" and "model". This seems
> >reasonable enough at first glance, but I think that in multi-monitor 
> >configurations it is not so uncommon to buy the same monitor model
> >multiple times - I personally have done this. Naturally, the "make"
> >and "model" of both monitors are identical, so I cannot discern
> >which is which by looking at the wl_output metadata. Am I missing
> >something here?
> 
> That is all true, you are not missing anything.
> 
> It is a missing piece of protocol - I believe no-one has had both the
> need and the time to work on getting anything better yet.
> 
> > Why isn't e.g. the connector the output is connected
> >to exported?
> 
> Because connector names are specific to DRM while Wayland (core
> protocol at least) is not. Also, would you not want to identify the
> monitor rather than which connector it happens to be plugged in? Would
> a user even know which connector name matches to which monitor?
> 
> To expose such a name in the protocol, we should define the space or
> meaning of the names. Human-readable? That's not the connector name,
> IMHO. Machine-parseable? Needs a very strict definition to work. Both?
> A simple numbering with a way in the compositor to identify the
> monitors? Maybe.
> 
> > This would allow way better matching and also give the
> >user a chance to select the right monitor without having to try all
> >options. Serial number (or anything similar - not sure if the EDID
> >has this though) could also be OK.
> 
> EDID may have a serial number, yes.
> 
> Physical monitor devices are not the only things though. An output
> could be just a window in another window system. An output could be at
> the end of a streaming network connection. Etc. So aiming for a generic
> solution here would have a really wide scope.
> 
> However, there already is a unique numbering for wl_outputs, even
> though it's not exactly user-friendly. It is the wl_output "name"
> advertised by wl_registry, which you use in wl_registry.bind request to
> create a wl_output instance. This "name" is the same for all clients.
> 
> What we would really need is a new protocol extension designed to cater
> for specific use cases and offering the additional information to help
> make user-friendly UIs. Maybe compositors should a) number of the
> outputs, and b) let the user give them arbitrary names to be shown in
> application UIs? But then, do you tie the output identity to the
> connector or the physical device? Or an intelligent mix?
> 
> Would it be in scope for your work to design such an extension? It's
> relatively easy to write a protocol proposal, but getting it reviewed
> and hopefully ack'd by more than one DE project is often hard and time
> consuming. And then you'd need to provide an implementation on at least
> one compositor, unless you find someone else to collaborate with you.
> 
> >  * Am I correct in that if I use zxdg_toplevel (i.e. give this role to
> >a surface), I cannot also use wl_shell_surface? If so, this would be
> 
> Yes. wl_shell and xdg_shell suites of protocol extensions are mutually
> exclusive, you cannot use both for the same wl_surface. wl_shell is the
> deprecated one, and xdg_shell suite is the replacement waiting to be
> decleared stable.
> 
> >quite a problem. I can see that zxdg_toplevel functionality is
> >mostly superior to that of wl_shell_surface, but it has one omission
> >that is crucial for Kodi: the ability to request a specific refresh
> >rate for fullscreen display. This is needed for closely matching the
> >display and video FPS so duplicated and skipped frames are kept to a
> >   

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Pekka Paalanen]

On Sun, 14 May 2017 14:43:44 +0200
Philipp Kerling  wrote:

> Hi Wayland team and community,
> 
> allow me to quickly introduce myself first, since this is my first post
> on this list.
> I'm Philipp, studying Computer Engineering and currently working on
> getting Wayland support (back) in Kodi as Google Summer of Code project
> [1] [2].I might have to ask some questions about specific aspects of
> Wayland over the next few months. I'll try not to be too annoying
> though :-)
> Please tell me if this is not the right place to ask this kind of stuff
> or if anything is unclear.

Hi,

you are exactly in the right place. :-)

> To start off:
>  * Kodi should offer the user the opportunity to select inside the
>application on which monitor he/she wants to have Kodi displayed on
>when in full-screen mode. Now I see that I can do this with either
>wl_shell_surface::set_fullscreen and zxdg_toplevel::set_fullscreen,
>which expect a wl_output to display the window on. But I am not sure
>how I should match the wl_output instance I get from Wayland with
>the monitor that the user selected. As far as I can see, I can only
>identify the monitor by way of "make" and "model". This seems
>reasonable enough at first glance, but I think that in multi-monitor 
>configurations it is not so uncommon to buy the same monitor model
>multiple times - I personally have done this. Naturally, the "make"
>and "model" of both monitors are identical, so I cannot discern
>which is which by looking at the wl_output metadata. Am I missing
>something here?

That is all true, you are not missing anything.

It is a missing piece of protocol - I believe no-one has had both the
need and the time to work on getting anything better yet.

> Why isn't e.g. the connector the output is connected
>to exported?

Because connector names are specific to DRM while Wayland (core
protocol at least) is not. Also, would you not want to identify the
monitor rather than which connector it happens to be plugged in? Would
a user even know which connector name matches to which monitor?

To expose such a name in the protocol, we should define the space or
meaning of the names. Human-readable? That's not the connector name,
IMHO. Machine-parseable? Needs a very strict definition to work. Both?
A simple numbering with a way in the compositor to identify the
monitors? Maybe.

> This would allow way better matching and also give the
>user a chance to select the right monitor without having to try all
>options. Serial number (or anything similar - not sure if the EDID
>has this though) could also be OK.

EDID may have a serial number, yes.

Physical monitor devices are not the only things though. An output
could be just a window in another window system. An output could be at
the end of a streaming network connection. Etc. So aiming for a generic
solution here would have a really wide scope.

However, there already is a unique numbering for wl_outputs, even
though it's not exactly user-friendly. It is the wl_output "name"
advertised by wl_registry, which you use in wl_registry.bind request to
create a wl_output instance. This "name" is the same for all clients.

What we would really need is a new protocol extension designed to cater
for specific use cases and offering the additional information to help
make user-friendly UIs. Maybe compositors should a) number of the
outputs, and b) let the user give them arbitrary names to be shown in
application UIs? But then, do you tie the output identity to the
connector or the physical device? Or an intelligent mix?

Would it be in scope for your work to design such an extension? It's
relatively easy to write a protocol proposal, but getting it reviewed
and hopefully ack'd by more than one DE project is often hard and time
consuming. And then you'd need to provide an implementation on at least
one compositor, unless you find someone else to collaborate with you.

>  * Am I correct in that if I use zxdg_toplevel (i.e. give this role to
>a surface), I cannot also use wl_shell_surface? If so, this would be

Yes. wl_shell and xdg_shell suites of protocol extensions are mutually
exclusive, you cannot use both for the same wl_surface. wl_shell is the
deprecated one, and xdg_shell suite is the replacement waiting to be
decleared stable.

>quite a problem. I can see that zxdg_toplevel functionality is
>mostly superior to that of wl_shell_surface, but it has one omission
>that is crucial for Kodi: the ability to request a specific refresh
>rate for fullscreen display. This is needed for closely matching the
>display and video FPS so duplicated and skipped frames are kept to a
>minimum. Is this an intentional omission and/or is there anything
>that provides this functionality?

Hopefully the xdg_shell designers would answer that, but I believe it
has been omitted for now to make it easier to declare the first
fundamental