Why isn't Xwayland just a Wayland client?
caseorum at gmail.com
Wed Sep 6 10:56:22 UTC 2017
I'm thinking this might be a job for a bit of translation shim within
Xwayland. Everything an X client needs either has a Wayland equivalent
(through an X server and a little translating XWM shim) or, where
forbidden by Wayland, can be stubbed out with a few white lies e.g.
"There are no other clients," "Your relative position is global."
I'm thinking of taking a whack at this. Are there any dragons in the
Xserver I should be aware of?
On Wed, Sep 6, 2017 at 12:37 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 6 Sep 2017 12:11:52 +0200
> Olivier Fourdan <fourdan at gmail.com> wrote:
>> On 6 September 2017 at 11:48, Joseph Burt <caseorum at gmail.com> wrote:
>> > To be clear, my first look at how the X11 channel is used in practice
>> > hasn't yet turned up the justification for its existence. The logic
>> > usually seems to be "if X client, send event over X11, else Wayland,"
>> > which is redundant. There must be something big, since tacking on a
>> > X11 channel is a big protocol extension, but I haven't found any
>> > discussion of that design decision. Can anyone point me in the right
>> > direction?
>> Positioning, stacking, focus management, decorations, X11 window
>> properties, ICCCM, etc. all those things that belong specifically to a X11
>> window manager which a Wayland compositor isn't. An X11 client running with
>> Xwayland does not become a Wayland client, it's still an X11 client,
>> whereas Xwayland itself is a Wayland client.
>> I guess one could come up with a X11 window manager specific protocol for
>> Wayland so that any compatible X11 window manager could integrate and work
>> along with a Wayland compositor, but that would be quite a lot of work, and
>> I am not sure about the benefits of such an approach.
> I understood the question the opposite way: why there is a X11 WM
> integrated in each Wayland compositor instead of integrated into
> Xwayland and shared by everyone?
> I can think a few possible reasons:
> - the big DEs already had a working X11 WM and the migration to Wayland
> evolved from that rather than throwing it out first
> - there are no suitable Wayland extensions for much of what one can do
> via X11, yet
> - the translation between X11 and Wayland window management protocols
> and concepts is very painful if even possible in general, because of
> the fundamental design difference: X11 is low-level (pure mechanism
> with no context) while Wayland is high-level (intent and context to
> let the server do the right thing)
> So it was easier to get Xwayland going by putting the X11 WM in the
> Wayland compositor, than trying to create a common X11-Wayland WM
> translation that would work for everything.
> Things might change in the future once Wayland on the desktop matures,
More information about the wayland-devel