Announcement

Collapse
No announcement yet.

XWayland 21.1 Release Candidate Offers Split From The X.Org Server

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • duby229
    replied
    Originally posted by curfew View Post
    That was never the intention, sorry that it took almost a decade for you to understant that. Supporting Wayland basically requires every single application to be patched for it. Sure, at least for Qt and GTK-based apps it's mostly very painless: just let the toolkit do all the heavy lifting. But even after that many apps simply cannot work, because they try to do something that Wayland explicitly forbids. Apps like screen recorders and others that want to access the "global state" which doesn't really exist anymore in the same way.
    Yeah, plus the other dozens of scenarios that don't work anymore. That's not a misunderstanding, that's a fact.

    Leave a comment:


  • curfew
    replied
    Originally posted by muncrief View Post
    I'm primarily referring to the issues with KDE and XFCE mppix , but also with all other things that aren't Gnome. If XWayland was a drop in replacement for X, which is how it was initially presented, it would just work with everything.
    Sounds like a misunderstanding on your part. Xwayland is a drop-in for running Xorg apps on Wayland, but even then you first need the Wayland session to exist. And after that Xwayland and the primary Wayland session somehow need to interact, which probably requires some additional work implemented in the Wayland host.

    Leave a comment:


  • curfew
    replied
    Originally posted by muncrief View Post
    Well, it doesn't appear that there's ever going to be a "drop in" Wayland replacement for X. Wayland was first released 9 years ago, and XWayland 7 years ago. And yet even the developers still have great difficulty with it.
    That was never the intention, sorry that it took almost a decade for you to understant that. Supporting Wayland basically requires every single application to be patched for it. Sure, at least for Qt and GTK-based apps it's mostly very painless: just let the toolkit do all the heavy lifting. But even after that many apps simply cannot work, because they try to do something that Wayland explicitly forbids. Apps like screen recorders and others that want to access the "global state" which doesn't really exist anymore in the same way.

    Leave a comment:


  • set135
    replied
    Originally posted by duby229 View Post

    EDIT: Almost -all- Linux applications are running on xwayland when in a Wayland session. There are only a handful of exceptions and most of those handful are buggy as hell. Hence the -entire- reason why 94% of all linux users are still on xorg...
    That is funny; I have been running wayfire on one of my vts for a while now, and I turned off xwayland support. Almost everything seems to run just fine native wayland style. Browsers, office suite, image viewers, terminals, video stuff....etc. There _are_ some X-only programs, but most modern applications are written using one of the several toolkits that support wayland out of the box. Most Linux users are running X now, because that was the default. And those who are not curious to test new stuff will probably keep running X until their distro changes the default to something else.

    Leave a comment:


  • Sonadow
    replied
    Finally. Xorg and Xserver had been nothing but pain.

    I don't wish to ever relive those days where the xserver refused to start and Xorg -configure returned all manner of obscure errors that simply could not be fixed or addressed to obtain a working graphical desktop. Which I experienced again first hand when trying out both FreeBSD 12-CURRENT and FreeBSD 13-BETA.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mppix View Post
    Exactly the point that I was trying to make.
    Xwayland runs on top of Wayland. Therefore, a Xwayland based Xserver is a Wayland compositor.....
    Xwayland is a Wayland client application. So its not Compositor. Thing to remember as gamescope from valve shows and the Weston reference compositor shows. Is that a Wayland compositor can in fact be a X11 application as well. So if Xwayland was a full blown wayland compositor it would be possible for it to run directly on top of X11 bare metal as well but Xwayland is not its only a Wayland client application.

    Being a compositor is different to being a client application. Compositor has to have all your hardware interface library bits and those open up some really wacky running locations.

    Leave a comment:


  • mppix
    replied
    Originally posted by oiaohm View Post

    Xwayland is not a Wayland compositor. Kind of comes clear when you look at the rough overview. Bare metal X11 roughly looks like one of the following the following.

    1) X11 server backend->X11 server frontend
    2) X11 server backend->X11 third party compositor->X11 server frontend

    The server X11 backend has the internal X11 compositor and X11 driver interfaces and so on. Yes this is also the area of the X11 server that does screen capture and input injection.

    Xwayland looks like.
    Wayland compositor->Xwayland

    Xwayland here is the X11 server frontend parts

    This explains why injecting input and screen capture are not working with Xwayland as those are going to the X11 Server backend that is not there so the functions nop. Yes X11 server frontend code in Xwayland is directly hooked up to Wayland client application interfaces.

    Now if Xwayland was in fact a Wayland compositor it could be using libdrm to get direct screen access or directly injecting input at least for X11 applications..... Not being a Wayland compositor does put a lot of limitations on what Xwayland can do.
    Exactly the point that I was trying to make.
    Xwayland runs on top of Wayland. Therefore, a Xwayland based Xserver is a Wayland compositor.....

    Leave a comment:


  • mppix
    replied
    Originally posted by AmericanLocomotive View Post
    Pardon me if I'm misunderstanding things (as the Linux GUI/Graphics stack still baffles me for the most part): Is this article really saying that x.org - something used by nearly all distributions, has no one actively developing/working on it? How is that even possible?
    The X window system was developed in the 80s and 90s. However similar to VNC, its governing bodies are defunct and the protocol cannot be changed anymore. Any change would result in a non-conformant implementation.

    It dates back to a time where computer/display architecture barely evolved beyond the terminal. For example, it includes clipboards, a print server, drawing primitives, or networking/network transparency. However, today's desktops are primarily based on extensions to enable a modern look'n'feel etc.

    Xorg is an X server implementation. For the reasons mentioned, it is more or less a Frankenstein that comes with 40 years of baggage that cannot be removed. It is one of the most complex opensource projects (possibly competing with the Kernel) and the least rewarding.
    Hence, the main Linux DEs + industry came up with Wayland and Apple with Metal. The goal with Wayland was to break the X server functionality down to make it maintainable and move barely related parts to separate packages.

    Xorg (as in the server) is more or less a walking dead. However, the X protocol is still very useful as a compatibility layer for Linux/Wayland and Apple/Metal.
    Last edited by mppix; 17 February 2021, 09:52 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mppix View Post
    I'm not sure what a XWayland-based XServer is other than a Wayland compositor?
    You could of course force every application to use XWayland and get window privacy by running an independent XWayland session for each application. You'd still need the copy-and-paste tools, screen-sharing, etc. introduced by Wayland compositors. Also it would be quite inefficient compared to just run the GUI framework, e.g. GTK4, natively on Wayland...
    Xwayland is not a Wayland compositor. Kind of comes clear when you look at the rough overview. Bare metal X11 roughly looks like one of the following the following.

    1) X11 server backend->X11 server frontend
    2) X11 server backend->X11 third party compositor->X11 server frontend

    The server X11 backend has the internal X11 compositor and X11 driver interfaces and so on. Yes this is also the area of the X11 server that does screen capture and input injection.

    Xwayland looks like.
    Wayland compositor->Xwayland

    Xwayland here is the X11 server frontend parts

    This explains why injecting input and screen capture are not working with Xwayland as those are going to the X11 Server backend that is not there so the functions nop. Yes X11 server frontend code in Xwayland is directly hooked up to Wayland client application interfaces.

    Now if Xwayland was in fact a Wayland compositor it could be using libdrm to get direct screen access or directly injecting input at least for X11 applications..... Not being a Wayland compositor does put a lot of limitations on what Xwayland can do.

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by muncrief View Post
    From what I understand Red Hat was the primary contributor to X, but abandoned it because they wanted to try and force quicker adoption of Wayland.
    That is a bit of an mis-characterization.

    Over the decades, various organizations have contributed to the entire X stack. Red Hat among them, but they were not the only. But managing the entire QA and release functions was a very substantial effort, and Red Hat was the most recent (presumably mostly because their customers at the time used/needed X, and Red Hat often stepped up to support what their customers needed).

    Long ago when the people responsible for X decided it needed replacement, they designed what we now know of as Wayland (it was designers and promoters of X that decided Wayland was the future, as X had run its course, and its limitations were becoming far to problematic). Red Hat was part of those discussions and proposals, so certainly concurred, and put substantial efforts into Wayland while continuing their X QA/release role at that time.

    In recent times those efforts with promoting and enabling Wayland throughout the stack moved to the point Red Hat apparently no longer saw a reason to staff the QA and release process for the entire X stack as Wayland just worked (for their major paying customers, at least). And Red Hat chose to stop resourcing that entire X release process, even as the need for that limited piece of X known as XWayland will need to be supported for some time in the real world as there are still X apps. But that (XWayland) is now the target for release, not the entire X stack.

    Hopefully others will step up to maintain and develop X
    And this will almost certainly not happen (although individual patches to integrate on an ad-hoc basis and the occasional security patch will almost certainly still be floating around). Others have had the chance to step forward to manage the entire X release process for quite some time. People have explicitly asked for others to step forward(*). No one with the resources needed to do so has volunteered.

    One should never say never (again), but at this time it certainly looks like there will never be a 1.21 release.


    (*) If your org is large enough to resource that entire process on an ongoing basis, and somehow missed all the discussions, go talk to the X project, as there could be room for you.

    Leave a comment:

Working...
X