Project Direction: Maintenance, Breaking Evolution, or Both?

[moolight-seashell]

Hi, and first of all — thank you for launching this project.
It's refreshing to see an effort to revive X11 in a landscape where development has become increasingly fragmented and inaccessible for small teams or solo developers.

After spending time exploring Wayland, I was honestly very unpleasantly surprised by its overall design:
the need to reimplement almost everything per project, the fragmentation, the lack of a solid central reference implementation, the high barrier to entry for building compositors, and the poor modularity.
in short, an anti-community project
In that context, Xlibre seems like a much more promising and grounded approach.

That said, I’d like to ask:
What is Xlibre’s long-term direction?

• A cleaned-up, stable Xorg fork focused on bugfixes and long-term backward compatibility?
• A modernized evolution, willing to break compatibility to enable better design and new features?
• A hybrid path, perhaps maintaining an Xorg-compatible branch alongside a more experimental, incompatible “X12” branch to explore long-overdue breaking improvements?
• another way ?

And more broadly:
What are the project's theoretical or strategic priorities?

Clarifying this would likely help both individuals and distributions understand the purpose of the project
and decide whether they can adopt it, rely on it, or contribute to it.

Looking forward to the discussion!

[metux]

A cleaned-up, stable Xorg fork focused on bugfixes and long-term backward compatibility?

Yes.

A modernized evolution,

Yes.

willing to break compatibility to enable better design and new features?

We don't need to break compatibility for new features. So, no.

A hybrid path, perhaps maintaining an Xorg-compatible branch alongside a more experimental,
incompatible “X12” branch to explore long-overdue breaking improvements?

Big changes (with huge risk of breaks) might go to some experimental tree first. But we won't break the protocol.
Compatibility is one of the major goals.

If I wanted to break compatibility, I could have forked Wayland or Mir.

[lorn10]

In view of some recent developments in Mesa it might make sense to have at some point two X11Libre branches, one for the future and the other which targets the past. 🤔

This would allow X11Libre to be somehow two-directional. The "modern" branch would be the place of the main development while the other one would focus primary on the compatibility even to old and super-old stuff like the 3Dfx Voodoo GPU series "and friends" from the 90s.

I mention this here especially in the context of the "zink" Gallium driver development in Mesa. Unfortunately those zink related refactorings are breaking quite often the older Gallium drivers. This then not only leads to frustrated end-users (like me) but also to frustrated developers. In some way it can be said that the last "victim" of this new versus old conflict was the D3D9 API implementation in Mesa called Gallium Nine.

As a result I have asked on Mesa for some sort of "separation" between old and new. In principle, this would simplify any zink refactoring and it would remove the pressure regarding the maintainance of older stuff. Unfortunately such a move needs maintainers, so people who are willing to support it. More context can be found here:

https://gitlab.freedesktop.org/mesa/mesa/-/issues/12789

[moolight-seashell]

Okay, thanks, that's very clear.
I was pretty sure that most of the missing features weren't present because of the incomatibility with the api.

[metux]

I was pretty sure that most of the missing features weren't present because of the incomatibility with the api.

Haven't seen a single requested feature that really requires breaking the protocol, instead of just extending it. Not even things like HDR.