concerns over wayland and need for wayland app display to X Server

[David Jackson]

On Mon, Feb 20, 2012 at 2:56 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> On 02/19/2012 03:08 PM, Daniel Stone wrote:
>
>> Hi,
>> There's already a Wayland session that runs on X, and as you asked
>> for, an X server that runs rootless on Wayland, with full and proper
>> integration with a Wayland session.  Hope this satisfies you.
>>
>
> The "Wayland session that runs on X" is, I believe, more like "a Wayland
> desktop inside an X window" and is *not* what he is asking for.
>
> I think he wants to see each window created by the Wayland program making
> a different X window that is completely filled by the contents of the
> Wayland window.
>
> So far it appears that toolkits like Qt are being written to internally
> switch between Wayland and Xlib, to provide this for him. This is probably
> the best solution.
>
>
 I am asking for the ability to display a wayland app to an X server. My
original suggestion was perhaps can be done via a runtime loadable client
side driver that would support the wayland client API, there would be
drivers for rendering from a wayland client to a wayland session and to an
wayland client to an X session and they can be selected at runtime, and the
selected one loaded into the wayland application. The wayland client driver
for X client connection to X server could be glue code between wayland APi
and Xlib.

the qt and gtk based methods are not sufficient as there will be other
applications with custom widgets which will not provide such switching. So
we cannot rely on that, the support needs to be in some optional module
that can be loaded into wayland. I specifically mentioned in my original
message that counting on widgets and applications to implement the
functionality is not sufficient, there are more than enough lazy and sloppy
programmers who wont do it.


There could be a Wayland compositor that actually "composites" the windows
> into X windows, which I think matches most closely what is being asked for.
> There are serious problems however. In particular the window borders are
> drawn by the client. Stripping them off and providing enough information
> for the X server to draw new ones would require all the crap that is in X
> now for clients to communicate information to the server, and would break
> any new and clever uses of the window borders. Displaying them as
> borderless windows would also work but may make some X desktops act
> strange. Double window borders may be somewhat acceptable, or an api from
> the compositor saying "no window border is needed" similar to what is
> needed for fullscreen. Stacking issues due to X window managers raising on
> click and the inability to outwit this without sending a limited set of
> rules through "transient for" hints is also going to be a big pain, but it
> might not break clients that consist of only one window and popup menus.
>
>
You probably can best speak for what is the best solution. If this
compositor idea is better than my idea for runtime selectable client side
driver in wayland clients, than the compositor idea is what it should be.
The double window borders would be tolerable for the benefit of being able
to display a future flood of wayland apps into our X sessions, and over my
SSH connections.

Most window managers work fine with apps that request border less windows,
i know several X clients that do this, like xmms.

Another thing that might be useful is you can display an X client into a
window created by another X Client. A big window can be created on an X
server, and then any X client can be displayed inside of it. By default the
subwindows won't be managed by the window manager of the root window
(window managers only manage one level) (though, some window managers allow
you to tell it to manage the subwindows in a window other than the root
window, not the root window, one is ctwm and its -w option).  Also the X
system has Xreparentwindow which allows windows to be moved between parent
windows.

One big window on the X server could be created for wayland apps and the
wayland apps displayed into there. The utility that allows a wayland app to
be displayed to an X server over an X client connection could have a -w
option which would give the window id to display to as well as the -display
option for address and port.

as far as the stacking, it went a little over my head. I guess you are
talking about coordination of the application stacking on the X server and
the wayland server, and how the stacking models generate expose events. I
suppose that the wayland server requests pixmaps for newly exposed areas
from applications and manages the stacking logic and so on, if thats in a
non-runtime replaceable part of the wayland server, i can see it could be a
mess to work around this. Plus, the stacking would be different on the X
server than on the wayland server due to X applications beingf present on
teh X server but not on the wayland server. It makes one think about making
a custom wayland server just for wayland client->xserver by ripping out the
wayland servers stack management and expose code and just wiring X expose
events straight to wayland clients.

With my idea of putting a runtime loadable driver into the wayland client,
with an xclient connection from the wayland client to an x server, the X
server would send Expose events, over x11 protocol, to the xlib in the
wayland client, glue code would handle the event and just get the necessary
data from the wayland application itself through the wayland API. If
wayland client libraries are dynamically linked it may be possible to
easily swap different versions of the library at runtime.

That idea would probably utilise some type or runtime loading and dynamic
linking.


In general I think it would be really ugly if all the mistakes of X have to
> be replicated in the Wayland api just to communicate this information. So I
> think the proper answer is "no, it is not going to support this perfectly,
> but there will be compositors that will try." Please do not add crap to the
> Wayland API just to match X!
>
>


I am not asking for this, There must be a way to make this wayland to x
bridge without any of this.


> ______________________________**_________________
> wayland-devel mailing list
> wayland-devel at lists.**freedesktop.org<wayland-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/wayland-devel<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120220/d6364f8d/attachment.htm>