Why isn't Xwayland just a Wayland client?
ppaalanen at gmail.com
Thu Sep 7 08:05:44 UTC 2017
On Wed, 6 Sep 2017 21:05:33 +0200
Joseph Burt <caseorum at gmail.com> wrote:
> On Wed, Sep 6, 2017 at 4:45 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > Popups (e.g. menus) in Wayland use protocol that provides the server
> > with:
> > - the relationship to the window which the popup is for, and
> > - the input event identity that triggered the popup.
> > These are required on Wayland: the parent window is required for
> > positioning and stacking, and the input event identity determines
> > whether the popup is valid.
> > X11 protocol does not necessarily provide these. On X11, the client
> > puts a window at x,y and makes an input grab. That's it.
> > You would have to infer from x,y and the X11 window stack which X11
> > window might be the parent (if it even exists) and guess what input
> > event might have triggered the popup (there might not be any) to be
> > able to translate that into Wayland.
> > Xwayland would also need to guess that the input grab is related to
> > showing the window to be able to combine the two actions into a popup
> > request on Wayland.
> > I hope this gives you an idea why it is so hard to try to translate
> > window management from X11 to Wayland protocol. Writing an X11 window
> > manager is extremely painful to begin with, making one that can
> > translate into Wayland is much more painful because of the fundamental
> > design differences. The "out-of-band" design of putting an X11 WM in a
> > Wayland compositor and using X11 to manage X11 windows is the
> > compromise to get things working.
> You're absolutely right, X clients will never use Wayland's builtin
> popup and transient logic, and with all of X's quirks, there will
> always have to be an X server somewhere.
I really meant that Xwayland, the X server, *is* the translator. I
believed that I explained why it is extremely difficult to make
Xwayland internally translate X11 to Wayland without adding Xwayland
specific protocol extensions to Wayland. Doing so requires coding
heuristics and policy into Xwayland, which is something generally
avoided in X servers I believe.
Still, I don't claim it's impossible or should never be done, I'm just
saying it will be much harder to implement than the current situation
where people already have a working X11 WM in their project, and
perhaps requires a Wayland extension going against Wayland design
principles for the translating X server alone.
In the current model, all the violations to Wayland design principles
are internal implementation details of a Wayland compositor acting as
the X11 WM.
> Where does the whole construction fail if the little bit of XWM logic
> is in Xwayland? Going a little farther, I'm imagining toplevel X
> client windows, clients isolated or not, arranged in the (essentially
> arbitrary and virtual) X coordinate space such that none overlap, each
> corresponding with a wl_surface, with everything on top done by the X
> server and/or via subsurfaces. That leaves the little WM shim dealing
> with decoration if required, close, resize, and grabs. How the
> compositor positions or stacks is irrelevant.
I kind of wish I shared your optimism, but I'm thinking more of a death
by a thousand papercuts kind of situation, not a single big failure
I'd be screaming in delight and joy if someone proved it is possible to
turn Xwayland into just a regular Wayland client that has no special
privileges nor requires any nasty Wayland extensions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel