4 ms·

> we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11

> we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning

worthless-trash 3y ago
I read this as "Please report bugs early in the RHEL 10 lifecycle so it can get fixed".
flohofwoe 3y ago
Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point. Why don't they simply accept that some programs will never be ported to native Wayland APIs since Wayland implementations don't offer required features for some types of programs (like universal support for rendering consistent window decorations). With XWayland, X11 is just another client-side window system API, why not simply support that forever and why should it matter for application developers what happens below the X11 API shim? Especially since it is more feature complete and much less hassle than writing code directly against Wayland APIs?
- m4rtink 3y ago
  Well, someone would still have to maintain a huge chunk of X indefinitely for that to work. :P
  - flohofwoe 3y ago
    It can't be much more than a thin "translation layer" on top of Wayland similar to how xcb or xlib are two different flavours of the same thing right? The most important feature of XWayland is that it knows how to render the window chrome so that it looks consistent with other apps.
    - bitwize 3y ago
      It's basically all of Xorg except the low-level graphics card driver bits. Xorg tracks a lot of state, there is no "thin wrapper" for that chonky protocol.
      - flohofwoe 3y ago
        Ok then I have another grand idea: a system-level libwayland dynamic link library which eases the pain of using the native Wayland APIs. No stupid code-generated headers, no extension mess, just a plain and simple widget-framework-agnostic C API in a single header and library to create a window with a titlebar and resizing handles (which needs to look the same as other windows on that system, no matter if Gnome, KDE or anything else is used), a hook for receiving input events, programmatic control over window position and size, being able to switch between fullscreen and windowed mode and being able to query the display DPI and refresh rate (that's the super-luxus requirements list which would make that API better than most alternatives including X11). Basically enough window system glue to create a window for housing a GL or Vulkan context, but nothing more. If this library existed and would be guaranteed to exist on each and every desktop Linux installation, I would switch in 30 minutes (it shouldn't take longer to port my code over). TL;DR: I don't care about the technical details on why X11 is better or worse than Wayland. I only know that X11 provides the required features for my use case, but Wayland doesn't (which is mainly: not having to deal with rendering window chrome that's consistent with the rest of the system, and without having to bring a widget framework like Qt or GTK into the mix - which doesn't make sense if all I need is a 3D rendering context spanning the entire window client area).
        bitwize 3y ago
        libSDL2 exists and is pretty much everywhere, dude.
        flohofwoe 3y ago
        Can SDL2 render proper client side decorations on Wayland by now that look identical with the rest of the system? Last I checked it couldn't because libdecor couldn't. But googling again it looks like libdecor has special GTK support since quite recently, so maybe the problem has actually been solved (I would be surprised though, because nothing else in the Wayland ecosystem seems to "just work").
- bitwize 3y ago
  > Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point. Astronaut 2: Always did. Keeping the jank of X11 around was never long-term viable. One day you will have to either switch to Wayland-capable apps or sandbox whatever last version of Xwayland is out there to keep whatever old app you have going.
  - ehvatum 3y ago
    > Keeping the jank of X11 around was never long-term viable Ha, it’s like saying “keeping the jank of win32, directx, GDI was never long-term viable” as your one and only argument for the inevitable success of Windows RT. Fools, the lot of you GUI hipsters.
    - eikenberry 3y ago
      But unlike Windows we can go ahead and do this if we want as we control our own systems instead of delegating control to a corporation. IE. I'll ditch X11 compatibility as soon as is feasible for me and it doesn't really matter if someone else keeps it around. That's on them.
- creatonez 3y ago
  You could speculate on the wording, but there is currently no such plan to drop Xwayland in the upstream Xorg project. In fact, one of the maintainers seems to be enthusiastic about continuing to maintain it for a very long time, now that the workload won't be eaten up by xserver (https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...)

worthless-trash 3y ago

I read this as "Please report bugs early in the RHEL 10 lifecycle so it can get fixed".

flohofwoe 3y ago

Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point. Why don't they simply accept that some programs will never be ported to native Wayland APIs since Wayland implementations don't offer required features for some types of programs (like universal support for rendering consistent window decorations). With XWayland, X11 is just another client-side window system API, why not simply support that forever and why should it matter for application developers what happens below the X11 API shim? Especially since it is more feature complete and much less hassle than writing code directly against Wayland APIs?

m4rtink 3y ago
Well, someone would still have to maintain a huge chunk of X indefinitely for that to work. :P
- flohofwoe 3y ago
  It can't be much more than a thin "translation layer" on top of Wayland similar to how xcb or xlib are two different flavours of the same thing right? The most important feature of XWayland is that it knows how to render the window chrome so that it looks consistent with other apps.
  - bitwize 3y ago
    It's basically all of Xorg except the low-level graphics card driver bits. Xorg tracks a lot of state, there is no "thin wrapper" for that chonky protocol.
    - flohofwoe 3y ago
      Ok then I have another grand idea: a system-level libwayland dynamic link library which eases the pain of using the native Wayland APIs. No stupid code-generated headers, no extension mess, just a plain and simple widget-framework-agnostic C API in a single header and library to create a window with a titlebar and resizing handles (which needs to look the same as other windows on that system, no matter if Gnome, KDE or anything else is used), a hook for receiving input events, programmatic control over window position and size, being able to switch between fullscreen and windowed mode and being able to query the display DPI and refresh rate (that's the super-luxus requirements list which would make that API better than most alternatives including X11). Basically enough window system glue to create a window for housing a GL or Vulkan context, but nothing more. If this library existed and would be guaranteed to exist on each and every desktop Linux installation, I would switch in 30 minutes (it shouldn't take longer to port my code over). TL;DR: I don't care about the technical details on why X11 is better or worse than Wayland. I only know that X11 provides the required features for my use case, but Wayland doesn't (which is mainly: not having to deal with rendering window chrome that's consistent with the rest of the system, and without having to bring a widget framework like Qt or GTK into the mix - which doesn't make sense if all I need is a 3D rendering context spanning the entire window client area).
      - bitwize 3y ago
        libSDL2 exists and is pretty much everywhere, dude.
        flohofwoe 3y ago
        Can SDL2 render proper client side decorations on Wayland by now that look identical with the rest of the system? Last I checked it couldn't because libdecor couldn't. But googling again it looks like libdecor has special GTK support since quite recently, so maybe the problem has actually been solved (I would be surprised though, because nothing else in the Wayland ecosystem seems to "just work").
bitwize 3y ago
> Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point. Astronaut 2: Always did. Keeping the jank of X11 around was never long-term viable. One day you will have to either switch to Wayland-capable apps or sandbox whatever last version of Xwayland is out there to keep whatever old app you have going.
- ehvatum 3y ago
  > Keeping the jank of X11 around was never long-term viable Ha, it’s like saying “keeping the jank of win32, directx, GDI was never long-term viable” as your one and only argument for the inevitable success of Windows RT. Fools, the lot of you GUI hipsters.
  - eikenberry 3y ago
    But unlike Windows we can go ahead and do this if we want as we control our own systems instead of delegating control to a corporation. IE. I'll ditch X11 compatibility as soon as is feasible for me and it doesn't really matter if someone else keeps it around. That's on them.
creatonez 3y ago
You could speculate on the wording, but there is currently no such plan to drop Xwayland in the upstream Xorg project. In fact, one of the maintainers seems to be enthusiastic about continuing to maintain it for a very long time, now that the workload won't be eaten up by xserver (https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...)