6 ms·

I wonder if there are plans to make it work with X11 in the future, I've yet to see the benefit of trying to switch to Wayland on my desktop, it just doesn't wo

by diath 3y ago

I wonder if there are plans to make it work with X11 in the future, I've yet to see the benefit of trying to switch to Wayland on my desktop, it just doesn't work as-is the way my 8 year old setup works.

knocte 3y ago
I doubt they have the energy to backport bleeding edge tech.
PlutoIsAPlanet 3y ago
This is one of the benefits of the Wayland protocol over X, being able to do this kind of thing relatively straightforwardly. Once support for hardware planes becomes more common in Wayland compositors, this can be tied to ultimately allow no-copy rendering to the display for non-fullscreen applications, which for video playback (incl. likes of Youtube) equals to reduced CPU & GPU usage and less power draw, as well as reduced latency.
- AshamedCaptain 3y ago
  > This is one of the benefits of the Wayland protocol over X What. The original design of X actually encouraged a separate surface / Window for each single widget on your UI. This was actually removed in Gtk+3 ("windowless widgets"). And now they are bringing it back just for wayland ("subsurfaces"). As far as I can read, it is practically the same concept.
  - tadfisher 3y ago
    The original design of X had clients send drawing commands to the X server, basically treating the server as a remote Cairo/Skia-like 2D rasterizer, and subwindows were a cheap way to avoid pixel-level damage calculations. This was obviated in the common case by the Xdamage extension. Later use of windows as a rendering surface for shared client/server buffers was added with Xshm, then for device video buffers with Xv. GTK3 got rid of windowed widgets because Keith Packard introduced the Xrender extension, which basically added 2D compositing to X, which was the last remaining use for subwindows for every widget.
    - AshamedCaptain 3y ago
      This is completely wrong. Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your rendering & event handling code with offsets and clip regions and the like). The excuse that was used when introducing windowless widgets is to reduce tearing/noise during resizing, as Gtk+ had trouble synchronizing the resizing of all the windows at the same time.
      - play_ac 3y ago
        >Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). Yes, that's the point. When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. >You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your code with offsets and clip regions and the like). No, you still had to have offsets and clip regions before too because the client still had to set and update those. And it was more complicated because when you made a sub-window every single bit of state like that had to be synchronized with the X server and repeatedly copied over the wire. With client-side rendering everything is simply stored in the client and never has to deal with that problem.
        AshamedCaptain 3y ago
        > When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. There is, or we would not be having subsurfaces on Wayland or this entire discussion in the first place. Are you seriously arguing that the only reason to using windows in Xorg is to have composition? People were using Xshape/Xmisc and the like to handle the lack of alpha channels in the core protocol? This is not what I remember. I would be surprised if Xshape even worked on non-top level windows. heck, even MOTIF had windowless widgets (called gadgets iirc), and the purpose most definitely was not composition-related.
hurryer 3y ago
No screen tearing is a major benefit of using a compositor.
- mrob 3y ago
  And screen tearing is a major benefit of not using a compositor. There's an unavoidable tradeoff between image quality and latency. Neither is objectively better than the other. Xorg has the unique advantage that you can easily switch between them by changing the TearFree setting with xrandr.
  - RVuRnvbM2e 3y ago
    It's not unique. Wayland has a tearing protocol. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/tearing-control?ref_type=heads https://gitlab.freedesktop.org/wayland/wayland-protocols/-/t...
    - mrob 3y ago
      This is something that every application has to opt in to individually. It's not a global setting like TearFree.
      - RVuRnvbM2e 3y ago
        This is just untrue.
        mrob 3y ago
        From the XML file that describes the protocol: "This global is a factory interface, allowing clients to inform which type of presentation the content of their surfaces is suitable for." Note that "global" refers to the interface, not the setting. Which Wayland compositor has the equivalent feature of "xrandr --output [name] --set TearFree off"?
      - kaba0 3y ago
        Which is the correct default? No application should unknowingly render half-ready frames, that’s stupid. The few niches where it makes sense (games, 3D applications) can opt into it, and do their own thing.
maccard 3y ago
> I've yet to see the benefit of trying to switch to Wayland on my desktop how about Graphics Offload?
- diath 3y ago
  This feature would be nice-to-have but is not impactful enough (at least to me) to outweigh the cons of having to switch to Wayland, which would include migrating my DE and getting accustomed to it as well as looking for replacement applications for these that do not work properly with Wayland (most notably ones that deal with global keyboard hooks). Admittedly I have never tried XWayland which I think could potentially solve some of these issues.
  - maccard 3y ago
    I think if your waiting for a magic bullet of a feature to upgrade you might be waiting a long time, and even Wayland will be replaced at that point. Instead, look at the combination of features (like this) and think about it and future upgrades. I think you're right that xwayland is probably a compromise for now if you need it for things like global shortcuts.
mnd999 3y ago
If it worked exactly the same there would indeed be no benefit. If you’re happy with that you have then there’s no reason to switch.
aktuel 3y ago
I am sorry to tell you that X11 is completely unmaintained by now. So the chances of that happening are zero.
- NGRhodes 3y ago
  FYI 21.1.9 was released less than a month ago (https://lists.x.org/archives/xorg/2023-October/061515.html https://lists.x.org/archives/xorg/2023-October/061515.html), they are still fixing bugs.
  - dralley 3y ago
    You mean, they're still fixing critical CVEs.
    - badsectoracula 3y ago
      Which are still bugs. Also only two of the four changes mentioned in the mail are about CVEs.
AshamedCaptain 3y ago
Frankly, it was X11 which introduced "Graphics Offload" in the first place, with stuff like XV, chroma keying, and hardware overlays. Then compositors came and we moved to texture_from_surface extensions and uploading things into GPUs. This is just the eternal wheel of reinventing things in computing (TM) doing yet another iteration and unlikely to give any tangible benefits over the situation from decades ago.
- play_ac 3y ago
  No, nothing like this exists in X11. Xorg still doesn't really have support for non-RGB surfaces. DRI3 gets you part of the way there for attaching GPU buffers but the way surfaces work would have to be overhauled to work more like Wayland, where they can be any format supported by the GPU. There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would. Yes, you're technically right that this would have been possible years ago but it wasn't actually ever done, because X11 never had the ability to do it at the same time as using compositing.
  - AshamedCaptain 3y ago
    > Xorg still doesn't really have support for non-RGB surfaces You really need to add context to these statements, because _right now_ I am using through Xorg a program which uses a frigging colormap, which is as non-RGB as it gets. The entire reason Xlib has this "WhitePixel" and XGetPixel and XYPixmap and other useless functions which normally fetch a lot of ire is because it tries to go out of its way to support practically other-wordly color visuals and image formats. If anything, I'd say it is precisely RGB which has the most problems with X11, specially when you go more than 24bpp. > there for attaching GPU buffers None of this is about the GPU, but about about directly presenting images for _hardware_ composition using direct scan-out, hardware layers or not. Exactly what Xv is about, and the reason Xv supports formats like YUV. > There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would As if that prevented any of the extensions done to X11 in the last three decades, including Xv.
audidude 3y ago
This would require protocol changes for X11 at best, and nobody is adding new protocols. Especially when nobody does Drawable of Drawables anymore and all use client-side drawing with Xshm. You need to dynamically change stacking of subsurfaces on a per-frame basis when doing the CRTC.
- AshamedCaptain 3y ago
  I really don't see why it would need a new protocol. You can change stacking of "subsurfaces" in the traditional X11 fashion and you can most definitely do "drawables of drawables". At the very least I'd bet most clients still create a separate window for video content. I agree though it would require a lot of changes to the server and no one is in the mood (like, dynamically decide whether I composite this window or push it to a Xv port or hardware plane? practically inconceivable in the current graphics stack, albeit it is not a technical X limitation per-se). This entire feature is also going to be pretty pointless in Wayland desktop space either way because no one is in the mood either -- your dmabufs are going to end up in the GPU anyway for the foreseeable future, just because of the complexity of liftoff, variability of GPUs, and the like.
  - audidude 3y ago
    > I really don't see why it would need a new protocol. You'll need API to remap the Drawable to the scanout plane from a compositor on a per-frame basis (so when submitting the CRTC) and the compositor isn't in control of the CRTC. So...
    - AshamedCaptain 3y ago
      This assumes it would be the role of the window manager or compositor rather than the server who decides that, which I didn't think that way. But I guess it'd make sense (policy vs mechanism). "per-frame basis" I don't see why and it just mirrors Wayland concepts. Still, as protocols go, it's quite a minor change, and one applications don't necessarily have to support.
kelnos 3y ago
I would very much doubt it. This would likely require work on Xorg itself (a new protocol extension, maybe; I don't believe X11 supports anything but RGB, [+A, with XRender] for windows, and you'd probably need YUV support for this to be useful), which no one seems to care to do. And the GTK developers seem to see their X11 windowing backend as legacy code that they want to remove as soon as they can do so without getting too many complaints.

by diath 3y ago

knocte 3y ago

I doubt they have the energy to backport bleeding edge tech.

PlutoIsAPlanet 3y ago

This is one of the benefits of the Wayland protocol over X, being able to do this kind of thing relatively straightforwardly. Once support for hardware planes becomes more common in Wayland compositors, this can be tied to ultimately allow no-copy rendering to the display for non-fullscreen applications, which for video playback (incl. likes of Youtube) equals to reduced CPU & GPU usage and less power draw, as well as reduced latency.

AshamedCaptain 3y ago
> This is one of the benefits of the Wayland protocol over X What. The original design of X actually encouraged a separate surface / Window for each single widget on your UI. This was actually removed in Gtk+3 ("windowless widgets"). And now they are bringing it back just for wayland ("subsurfaces"). As far as I can read, it is practically the same concept.
- tadfisher 3y ago
  The original design of X had clients send drawing commands to the X server, basically treating the server as a remote Cairo/Skia-like 2D rasterizer, and subwindows were a cheap way to avoid pixel-level damage calculations. This was obviated in the common case by the Xdamage extension. Later use of windows as a rendering surface for shared client/server buffers was added with Xshm, then for device video buffers with Xv. GTK3 got rid of windowed widgets because Keith Packard introduced the Xrender extension, which basically added 2D compositing to X, which was the last remaining use for subwindows for every widget.
  - AshamedCaptain 3y ago
    This is completely wrong. Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your rendering & event handling code with offsets and clip regions and the like). The excuse that was used when introducing windowless widgets is to reduce tearing/noise during resizing, as Gtk+ had trouble synchronizing the resizing of all the windows at the same time.
    - play_ac 3y ago
      >Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). Yes, that's the point. When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. >You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your code with offsets and clip regions and the like). No, you still had to have offsets and clip regions before too because the client still had to set and update those. And it was more complicated because when you made a sub-window every single bit of state like that had to be synchronized with the X server and repeatedly copied over the wire. With client-side rendering everything is simply stored in the client and never has to deal with that problem.
      - AshamedCaptain 3y ago
        > When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. There is, or we would not be having subsurfaces on Wayland or this entire discussion in the first place. Are you seriously arguing that the only reason to using windows in Xorg is to have composition? People were using Xshape/Xmisc and the like to handle the lack of alpha channels in the core protocol? This is not what I remember. I would be surprised if Xshape even worked on non-top level windows. heck, even MOTIF had windowless widgets (called gadgets iirc), and the purpose most definitely was not composition-related.

hurryer 3y ago

No screen tearing is a major benefit of using a compositor.

mrob 3y ago
And screen tearing is a major benefit of not using a compositor. There's an unavoidable tradeoff between image quality and latency. Neither is objectively better than the other. Xorg has the unique advantage that you can easily switch between them by changing the TearFree setting with xrandr.
- RVuRnvbM2e 3y ago
  It's not unique. Wayland has a tearing protocol. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/tearing-control?ref_type=heads https://gitlab.freedesktop.org/wayland/wayland-protocols/-/t...
  - mrob 3y ago
    This is something that every application has to opt in to individually. It's not a global setting like TearFree.
    - RVuRnvbM2e 3y ago
      This is just untrue.
      - mrob 3y ago
        From the XML file that describes the protocol: "This global is a factory interface, allowing clients to inform which type of presentation the content of their surfaces is suitable for." Note that "global" refers to the interface, not the setting. Which Wayland compositor has the equivalent feature of "xrandr --output [name] --set TearFree off"?
    - kaba0 3y ago
      Which is the correct default? No application should unknowingly render half-ready frames, that’s stupid. The few niches where it makes sense (games, 3D applications) can opt into it, and do their own thing.

maccard 3y ago

> I've yet to see the benefit of trying to switch to Wayland on my desktop how about Graphics Offload?

diath 3y ago
This feature would be nice-to-have but is not impactful enough (at least to me) to outweigh the cons of having to switch to Wayland, which would include migrating my DE and getting accustomed to it as well as looking for replacement applications for these that do not work properly with Wayland (most notably ones that deal with global keyboard hooks). Admittedly I have never tried XWayland which I think could potentially solve some of these issues.
- maccard 3y ago
  I think if your waiting for a magic bullet of a feature to upgrade you might be waiting a long time, and even Wayland will be replaced at that point. Instead, look at the combination of features (like this) and think about it and future upgrades. I think you're right that xwayland is probably a compromise for now if you need it for things like global shortcuts.

mnd999 3y ago

If it worked exactly the same there would indeed be no benefit. If you’re happy with that you have then there’s no reason to switch.

aktuel 3y ago

I am sorry to tell you that X11 is completely unmaintained by now. So the chances of that happening are zero.

NGRhodes 3y ago
FYI 21.1.9 was released less than a month ago (https://lists.x.org/archives/xorg/2023-October/061515.html https://lists.x.org/archives/xorg/2023-October/061515.html), they are still fixing bugs.
- dralley 3y ago
  You mean, they're still fixing critical CVEs.
  - badsectoracula 3y ago
    Which are still bugs. Also only two of the four changes mentioned in the mail are about CVEs.

AshamedCaptain 3y ago

Frankly, it was X11 which introduced "Graphics Offload" in the first place, with stuff like XV, chroma keying, and hardware overlays. Then compositors came and we moved to texture_from_surface extensions and uploading things into GPUs. This is just the eternal wheel of reinventing things in computing (TM) doing yet another iteration and unlikely to give any tangible benefits over the situation from decades ago.

play_ac 3y ago
No, nothing like this exists in X11. Xorg still doesn't really have support for non-RGB surfaces. DRI3 gets you part of the way there for attaching GPU buffers but the way surfaces work would have to be overhauled to work more like Wayland, where they can be any format supported by the GPU. There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would. Yes, you're technically right that this would have been possible years ago but it wasn't actually ever done, because X11 never had the ability to do it at the same time as using compositing.
- AshamedCaptain 3y ago
  > Xorg still doesn't really have support for non-RGB surfaces You really need to add context to these statements, because _right now_ I am using through Xorg a program which uses a frigging colormap, which is as non-RGB as it gets. The entire reason Xlib has this "WhitePixel" and XGetPixel and XYPixmap and other useless functions which normally fetch a lot of ire is because it tries to go out of its way to support practically other-wordly color visuals and image formats. If anything, I'd say it is precisely RGB which has the most problems with X11, specially when you go more than 24bpp. > there for attaching GPU buffers None of this is about the GPU, but about about directly presenting images for _hardware_ composition using direct scan-out, hardware layers or not. Exactly what Xv is about, and the reason Xv supports formats like YUV. > There isn't any incentive to implement this in X11 either because X11 is supposed to work over the network and none of this stuff would As if that prevented any of the extensions done to X11 in the last three decades, including Xv.

audidude 3y ago

This would require protocol changes for X11 at best, and nobody is adding new protocols. Especially when nobody does Drawable of Drawables anymore and all use client-side drawing with Xshm. You need to dynamically change stacking of subsurfaces on a per-frame basis when doing the CRTC.

AshamedCaptain 3y ago
I really don't see why it would need a new protocol. You can change stacking of "subsurfaces" in the traditional X11 fashion and you can most definitely do "drawables of drawables". At the very least I'd bet most clients still create a separate window for video content. I agree though it would require a lot of changes to the server and no one is in the mood (like, dynamically decide whether I composite this window or push it to a Xv port or hardware plane? practically inconceivable in the current graphics stack, albeit it is not a technical X limitation per-se). This entire feature is also going to be pretty pointless in Wayland desktop space either way because no one is in the mood either -- your dmabufs are going to end up in the GPU anyway for the foreseeable future, just because of the complexity of liftoff, variability of GPUs, and the like.
- audidude 3y ago
  > I really don't see why it would need a new protocol. You'll need API to remap the Drawable to the scanout plane from a compositor on a per-frame basis (so when submitting the CRTC) and the compositor isn't in control of the CRTC. So...
  - AshamedCaptain 3y ago
    This assumes it would be the role of the window manager or compositor rather than the server who decides that, which I didn't think that way. But I guess it'd make sense (policy vs mechanism). "per-frame basis" I don't see why and it just mirrors Wayland concepts. Still, as protocols go, it's quite a minor change, and one applications don't necessarily have to support.

kelnos 3y ago

I would very much doubt it. This would likely require work on Xorg itself (a new protocol extension, maybe; I don't believe X11 supports anything but RGB, [+A, with XRender] for windows, and you'd probably need YUV support for this to be useful), which no one seems to care to do. And the GTK developers seem to see their X11 windowing backend as legacy code that they want to remove as soon as they can do so without getting too many complaints.