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
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
