Call for Discussion : New Project to support the Wayland display server on Linux
philip.race at oracle.com
Thu Jul 8 17:14:14 UTC 2021
And I think the first phase of the project needs to be an investigation
of the alternatives
and consideration of how well it matches all the requirements.
I would not want to see a "code first, figure it out later" approach.
Significant documentation and justification of the options and reasons
for choices is required.
Even with the much simpler "Metal" pipeline for macOS we had to spend
time deciding if
we'd use MetalKit or the lower level Metal APIs and the latter is what
we found we needed.
Very often it seems if you are writing a platform you end up needing to
go for the lower level
Not saying that's where we'll end up here, but it all needs to be
thought through and written down
It seems a wayland compositor needs to work on "non-desktop" machines.
Think all those millions of rack mounted boxes with minimal graphics
sitting in data centres.
So it can't be fully "accelerated graphics or nothing"
2D has s/w loops for everything already so can work in that world and it may
be that a GTK port can end up doing *most* things we need but it has to
do *all* the things we need
Options to investigate include (at least) :
and then we have to see how the rendering side of it (2D) fits with the
On 7/8/21 9:11 AM, Mario Torre wrote:
> What I would like to do however is to see if it makes sense to create
> a GTK toolkit rather than a Wayland one, and let GTK deal with every
> abstraction. We can be pretty confident that GTK will always be there,
> and will work on X11 and Wayland transparently, so even a user on a
> pure KDE desktop won’t really need to deal directly with Wayland.
More information about the discuss