New to Wayland, Need suggestion on a starting point

[Srivardhan]

> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at lists.freedesktop.org] On Behalf Of Pekka Paalanen
> Sent: Monday, May 05, 2014 5:36 PM
> To: Srivardhan
> Cc: 'Jason Ekstrand'; wayland-devel at lists.freedesktop.org
> Subject: Re: New to Wayland, Need suggestion on a starting point
> 
> 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.
> 

Hi,

I guess I need more knowledge on how Wayland protocol is working and how
Weston is working to implement this. I would do more reading and code study
of Weston and then would come back to this.  

Thank-you,
Hebbar
> 
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel