[PATCH] wayland-server: Add APIs to get some structure's value
Pekka Paalanen
ppaalanen at gmail.com
Thu Jun 23 11:38:55 UTC 2016
On Thu, 23 Jun 2016 19:47:23 +0900
______ <jhyuni.kang at samsung.com> wrote:
> Dear, Mr. Pekka Paalanen.
>
> Thanks you for your rapid reply and
> I understand what you mean.
>
> Yes, I just want to make like weston-info.
> But I want to insert extra information than weston-info.
>
> Weston-info just print interface's name/version/id about user defined
> interface.
Those we call "globals". There is nothing "user defined" there.
Globals are advertised via wl_registry. That is the definition of a
global.
> So I can't print requests and events supported by interfaces.
> And weston-info had difficult to query derived interfaces.
> (I'm not sure that this is right expression.)
I understand what you mean. Those are "normal" interfaces, not globals.
> wl_seat and wl_keyboard/wl_pointer/wl_touch is similar to derived interface.
>
> We could know how to get wl_keyboard because this is a base interface
> supported in wayland.
> So weston-info wait wl_keyboard using roundtrip.
> But the debug tool like weston-info did not know,
> how many derived interfaces were supported in this system.
> So it did not print all of interfaces.
> Because of this issue, I approach server side: global_list.
You do not need any of the modifications you are suggesting.
> You said that "it is just a database generated from the XML files"
> Yes, that is absolutely right.
> I want to make debug tool like weston-info but give more information.
> To give comfortable way to get information about wayland server and
> protocol.
Then you should do exactly that: generate a database from the XML
files, do what weston-info does to get the list of globals and their
supported versions, and then do a recursive search through the database
to find what object types can be created from the advertised globals,
what types can be created from those, and so on.
You do not need to call wl_registry.bind at all.
> Can I give to you one more question?
> Take weston-info to base, can I solve those problems?
> 1st, get requests/events information(such as name)
Write an XML processor, that extracts the exact info you need from the
XML files. Use the interface name as a key, and have it return the list
of requests and events.
wl_registry.global event gives you the interface name, and you can
search your database with that. The event also gives you the interface
version, which you can use to ignore any requests or events with
'since' attribute greater than that.
> 2nd, get whole of derived interfaces if I do not know that interface.
Write an XML processor, that extracts the exact info you need from the
XML files. For every request and event, store a list of what object
types (interfaces) it can create (easily found by looking only at
arguments of type 'new_id').
You search by an initial interface name you got from wl_registry.global
event, list the requests and events, and list the interfaces possible
to create by the requests and events. Then you do the search again for
each interface name you found. Repeat until everything listed.
>
> If it is not, and it is better method that get these information from XML,
> (like you refer to prior email)
> I will try that way.
>
> Anyway thank you for your reply and attention.
> It is helpful to me, so I appreciate these reply to you.
Yes, I very much recommend using the XML files. They have been written
precisely for machine-readability, for use cases like yours.
I do not think the patch "wayland-server: Add APIs to get some
structure's value" has a chance to be accepted. Not for your use case.
Thanks,
pq
> > -----Original Message-----
> > From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> > Sent: Wednesday, June 22, 2016 10:47 PM
> > To: ______
> > Cc: wayland-devel at lists.freedesktop.org
> > Subject: Re: [PATCH] wayland-server: Add APIs to get some structure's
> > value
> >
> > On Wed, 22 Jun 2016 19:45:15 +0900
> > ______ <jhyuni.kang at samsung.com> wrote:
> >
> > > Dear, Mr. Pekka Paalanen.
> > >
> > > Thank you for your reply and opinion.
> > > I have checked Mr. Giulio's patch:
> > > https://patchwork.freedesktop.org/series/4181/
> > > But unfortunately my patch was little different with Mr. Giulio's.
> > >
> > > His patch is to watch interfaces binded such clients.
> > > So He added wl_resource_get_interface() function to refer interface
> > > from resource.
> > > But My patch's purpose is that print which interface is supported in
> > > this server and which requests and events are supported current
> > > interface.
> >
> > Hi,
> >
> > for that, you need none of what you posted.
> >
> > Just make a normal client, create a wl_registry, and you will see what is
> > *actually supported* by the server. You cannot even get that from the
> > functions you added, because you are not taking into account the interface
> > versions advertised by the server.
> >
> > A server does not need to support the highest interface version that it
> > has the descriptions for.
> >
> > >
> > > But if he has plan to expand "GammaRay"'s function, my patch can
> > > support that.
> > > Because I add this APIs to support debugging.
> > >
> > > I explain to my purpose to this patch.
> > > So please give me more opinions.
> > >
> > > I want to see all of interfaces and requests/events names supported
> > > current server.
> > >
> > > Ex> command in console: $print_supported_layout
> > > [1] wl_compositor
> > > -- Request List --
> > > 0) create_surface
> > > 1) create_region
> > > -- Event List --
> > >
> > > [2] wl_subcompositor
> > > -- Request List --
> > > 0) destroy
> > > 1) get_subsurface
> > > -- Event List --
> > >
> > > Each server has different configuration, so that they could have
> > > different about supported interface.
> >
> > As I said, you get all the runtime information you need from a wl_registry
> > as a normal client, and the rest you get from the protocol XML
> > descriptions that are installed in the system, also extensions, not just
> > Wayland core.
> >
> > Try 'weston-info', works on any Wayland server.
> >
> > > Because this could show not only wayland's basic protocol but also
> > > extra protocol which is user defined.
> >
> > Ok, so you want information from server supported extensions for which you
> > do not have the XML files for. This is getting strange.
> >
> > Is this for reverse-engineering?
> >
> > > And it provide more convenience to client developer.
> >
> > This I disagree. A client developer will always need the corresponding
> > protocol XML description to be able to use it. You need to generate the
> > programming language bindings from XML.
> >
> > > The client developer can watch all of interface and requests/events
> > easily.
> > > (Yes, I know that to watch xml file is more easier to expert.)
> >
> > You can also look at what wayland-scanner generates from the XML, and you
> > can push that through Doxygen. Then you will have all of nice layout,
> > documentation, and C API.
> >
> > I would very strongly suggest writing a better document generator if
> > reading XML or what we generate from it is worse than reading a runtime
> > string dump that cannot include documentation.
> >
> > > This patch is not related to make new functions, fix bugs.
> > > Just to make easier to debug.
> > > Watch server's global list more easier.
> >
> > You can watch server's global list as a normal client just fine, just
> > create a wl_registry and listen.
> >
> > > I don't know this is enough explain why I want to added these APIs.
> > >
> > > Have you give me more opinions or tips about this.
> > > I'm ready to listen your opinions.
> > > If you feel my purpose is reasonable I'll add more specific doc to
> > > each APIs.
> >
> > Right, so what I understood is that you want two different things: to know
> > what a server supports at runtime (weston-info gives you that), and to get
> > "better" list of the interfaces. I would not consider your patch to be a
> > solution to either. Your approach cannot even access the documentation we
> > have so carefully written. If you need an index, then please generate an
> > index from the XML descriptions.
> >
> > I hope I didn't totally misunderstand.
> >
> > Do you have a real example of your proposal being used?
> >
> > You made a sketch with "$print_supported_layout", but to me it is just a
> > database generated from the XML files, filtered with what weston-info
> > reports. You do not need any changes to libwayland or compositors or
> > anything to implement that. And when you use the XML files as the source,
> > you can also include the actual documentation any way you want.
> >
> > I am leaning on rejecting this patch.
> >
> >
> > Thanks,
> > pq
> >
> > > > -----Original Message-----
> > > > From: wayland-devel
> > > > [mailto:wayland-devel-bounces at lists.freedesktop.org]
> > > > On Behalf Of Pekka Paalanen
> > > > Sent: Tuesday, June 21, 2016 5:02 PM
> > > > To: JengHyun Kang
> > > > Cc: wayland-devel at lists.freedesktop.org
> > > > Subject: Re: [PATCH] wayland-server: Add APIs to get some
> > > > structure's value
> > > >
> > > > On Tue, 21 Jun 2016 13:45:16 +0900
> > > > JengHyun Kang <jhyuni.kang at samsung.com> wrote:
> > > >
> > > > > This patch's purpose is getting global interface information
> > > > > registerred in the server.
> > > > > If global is created (used wl_global_create()), information are
> > > > > saved in global_list.
> > > > > But almost structures used in wayland is defined statically.
> > > > > So it is hard to get structure's values in server side.
> > > > >
> > > > > Added following APIs.
> > > > > - wl_display_get_global_list()
> > > > > - wl_global_get_interface()
> > > > > - wl_interface_get_name()
> > > > > - wl_interface_get_method_count()
> > > > > - wl_interface_get_methods()
> > > > > - wl_interface_get_event_count()
> > > > > - wl_interface_get_events()
> > > > > - wl_message_get_name()
> > > > > - wl_global_list_get_global()
> > > > >
> > > > > You can get interface information to combine added APIs.
> > > > > (Such as interface's name and events/requests name)
> > > > >
> > > > > 1st, you can get wl_list:global_list to use
> > > wl_display_get_global_list().
> > > > > 2nd, you can get length of wl_list to use wl_list_length() and
> > > > > wl_global to use wl_global_list_get_global().
> > > > > wl_global is saved in list, so you need index to get wl_global.
> > > > > 3rd, you can get wl_interface to use wl_global_get_interface().
> > > > > 4th, in wl_interface structure, there are so many information about
> > > > > interface name and events/requests information.
> > > > > so you can get information to use wl_interface_get_name(),
> > > > > wl_interface_get_method_count(), wl_interface_get_method(),
> > > > > wl_interface_get_event_count(), wl_interface_get_event().
> > > >
> > > > Hi,
> > > >
> > > > your commit message forgot to explain the one most important thing:
> > > >
> > > > Why?
> > > >
> > > > Also, please see https://patchwork.freedesktop.org/series/4181/
> > > > which is already reviewed and seems to overlap with yours. Giulio
> > > > has demonstrated the use case for all the API he is adding with a
> > > > single
> > > > screenshot:
> > > > https://i.imgur.com/ihW3d88.jpg
> > > >
> > > > and also roughly explaining how "GammaRay" hooks up to a compositor.
> > > >
> > > > It would be nice if you reviewed Giulio's series, checked how it
> > > > matches your needs, and then explain what you are still missing and
> > why.
> > > > Personally I am in favour of Giulio's series and no-one has yet
> > > > disagreed with it, so I think it has good chances of getting merged
> > once polished.
> > > >
> > > >
> > > > Thanks,
> > > > pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160623/14665d4b/attachment-0001.sig>
More information about the wayland-devel
mailing list