5 ms·

this isn't "no plans to support wayland" - these drivers are built to support wayland. It's the Xwayland translation layer they're talking about here, which (I

by pfooti 9y ago

this isn't "no plans to support wayland" - these drivers are built to support wayland. It's the Xwayland translation layer they're talking about here, which (I think - my understanding is a bit thin here) is for running applications that are compiled to use X11 graphics in a wayland environment. So: it could well be that this is an issue of resource allocation more than anything else. Over time, most applications should move to using wayland (or whatever window / surface library emerges as the clear winner, but that looks like wayland is the future here) for their graphics. A lot of effort into supporting Xwayland would mean work spent on a library that should be of limited utility - only useful during the transition between platforms (like the old carbon layer for OSX in the early 10.0, 10.1 days). Right? Or maybe I'm misreading it.

ollien 9y ago
From what I read on reddit, Xwayland is X running within wayland, and (for some reason) needs some special code in the drivers. I'm not fully clear as to why or what needs to change.
- majewsky 9y ago
  The motivation for Xwayland is that 1. a lot of applications use no GUI frameworks (or outdated versions thereof, e.g. all these apps that are still on Qt 4), so if the frameworks are ported to Wayland, it doesn't help them. And 2. a lot of applications talk to X directly even if using a framework (e.g. an application that takes a screenshot needs to use xlib or xcb directly because that's typically not abstracted by a GUI framework). Xwayland enables these types of applications to continue working in a Wayland session, so that desktops and distributions can move to Wayland without having to either wait on the legacy applications or remove them from the distribution.
  - d33 9y ago
    Couldn't those just be recompiled with a wrapper that maps X calls to Wayland?
    - josteink 9y ago
      You mean like xwayland?
      - lotyrin 9y ago
        AFAICT XWayland is a server that speaks the X protocol and not an Xlib replacement compatibility layer that emulates X11 client+server in-process and speaks Wayland protocol (though, I imagine various mismatches prevents that sort of thing from working well at all).

by pfooti 9y ago

ollien 9y ago

From what I read on reddit, Xwayland is X running within wayland, and (for some reason) needs some special code in the drivers. I'm not fully clear as to why or what needs to change.

majewsky 9y ago
The motivation for Xwayland is that 1. a lot of applications use no GUI frameworks (or outdated versions thereof, e.g. all these apps that are still on Qt 4), so if the frameworks are ported to Wayland, it doesn't help them. And 2. a lot of applications talk to X directly even if using a framework (e.g. an application that takes a screenshot needs to use xlib or xcb directly because that's typically not abstracted by a GUI framework). Xwayland enables these types of applications to continue working in a Wayland session, so that desktops and distributions can move to Wayland without having to either wait on the legacy applications or remove them from the distribution.
- d33 9y ago
  Couldn't those just be recompiled with a wrapper that maps X calls to Wayland?
  - josteink 9y ago
    You mean like xwayland?
    - lotyrin 9y ago
      AFAICT XWayland is a server that speaks the X protocol and not an Xlib replacement compatibility layer that emulates X11 client+server in-process and speaks Wayland protocol (though, I imagine various mismatches prevents that sort of thing from working well at all).