Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Wayland vs. Full Wayland

  1. #11
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    22,271
    Blog Entries
    1

    Default Re: Wayland vs. Full Wayland

    Quote Originally Posted by mchnz View Post
    No I don't think the way you've described it is quite correct. Again looking athttps://wayland.freedesktop.org/docs/html/ch05.html

    If you look at figure 5 and the surrounding description, XWayland is part of the Wayland compositor, not the other way around. The normal Wayland compositor contains an XWayland component and starts an instance of it to handle X11 clients (it's true the to the X11 clients, XWayland just looks like the real deal). In this way normal Wayland compositor handles native Wayland-windows and X11-windows somewhat seamlessly for something like KWin.

    This model allows Wayland-KWin running in Wayland to manage the entire session of both Wayland windows and X11 windows. That's what makes non-full Wayland functional.
    I concur with this description.
    openSUSE Leap 15.2; KDE Plasma 5

  2. #12
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,905
    Blog Entries
    2

    Default Re: Wayland vs. Full Wayland

    Quote Originally Posted by mchnz View Post
    No I don't think the way you've described it is quite correct. Again looking athttps://wayland.freedesktop.org/docs/html/ch05.html

    If you look at figure 5 and the surrounding description, XWayland is part of the Wayland compositor, not the other way around. The normal Wayland compositor contains an XWayland component and starts an instance of it to handle X11 clients (it's true the to the X11 clients, XWayland just looks like the real deal). In this way normal Wayland compositor handles native Wayland-windows and X11-windows somewhat seamlessly for something like KWin.

    This model allows Wayland-KWin running in Wayland to manage the entire session of both Wayland windows and X11 windows. That's what makes non-full Wayland functional.



    No, I think full wayland just means that as well as KWin using Wayland-Qt libs, the applications such as konsole and dolphin also use Wayland-Qt and Wayland-GTK libs (this could be switched by not much more than a change to LD_LIBRARY_PATH). Because the Wayland versions of these libraries are currently not good enough to handle all applications we need a non-full X11-lib supporting alternative. Plus XWayland is still started for full-wayland, otherwise xterm, xeyes, etc would fail.

    At least that's my interpretation.

    BTW, as I understand X11, it uses local UNIX sockets unless a DISPLAY is set to a TCP name/address (so DISPLAY=:0 would result in UNIX sockets being used and DISPLAY=10.0.0.22:0 would force X11 to use TCP). It's rare these days to use X11 over TCP-IP for more than admin xterms/emacs/yast/etc (issues with OpenGL and sound kind of diminished remote X11 via TCP for full desktop use).
    IMO the diagram you're referring to is accurate but you are interpreting incorrectly.
    And, you'll find the diagram 3.1 on the following page is more clear, supporting what I describe.

    https://wayland.freedesktop.org/docs/html/ch03.html

    As I said earlier, the referenced XWayland page is probably misleading read by itself. To properly understand the XWayland architecture you also have to read the preceding pages that describe Full Wayland and some other ways XWayland is described.

    That said... who knows...
    As I mentioned, by simply referring to the "Wayland compositor" in both Full Wayland and XWayland by the same name without differentiation, it's easy to confuse or assume the two are same when I'm pretty sure the documentation says they're not the same.
    If someone can point out where in the documentation it says that the X server passes data to the compositor in a Full Wayland instead of a Wayland compositor in the X server, I'm easy to admit my mistake.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  3. #13
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,905
    Blog Entries
    2

    Default Re: Wayland vs. Full Wayland

    BTW -
    For anyone following this discussion about what compositor is actually used or whether it's one and the same for both Full Wayland and XWayland, it's not just an academic exercise (lots of words with no significance).

    It also means that although an X server Wayland compositor might be made as nearly the same as a Full Wayland compositor as possible, it's not guaranteed to be so.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  4. #14
    Join Date
    Feb 2009
    Location
    New Zealand
    Posts
    162

    Default Re: Wayland vs. Full Wayland

    Quote Originally Posted by tsu2 View Post
    IMO the diagram you're referring to is accurate but you are interpreting incorrectly.
    And, you'll find the diagram 3.1 on the following page is more clear, supporting what I describe.

    https://wayland.freedesktop.org/docs/html/ch03.html

    As I said earlier, the referenced XWayland page is probably misleading read by itself. To properly understand the XWayland architecture you also have to read the preceding pages that describe Full Wayland and some other ways XWayland is described.

    That said... who knows...
    As I mentioned, by simply referring to the "Wayland compositor" in both Full Wayland and XWayland by the same name without differentiation, it's easy to confuse or assume the two are same when I'm pretty sure the documentation says they're not the same.
    If someone can point out where in the documentation it says that the X server passes data to the compositor in a Full Wayland instead of a Wayland compositor in the X server, I'm easy to admit my mistake.

    TSU
    The diagrams in your reference illustrate the differences between traditional/old X11 and Wayland. They don't illustrate the architecture of Wayland/XWayland.

    XWayland definitely only runs as part of wayland. From the Wayland FAQ: https://wayland.freedesktop.org/faq.html

    Is wayland replacing the X server?

    Mostly, yes. User sessions are able to run under Wayland today, via a number of compositors: Weston itself as well as Enlightenment, GNOME Shell, KDE, and a number of others under development. With most toolkits having Wayland ports, as well as frameworks such as GStreamer and SDL, it's perfectly possible to run a purely native Wayland session as your desktop.
    That being said, there are some clients which rely on X11, and always will be. To that end, XWayland provides a plugin for Wayland compositors, running a real X server. This gives legacy clients a real and compliant X11 platform to run on, displayed side by side with native Wayland clients in your Wayland session.
    It has to be this way so that Wayland can run old X11 applications, which is a major goal. The Wayland Wikipedia entry describes support for X11 and the full/non-full scenario pretty much as I have previously summarised them:

    Compatibility with X
    XWayland is an X Server running as a Wayland client, and thus is capable of displaying native X11 client applications in a Wayland compositor environment.[42] This is similar to the way XQuartz runs X applications in macOS’s native windowing system. The goal of XWayland is to facilitate the transition from X Window System to Wayland environments, providing a way to run unported applications in the meantime. XWayland was mainlined into X.Org Server version 1.16.[43]
    Widget toolkits such as Qt5 and GTK3 can switch their graphical back-end at run time,[44] allowing users to choose at load time whether they want to run the application over X or over Wayland. Qt 5 provides the -platform command-line option[45] to that effect, whereas GTK 3 lets users select the desired GDK back-end by setting the GDK_BACKENDUnix environment variable.[44][46]
    So it even in openSUSE full-wayland is likely possible to still force a some troublesome applications to use the X11 (Qt5/GTK3) libraries. Similarly in non-full-wayland, it is likely possible to force selected applications to use Wayland (Qt5/GTK) libraries. But playing such games will may cause problems with cut/paste drag/drop between the X11/Wayland (unless KWin includes code to bridge the two).

  5. #15
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    22,271
    Blog Entries
    1

    Default Re: Wayland vs. Full Wayland

    Quote Originally Posted by tsu2 View Post
    BTW
    For anyone following this discussion about what compositor is actually used or whether it's one and the same for both Full Wayland and XWayland, it's not just an academic exercise (lots of words with no significance).

    It also means that although an X server Wayland compositor might be made as nearly the same as a Full Wayland compositor as possible, it's not guaranteed to be so.

    TSU
    I don't understand what your confusion is about. From a Wayland perspective, XWayland is just another Wayland client. AFAIU, 'Full Wayland' refers to the desktop session (eg KDE Plasma) running as a Wayland compositor.

    A Qt app can be made to run as a Wayland client using 'QT_QPA_PLATFORM=wayland <application>

    More info:...
    https://wayland.freedesktop.org/qt5.html
    https://community.kde.org/KWin/Wayland

    The following will start a Plasma session on Wayland...
    Code:
    dbus-run-session startplasma-wayland
    Last edited by deano_ferrari; 22-Jun-2020 at 16:30.
    openSUSE Leap 15.2; KDE Plasma 5

  6. #16
    Join Date
    Feb 2009
    Location
    New Zealand
    Posts
    162

    Default Re: Wayland vs. Full Wayland

    You can actually play with a nested kwin_wayland running as wayland compositor inside a normal X11 session.

    Here is what I think would equate to openSUSE full-wayland:

    Code:
    #!/bin/bash
    # 
    export $(dbus-launch)
    # Force all Qt and GTK applications to use Wayland
    export QT_QPA_PLATFORM=wayland
    export GDK_BACKEND=wayland
    kwin_wayland  --width=1280 --height=1024 --xwayland plasmashell
    
    When this script is run, there will be a kwin_wayland process and under that an Xwayland sub-process. If you start a konsole inside the nested session, it will be running with wayland-Qt code paths.

    In the konsole you can see DISPLAY is set and you can run up an xterm with no issues, DISPLAY connects it to XWayland.

    If in a konsole you uset DISPLAY, you can no longer start an xterm from the konsole, but you can still start a konsole from the konsole. This is because konsole is using native wayland-Qt and doesn't use/need X11 or the value of DISPLAY.

    What about openSUSE non-full wayland? I think openSUSE non-full-wayland would equate to commenting out or removing the QT/GDK environment settings:
    Code:
    #!/bin/bash
    # 
    export $(dbus-launch) 
    kwin_wayland  --width=1280 --height=1024 --xwayland plasmashell
    
    The KDE applications will use the Qt X11 code paths. Interestingly when I play the same tricks in a konsole by unsetting DISPLAY, starting a new konsole does result in a cannot find display message, but the konsole starts anyway, so is it falling back to Wayland?

    Finally, a nested kwin_wayland can be started without an Xwayland client, just drop the --xwayland, in which case no X11 applications can run inside it and we definitely have to force all QT/GTK applications to use wayland (or the session won't start at all).
    Code:
    #!/bin/bash
    # 
    export $(dbus-launch) 
    # Force all Qt and GTK applications to use Wayland because there is no Xwayland
    export QT_QPA_PLATFORM=wayland 
    export GDK_BACKEND=wayland
    kwin_wayland  --width=1280 --height=1024 plasmashell
    
    Any xterm started in the above will start on the original outer desktop because DISPLAY=:0 was inherited and not overridden.

    A little more background...

    According to https://community.kde.org/KWin/Wayland kwin X11 is a X11 window manager and also an X11 compositor. Developer resources aren't sufficient to create a stand alone Walland kde compositor, so the kwin codebase also serves to for kwin_wayland, which is a KDE window manager and Wayland compositor.

    Under Wayland we have no wayland process, just a running compositer such as kwin_wayland. That differs from X11, where X11 runs in a process separate from kwin_X11 and they talk to each other. The difference can be clearly seen via ps/pstree when running the above scripts.

    KWin_wayland is one of many compositors because Wayland is only protocol specification. There are dozens of Wayland compositors available, such as Weston (the reference implementation), Mutter, Enlightenment, etc. Presumably these compositors may share some code in the form of libraries, certainly many of them will use the XWalland client to support old X11 apps.

    Fun stuff!

  7. #17
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,905
    Blog Entries
    2

    Default Re: Wayland vs. Full Wayland

    I think you guys are confused by the terminology used in the documentation,
    In the Wikipedia reference, if you click on the footnote, inspect the announcement. It describes the Glamor rendering engine running in the X server. I wonder if that would be necessary if the X server merely translated and passed data to a Full Wayland backend where everything including Glamor exists.
    XWayland was mainlined into X.Org Server version 1.16
    When the XWayalnd Wayland compositor is deployed in the X server, the X server itself becomes the API interface to external clients and also itself becomes a client to the embedded Wayland compositor. Hence, no external Full Wayland is involved.
    The stuff about XWayland supporting common DE and WM is probably merely interesting, it's why XWayland is compatible with everything, because it's not imposing a new architecture, objects and components but I don't see it as a differentiator whether a full Wayland backend is used or not..

    But,
    We're talking in circles when AFAIK none of us are Wayland Developers.

    I recommend putting this topic on hold until I (or anyone else) can find someone who can authoritatively provide answers.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  8. #18
    Join Date
    Feb 2009
    Location
    New Zealand
    Posts
    162

    Default Re: Wayland vs. Full Wayland

    Quote Originally Posted by tsu2 View Post
    I think you guys are confused by the terminology used in the documentation,
    In the Wikipedia reference, if you click on the footnote, inspect the announcement. It describes the Glamor rendering engine running in the X server. I wonder if that would be necessary if the X server merely translated and passed data to a Full Wayland backend where everything including Glamor exists.


    When the XWayalnd Wayland compositor is deployed in the X server, the X server itself becomes the API interface to external clients and also itself becomes a client to the embedded Wayland compositor. Hence, no external Full Wayland is involved.
    The stuff about XWayland supporting common DE and WM is probably merely interesting, it's why XWayland is compatible with everything, because it's not imposing a new architecture, objects and components but I don't see it as a differentiator whether a full Wayland backend is used or not..

    But,
    We're talking in circles when AFAIK none of us are Wayland Developers.

    I recommend putting this topic on hold until I (or anyone else) can find someone who can authoritatively provide answers.

    TSU
    Agreed. With Glamor we are crossing into new territory that blurs the discussion, which is not helpful.

    Glamor is something that is used to draw graphical output onto some graphical "buffer". This is NOT something that Wayland does, from the FAQ:

    Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents.
    Wayland's responsibility is to allocate and manage the buffers, keep track of which buffers belong to which on-screen windows, track which windows overlap each other, and efficiently created the composited final on-screen view. So a Wayland implementation is a window manager and compositor only.

    Part of the picture is that other bits of X11 have also been supplanted by other libraries, such as drawing libraries including Glamor, OpenGL, Vulkan, etc.

    So X11 applications running under XWayland still have to use something, such Qt/GTX, OpenGL/Glamor/Vulkan (or something older) to draw their output on the buffer allocated to them. The buffer will have come from Wayland (via XWalland), and that's how the result is properly managed by Wayland.

    At the same time pure Walland applications will also potentially using the same libraries to draw into there Wayland allocated buffers.

    Now it may be that the Walland implementation is also using the same libraries, OpenGL, Vulkan, Glamor etc to do the final job of rendering the screen and doing compositing effects.

  9. #19
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    22,271
    Blog Entries
    1

    Default Re: Wayland vs. Full Wayland

    @tsu2:I'm really not certain about most of what your question to be frank. The reference links are at most overviews, and perhaps that leads to your confusion about some of the details.

    When the XWayland Wayland compositor is deployed in the X server, the X server itself becomes the API interface to external clients and also itself becomes a client to the embedded Wayland compositor. Hence, no external Full Wayland is involved.
    The stuff about XWayland supporting common DE and WM is probably merely interesting, it's why XWayland is compatible with everything, because it's not imposing a new architecture, objects and components but I don't see it as a differentiator whether a full Wayland backend is used or not.
    "Full Wayland" just means where back-ends for GTK or Qt are set to Wayland, and really only has meaning in the context of the desktop environment. As mchnz already mentioned, this means 'QT_QPA_PLATFORM' and 'GDK_BACKEND' variables are both set to 'wayland'. Regular Plasma Wayland sessions will use X11 (XWayland) for applications (unless the application explicitly called with the pertinent environment variable set).

  10. #20
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    22,271
    Blog Entries
    1

    Default Re: Wayland vs. Full Wayland

    Quote Originally Posted by tsu2 View Post
    In the Wikipedia reference, if you click on the footnote, inspect the announcement. It describes the Glamor rendering engine running in the X server. I wonder if that would be necessary if the X server merely translated and passed data to a Full Wayland backend where everything including Glamor exists.
    That's a misconception on your part. There is no "translation" process. Wayland clients do their own rendering (to shared buffers), and notify the Wayland compositor when display updates are needed. As already mentioned, Wayland itself is a communication protocol used to communicate between Wayland clients and the display server (a Wayland compositor) for input and output (graphical update) events. The compositor
    collects updates (damage requests) from clients and then re-composites the entire screen (via an ioctl pageflip with KMS).

    The diagrams in your reference illustrate the differences between traditional/old X11 and Wayland. They don't illustrate the architecture of Wayland/XWayland.
    This image should help clarify how it fits together...
    https://upload.wikimedia.org/wikiped...and_glamor.svg
    openSUSE Leap 15.2; KDE Plasma 5

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •