New to Wayland, Need suggestion on a starting point

[Pekka Paalanen]

On Mon, 05 May 2014 13:53:05 +0530
Srivardhan <sri.hebbar at samsung.com> wrote:

> The Wayland protocol dumper is interesting. Pardon me if am asking
> stupid questions. I was wondering how I could implement it. I
> compiled Weston on my Ubuntu 21.04 and executed it. Below are my
> understanding, correct me if am wrong.
> 
>  
> 
> 1.       Weston uses the functions in the libwayland-server and
> libwayland-client and creates a compositor and client.
> 
> 2.       All the Wayland library functions which are used to create
> compositor is in src/wayland-server.c and all the Wayland library
> functions which are used to create client is in src/wayland-client.c
> 
> 3.       In both wayland-server.c and wayland-client.c
> wl_clorsure_print() is used to print logs to stderr. The functions
> call wl_closure_print to print logs and then call socket functions to
> send the message.
> 
>  
> 
> By this understanding, what I was thinking was, in the
> src/connection.c, if we create a debug socket and then write the
> messages to it too. The wayland-trace program can listen to that
> socket and then print the logs. What do you think? 

Hi,

I guess that might work, but it also seems a bit messy to manage, and
it does not separate the clients much when the server is sending. You
would have to create a server dump socket for each client. Then have a
way to find the right sockets and connect to them. Enforcing security
there would be a big issue.

At starting time, there would be a race between your dumper app
connecting to the dump sockets, and the client starting to use the
protocol. You might miss the first messages, which would then mean you
cannot interpret the rest of the stream either. Though I guess that
could be worked around by making the client wait for a connection in
the dump socket.

My idea is to not use libwayland at all. Instead, you would duplicate
all the needed parts in a stand-alone program. The starting point would
be to relay Wayland messages in both directions without parsing them at
all beyond the message size field. You just need to make sure to
handle file descriptors, otherwise it would be just a byte for byte
copy.

Once that works, you can already dump the header of each message,
allowing the tool to dump at least something on unknown protocol
extensions. The next step would be to read in the protocol XML files so
that you can actually parse and print the messages. You start with
wl_display as that is needed to maintain object references, and then do
the rest of the core protocol. Once you handle the core protocol, you
also handle all extensions that can ever be, as long as you have their
XML description.

You could use a custom generator to convert the XML into C data
structures, but I would prefer if the tool read in the XML files
directly. That way the built tool is not dependent on any particular
protocol version it was built with but you can use it on everything.
This would be very useful when developing protocols as one would not
need to recompile the dumping tool all the time. The XML files are
installed by each project maintaining them (or should be), so they
would be always available in distribution -devel packages I assume.

That would make the dumping tool an independent project. In the future,
it could then be a basis for more sophisticated tools, like an object
state recorder/viewer and graphical visualization, or maybe co-operate
with existing protocol visualization tools.

This project would introduce you to Wayland starting from the lowest
level of the protocol. If you wish to learn how Wayland works on a
higher level, with semantics, this would be a slow path, however.


Thanks,
pq