Basic API usage

[Jan Bruns]

Pekka Paalanen wrote:

 >> The Vk implementation as well as the application instanciating the Vk
 >> would then both be free to choose whatever implementation to talk
 >> wayland protocol.

 > Ok, yeah, you could invent something like that, but how do you then
 > guarantee the strict message ordering requirements that Wayland
 > protocol relies on.

Well, this example protocol of course isn't discussed throughly, yet.

It yet just served as some example to roughly outline theoretically 
possible future core protocol contents of wayland. To answer your 
question about how there could be some wayland-only, 
non-API-implementation specific way:

 >>> I cannot guess what you are thinking here. If Vulkan didn't use
 >>> actually implemented types from *some* Wayland implementation in its
 >>> API, what could it use?

But of course, details about that example are also an interesting topic.

 > Take for example EGL's eglSwapBuffers(). That function is required to
 > issue wl_surface.commit exactly once on the wl_surface associated with
 > the EGLSurface before it returns. With that guarantee, applications can
 > put window state changes and more into the exact same commit, which is
 > required for both avoiding glitches and in some cases also for message
 > sequence correctness. An incorrect sequence may result in a protocol
 > error, which disconnects the client.

 > If you send two requests through two different Wayland connections,
 > there is no guarantee whatsoever on which one a compositor will
 > process first.

Of course.

However, forcing applications to even let third party code reuse their 
wayland connection also doesn't prevent applications from doing things 
wrong.

 > I didn't even touch the issue of allocating object IDs yet.

What kind of issue are you talking about?

 > I think the trade-off is not worth it.

I didn't notice you mentioned a trade-off.

 > No, designing Wayland so that you could use multiple different
 > implementations in one process to talk through the same Wayland
 > connection and mix and match those freely message by message was never
 > a goal.

Having this said, and given the situation that there are quite a few 
APIs that wanna talk wayland on behalf of applications, combined with a 
lack of a core protocol like the example I've given, wayland actually 
frequently binds applications to use libwayland, a heavy bunch of 
possible inappropriateness.

 > I'm sure there already are from-scratch Wayland implementations, and
 > they are interoperable with libwayland on the other side of the process
 > boundary. ISTR there are also Wayland debugging tools that do not use
 > libwayland as the interface wasn't a good fit for a pass-through proxy.

So libwayland probably isn't always the best possible choice to talk 
wayland.

Do you BTW think it is a very good choice for dealing with very dynamic 
content? For example, think of browsers, probably considering to let X11 
or wayland do parts of their job? For example, it has a hardcoded way of 
dealing with objects infered from wayland-talking, and doesn't even seem 
to be very communicative about that management (I even didn't notice 
some notification-sheme about object deletion).

 > I think there is nothing more I can give you. Wayland is not what you
 > imagined or wished for.

Nobody knows what the future is.

Thanks.

Gruss

Jan Bruns