14:26wlb: weston Merge request !1340 opened by Marius Vlad (mvlad) kiosk-shell, xwayland: Add Xwayland surfaces appidd based on WM_NAME and WM_CLASS https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1340 [kiosk-shell], [XWayland]
15:15Zeroine: I don't understand the "Note in the XML documentation that this new ID is defined ahead of time to be governed by the wl_registry interface:" part in https://wayland-book.com/registry.html what did the author mean by this?
15:21Zeroine: like the ID argument passed to get_registry request "00000002" wasn't chosen randomly?
15:22Zeroine: I mean iirc it can't be random because they need to be increasing one by one and client and server have different ranges
15:39davidre: I thi k what it tries to say that the object with id 2 that you create follows the interface
15:44Zeroine: ah, yeah that makes sense
15:44Zeroine: thanks
19:39_DOOM_: Is destroy or release perferred when you are done with a wayland object?
19:39emersion: depends if we messed up or not
19:40emersion: if we messed up, we forgot to add a destroy request, so we added release as a fixup, and that's what you should use
19:40kchibisov: I do't think there's an object with both at the same time.
19:40_DOOM_: wl_output
19:40emersion: in the libwayland generated API, there is
19:41emersion: _destroy() is always generated, sends the destroy request if any, then free's the alloc
19:41emersion: _release() sends the release request then free's the alloc
19:41kchibisov: Ah, that makes sense why I never seen such a thing.
19:42_DOOM_: So should I always call _destroy() or _release()
19:42emersion: if release() exists, use that, otherwise destroy()
19:42_DOOM_: Ok
19:43_DOOM_: Wait so does the existance of the release request imply that a destroy doesn't always tell the compositor that an object should be destroyed?
19:43emersion: indeed
19:44emersion: a release request indicates that we messed up and forgot destroy, so destroy() does not inform the compositor that the client has destroyed the object
19:44_DOOM_: Oh, ok
19:44_DOOM_: Makes sense
19:45_DOOM_: Thanks
20:16Zeroine: https://wayland-book.com/registry/binding.html Is the wire protocol exchange example here correct?
20:18Zeroine: I don't know where get_registry exactly creates the registry object, from that exchange it looks like on both the client and server but the IDs don't make sense, shouldn't the server have much higher ID for the registry object, like when it calls it in the middle part of that example?
20:19Zeroine: on the client the new_id makes sense though, I think
20:20Zeroine: in get_registry description it mentions server resources being used so I guess it definitely is on the server
20:21emersion: it's always the objectif with ID 1, pre-created
20:21Zeroine: at least on the server*
20:21emersion: object*
20:22Zeroine: emersion: you mean wl_display, right?
20:22emersion: yes
20:22emersion: i mean the protocol object
20:22Zeroine: yeah but what about the object ID 2 that is in that example?
20:23Zeroine: it's created by get_registry so where does it exist?
20:23Zeroine: on both?
20:24Zeroine: because you can see the server calls it and so does the client
20:24Zeroine: but on the server the object ID range is [4278190080, 4294967295]
20:25Zeroine: and the first 32 bits of a message are the sender's object ID
20:25Zeroine: I guess the example is wrong then?
20:28emersion: the client sends the request
20:28emersion: so it's a client-created object
20:28emersion: no, the example is not wrong
20:29Zeroine: emersion: "client-created object" as in it exists only on the client?
20:30Zeroine: I know the client sends the request to create the registry object using get_registry
20:30emersion: no, as in a new_id arg in a request
20:31emersion: the protocol docs explain this iirc
20:36Zeroine: emersion: "The 32-bit object ID. Generally, the interface used for the new object is inferred from the xml, but in the case where it's not specified, a new_id is preceded by a string specifying the interface name, and a uint specifying the version." The "registry" arg to get_registry is new_id
20:36Zeroine: how does this explain the IDs though?
20:37Zeroine: the server is calling ID 2 while that ID can't exist on the server
20:43Zeroine: is the inferring from XML somehow relevant? I really don't know.
21:07dottedmag: whenever the argument type is new_id, the request or event will be sent with the _new_ ID, allocated by the sender, and the recipient should remember it
21:20kennylevinsen: Zeroine: client allocates ID, sends it as new_id arg to inform server "hi the object should be assigned to this ID" a and so if the client sends oid 2 for get_registry, that's the ID that the registry gets
21:21kennylevinsen: That's how all client allocated objects work - client picks the ID and sends it to the server in the relevant object creation message. This way, the client does not need to wait for the server to see the message, and can use the object immediately afterwards
21:27Zeroine: Thanks for the answers but that object that the client allocated the ID for must eventually exist on the server, right?
21:27Zeroine: and it can't use object ID 2 then for example, what does it use then?
21:29Zeroine: or does it not have to exist? dottedmag said the recipient (server) remembers them, how does that work? Can the server then just use it in it's messages first 32 bits as the object ID even if it doesn't exist on the server?
21:30Arnavion: The ID only has to make sense for that one particular client connection
21:34Zeroine: Arnavion: so here https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format it says "The first word is the sender's object ID (32-bit)". Then this isn't a strict rule? It doesn't have to be the _sender's_ object ID? It just has to "make sense"?
21:36Arnavion: I'm saying that "<Zeroine> and it can't use object ID 2 then for example" is a wrong premise. There is no reason the server can't use object ID 2 because object ID 2 has not yet been used in that client's session
21:39Zeroine: The reason I thought it couldn't use it to send messages is because of the range mentioned here https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Creating-Objects which for the server is [0xff000000, 0xffffffff] or [4278190080, 4294967295]. Like 2 doesn't belong inside there, therefore it can't be used for sending messages by the server, is what I thought.
21:40Arnavion: As was already explained to you, new_id is allocated by the sender. For wl_registry::bind, the sender is the client
21:40Arnavion: When the client says wl_registry::bind with new_id 2, it's telling the server "In the future I will use ID 2 to refer to this object". On the server side the server notes "In the future when the client says ID 2 it will refer to this object"
21:42Zeroine: But when the sender is the server "S->C" in this example https://wayland-book.com/registry/binding.html
21:43Zeroine: But what about when*
21:44Arnavion: What about it.
21:47Zeroine: maybe I'm explaining my question very badly, I don't know
21:48Zeroine: Okay, "S->C", that's server sending to the client. The message's first 32 bits must be "sender's object ID (32-bit)", the sender in this case is the server because it's sending to the client, the server's range of object IDs that it can have is [4278190080, 4294967295], 2 does not go in that range but yet it is sending a message in which the first word (32 bits) contains 2.
21:50Arnavion: Let's say you have a ball. You give me that ball and say "This ball's name is Bob." Now if you want me to throw the ball, you'll tell me "Throw Bob to me." If I agree, I'll say "Okay, I'll throw Bob to you." Notice how both of us used the same name "Bob" to refer to the ball.
21:51Zeroine: yeah
21:51Arnavion: Or, better example. I have a ball and show it to you. You say "That ball's name is now Bob." I say "Okay". Now if you want me to throw that ball to you, you'll say "Throw Bob to me." I'll say "Okay, I'll throw Bob to you." Again, both of us used the name "Bob"
21:52Arnavion: The ball is the wl_registry object. "Bob" is ID 2.
21:54Arnavion: (Earlier I said wl_registry::bind but I should've said wl_display::get_registry. The point is the same)
21:56emersion: this is called the BNS -- the Ball Name System
21:58Zeroine: yeah thanks, then I guess "The first word is the sender's object ID (32-bit)." isn't as strict as I thought, the object doesn't have to exist on the server, it just has to either exist or have been remembered by the server
22:00Arnavion: The object exists on the server and the ID is the sender's object ID.
22:00Arnavion: The ball exists in my hands and when I say "Okay I'll throw Bob to you" I'm using the object's ID from my perspective
22:00Arnavion: The ID was initially *assigned* by you
22:03Arnavion: I can't even imagine how you think it would work otherwise. You'll say "Throw Bob to me." and I'll respond "Okay I'll throw Jeremy to you." How would you know what I'm talking about?
22:10Zeroine: Arnavion: Does it really work like that ball analogy then, it's not simultaneously existing on both ends? Maybe I should have mentioned this but by exist I mean that it's stored in the memory of the process running the server ever since the client sends that first get_registry request.
22:11Arnavion: I mean, the concept of a ball named Bob exists on both sides
22:14Zeroine: Okay, thanks for the help. Sorry this has taken so long.
22:14Arnavion: When I said the ball is the wl_registry object and talked about throwing it from me to you I didn't literally mean the wl_registry object moves from the server to the client...
22:14Arnavion: There is a wl_registry object and both parties in the conversation agreed that it should be called ID 2
22:15Arnavion: because the client asked for it to be named ID 2 and the server agreed
22:16Zeroine: Ah okay, thank you