Basic API usage

[Pekka Paalanen]

On Tue, 15 Sep 2020 15:31:40 +0200
Jan Bruns <code at abnuto.de> wrote:

> Pekka Paalanen wrote:
> 
>  >> What I can tell about wl now is that I haven't yet identified lines of
>  >> text or code about it, that might probably be of not so much relevance,
>  >> given specific sets of workflows. That's bad news to me, a
>  >> disappointment, because making things easier for the distant future was
>  >> my only motivation for focussing on wl a bit.  
>  >
>  > Sorry, but I do not understand what you are talking about. If your goal
>  > is not to write a program that uses Wayland in your preferred language,
>  > then what is it?
>  >
>  > What workflow are you referring to?  
> 
> Well, why was it almost necessary to ask this mailing list about basic 
> API usage?

Hi,

I would think that writing language bindings for libwayland that does
not already have any bindings for the target language is quite an
advanced use case. After all, you won't be using the normal libwayland
API, but you have to use the low-level API and write a code generator
that suits your target language while using the low-level API
correctly. You have to understand precisely how the XML definitions are
turned into concepts on the wire, which is something you'd never care
about if you used the ready-made C or other language bindings.

That is definitely not something I would recommend anyone starting to
learn Wayland to begin from. You get hit by the full complexity and
historical baggage all at once.

Even the normal libwayland API is considered something mostly for
toolkit developers. Wayland itself is a fairly low-level protocol. You
need quite a lot of "meat" around it in a client to have it actually
show a window.

Writing a full Wayland protocol marshalling implementation in a new
language from scratch is also an advanced topic in my mind. You don't
need to really know the libwayland low-level API, but you need even
more knowledge about how the XML maps to data on the wire and how
object IDs are managed. Again you would need to know none of that if
you were to use ready-made language bindings.

I don't see anything "basic" in what I understood that you aimed to do:
use Wayland from a language that has no (I assume) prior art on Wayland.

> For example, the vulkan API claims to support a "wayland" interface. 
> Great words, relative to the situation the protocol probably doesn't yet 
> deliver the functionality required to fulfill that claim. What that 
> mentioned interface really is about is called libwayland. But what 
> happens if the wayland protocol gets to the point of supporting the 
> claim directly, without libwayland interaction?

What do you mean by all that?

> Would they introduce 
> structures named like
> 
> VK_STRUCTURE_TYPE_WAYLAND_NOLIBWAYLAND_SURFACE_CREATE_INFO_KHR or 
> VK_STRUCTURE_TYPE_DIRECTWAYLAND_SURFACE_CREATE_INFO_KHR, in addition to 
> the existing VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR?

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?

For comparison, VkXcbSurfaceCreateInfoKHR uses libxcb types in the API,
so you are forced to use libxcb if you want to use that. Likewise in
EGL, you are forced to use libX11 if you want to use the EGL X11
platform, and libwayland-client if you want to use the EGL Wayland
platform.

In any case, Wayland per se is not tied to any particular
implementation, even through libwayland is the authoritative
implementation. You are free to write a Wayland protocol implementation
from scratch with your own language. If the implementation is correct,
it will have no trouble as a client communicating with a Wayland
compositor written in C and using libwayland-server, for instance. Or
vice versa, your own compositor in your own language can well accept
any existing client written in any language.

It is also possible to replace libwayland in one process with a
completely different but ABI-compatible implementation. Just make sure
all pieces in the process use the same implementation. Between
processes, each process can use a totally different Wayland
implementation if you want to, as long as they all talk the same binary
wire format.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200916/2ad723c7/attachment.sig>