[RFC wayland, weston] Expose an output's connector name

[Quentin Glidic]

On 07/02/2017 20:51, Matthias Treydte wrote:
> I already brought this up on IRC before and finally started to work 
> on it. The goal is to give an Wayland client some identifier which 
> allows it to recognize the physical connector which corresponds to 
> some Wayland output.
> 
> The rationale why such an API is useful is that a client might want 
> to ensure that it's content is available on some well-known 
> connector. Imagine, for example, a video player which "knows" that 
> the projector is connected to the second HDMI port.

Hi,

(Reminder: with wl_shell and xdg_shell, an app can only decide which 
output to go *fullscreen* on, and that is the only case where 
identifying a wl_output would be on any use.)

I think the video player use case is ill-defined. Users don’t want the
video player to forces itself on a specific output. Instead, they want
the compositor to properly put the video player on the output that will
be the best at said time.
If I’m working on my primary monitor, I want the video player on the
secondary one, not to disturb the work area.

Another use case was for an app to go fullscreen on the last output it 
was fullscreen on. (So app fullscren on A, user un-fullscreens, moves to 
B, user fullscreens again, app asks to go to A.)

My compositor is the only one knowing enough to make such a decision, 
and I have yet to see a use case where an application should be able to 
decide.
wl_shell and xdg_shell already have the “this is a hint” restriction, 
and we cannot change wl_shell now, but I think this wl_output choice 
should go, eventually (in xdg_shell at least).


> Our use case is like that: We have an Wayland application which, 
> running under the fullscreen shell, presents one surface per output.

This is a very important information: you’re using the fullscreen shell. 
It is not designed for “normal” applications.
And Emre was talking about IVI, which is very different from desktop too.

> [snip]
> The first patch extends the "wl_output" interface by a new 
> "connector" event, providing a string to the client which can be
> used as a stable identifier for that output. I'm unsure if this
> version bump to the core Wayland protocol is acceptable, but to me
> this seems the obvious place where this information should be
> published. A lot of monitor related information (resolution(s),
> physical size, maker, model, ...) is already published there, so it
> seems natural.
> [snip]

As a result, I strongly feel like wl_output is not the right place.
It would bring no value to the desktop shells, and even mislead people 
to think it would be useful. (I even remember hearing that wl_output 
already has too much information not useful to the average app that 
should have been hidden.)

Another advantage of not using wl_output is that each shell can define 
its own value range. IVI could use uints because it’s supposed to run on 
known hardware with MAC-like identifiers (wild guess) while 
fullscreen-shell would use strings.


Cheers,

-- 

Quentin “Sardem FF7” Glidic