[RFC PATCH wayland-protocols] Introduce logical output protocol for Xwayland
ppaalanen at gmail.com
Mon Jul 3 09:25:02 UTC 2017
On Mon, 3 Jul 2017 04:42:52 -0400 (EDT)
Olivier Fourdan <ofourdan at redhat.com> wrote:
> So, 3 possibilities so far:
> 1. Add the logical output in wl_output
> Looked like a good idea initially, not so much on further
> consideration. pro: It's just an additional event to a existing
> Wayland core protocol cons: It's quite limited in usefulness outside
> of its indented use for Xwayland and remains fairly desktop centric
> 2. Add a specific Xwayland protocol
> pro: It's just an event for now, but this could be extended in
> the future, but not sure with what. cons: might seem a bit overkill
> to add a new protocol just for that, unless it's extended in the
> future. Might need to be deprecated again if/when option #3 is
> chosen. Not necessarily a huge problem though if the protocol is
> limited to Xwayland.
> 3. Deprecate most of the desktop centric parts of wl_output and add a
> new wp_output protocol for this intended use, as discussed on irc (*)
> pro: would clean up wl_output from most concepts "desktop-ish". Even
> if size might be less "desktop-ish" that position, Xwayland need both
> anyway. cons: might take some considerable time to get to an
> agreement to such a protocol, could be seen as a longer term solution.
Maybe more along the lines of xdg_output rather than wp_output. Is
there something else desktops would need about outputs? Identification
(machine-wide unique connector name, output number?) has come up
before, in both human-readable description and persistent
machine-parseable forms. Output type (monitor, projector, ...) maybe?
No need to add everything from the start, but I think it could make
sense. Start with the position and size parameters all desktops use
today, but maybe leave them somehow optional, and don't pack more than
one thing (e.g. logical size) per event.
As for deprecation of existing wl_output bits, it could be as simple
start as changing nothing. Maybe add documentation saying that
extensions offer probably better things to use, or that some particular
parameters are not always reliable.
> I, for one, has no preference, other than we shall need this as I see
> no other way to make Xwayland work reliably with the various Wayland
> compositors implementations that already exist.
> (*) incidentally, the login who captured the irc logs probably got
> kicked off irc, there's no more logs of past discussions:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel