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 to a Wayland ecosystem. With this, we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. The result of this evaluation is that, while there are still some gaps and applications that need some level of adaptation, we believe the Wayland infrastructure and ecosystem are in good shape, and that we’re on a good path for the identified blockers to be resolved by the time RHEL 10 is out, planned to be released on the first half of 2025. Earlier this year (2023), as part of our RHEL 10 planning, we made a study to understand Wayland’s status, not only from an infrastructure perspective, but also from an ecosystem perspective. This effort gave us the confidence to first make Wayland default for most use cases in RHEL 8, followed up with the deprecating of Xorg server in RHEL 9, with the intention of its removal in a future release. We want to recognize the significant effort all these organizations and individuals have made, especially the rest of the upstream community, without whom this project would never be so mature. And dozens of other initiatives from the past and newer ones that are coming in the near future.Co-led the Wakefield initiative to make OpenJDK work with (X)Wayland. Created Libei to provide a solution for input emulation and capture.Review and development for explicit sync support in the Wayland protocol and relevant projects.Developing infrastructure to support modern remote desktop solutions. Leading Xwayland as the cornerstone for backwards compatibility with X11 clients.Leading parts of the effort to support High Dynamic Range (HDR)/color management.I’m really proud of the work we’ve done, this includes efforts such as: This has become a difficult situation to sustain.Īs Wayland has advanced and become more capable, we’ve worked upstream and internally with multiple hardware vendors, software vendors, customers, the visual effects (VFX) industry and upstream projects to understand and develop the necessary projects to close the feature gap and even expand on the Wayland stack. While it is great that Wayland has been greatly enhanced, it does mean there’s an increased maintenance burden in both stacks, with lots of new work to maintain in Wayland and lots of older, legacy work to maintain in X.org. That being said, the community has been building new features and addressing gaps in Wayland, while new development in the Xorg server and X11 infrastructure have been winding down. This splits the time we and the upstream community have available to support new features, and for fixing bugs. Through this transition, Red Hat has been supporting both the X.org and Wayland stacks. Today, Wayland has been recognized as the de-facto windowing and display infrastructure solution. Over time, it became clear that the X11 protocol and the Xorg server had fundamental issues that needed to be addressed, and Wayland was the solution. The transition from the now 30+ year old X Window System to the newer Wayland-based stack has been happening for the past 15 or so years, and Red Hat has been involved from the start. I want to provide you with the context, and explain the efforts we made in coming to this decision. Hi everyone, I’m part of the Engineering and Product group focused on graphical display and GPUs for Red Hat Enterprise Linux (RHEL), and I want to communicate a product and engineering decision we’ve recently made.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |