Call for Discussion : New Project to support the Wayland display server on Linux

[Philip Race]

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) :

- GTK
- EGL
- Vulkan
-Software rendering

and then we have to see how the rendering side of it (2D) fits with the 
AWT part.

-phil.

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.