ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has joined #wayland
lsd|2 has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest7746
carlos_ has quit [Quit: carlos_]
Guest7633 has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
<wlb>
weston Merge request !263 closed (libweston: skip view which doesn't touch the output, in compositor_accumulate_damage())
carlos_ has quit [Ping timeout: 480 seconds]
newbthenewbd has quit [Ping timeout: 480 seconds]
godvino has joined #wayland
Guest7746 has quit [Remote host closed the connection]
Moprius has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
cmichael has quit [Ping timeout: 480 seconds]
iomari892 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
<Zeroine>
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?
iomari892 has joined #wayland
<Zeroine>
like the ID argument passed to get_registry request "00000002" wasn't chosen randomly?
<Zeroine>
I mean iirc it can't be random because they need to be increasing one by one and client and server have different ranges
MajorBiscuit has quit [Ping timeout: 480 seconds]
MrCooper has quit [Quit: Leaving]
<davidre>
I thi k what it tries to say that the object with id 2 that you create follows the interface
MrCooper has joined #wayland
<Zeroine>
ah, yeah that makes sense
<Zeroine>
thanks
rgallaispou has left #wayland [#wayland]
cool110 has joined #wayland
cool110 is now known as Guest7799
Guest7753 has quit [Ping timeout: 480 seconds]
Nosrep has quit [Remote host closed the connection]
heapheap has quit [Remote host closed the connection]
pochu_ has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
iomari892 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
_DOOM_ has joined #wayland
<_DOOM_>
Is destroy or release perferred when you are done with a wayland object?
<emersion>
depends if we messed up or not
<emersion>
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
<kchibisov>
I do't think there's an object with both at the same time.
<_DOOM_>
wl_output
<emersion>
in the libwayland generated API, there is
<emersion>
_destroy() is always generated, sends the destroy request if any, then free's the alloc
<emersion>
_release() sends the release request then free's the alloc
<kchibisov>
Ah, that makes sense why I never seen such a thing.
<_DOOM_>
So should I always call _destroy() or _release()
<emersion>
if release() exists, use that, otherwise destroy()
<_DOOM_>
Ok
___nick___ has joined #wayland
___nick___ has quit []
<_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?
<emersion>
indeed
<emersion>
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
<Zeroine>
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?
<Zeroine>
on the client the new_id makes sense though, I think
<Zeroine>
in get_registry description it mentions server resources being used so I guess it definitely is on the server
<emersion>
it's always the objectif with ID 1, pre-created
<Zeroine>
at least on the server*
<emersion>
object*
<Zeroine>
emersion: you mean wl_display, right?
<emersion>
yes
<emersion>
i mean the protocol object
<Zeroine>
yeah but what about the object ID 2 that is in that example?
<Zeroine>
it's created by get_registry so where does it exist?
<Zeroine>
on both?
<Zeroine>
because you can see the server calls it and so does the client
<Zeroine>
but on the server the object ID range is [4278190080, 4294967295]
<Zeroine>
and the first 32 bits of a message are the sender's object ID
<Zeroine>
I guess the example is wrong then?
<emersion>
the client sends the request
<emersion>
so it's a client-created object
<emersion>
no, the example is not wrong
<Zeroine>
emersion: "client-created object" as in it exists only on the client?
<Zeroine>
I know the client sends the request to create the registry object using get_registry
<emersion>
no, as in a new_id arg in a request
<emersion>
the protocol docs explain this iirc
jmdaemon has joined #wayland
<Zeroine>
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
<Zeroine>
how does this explain the IDs though?
<Zeroine>
the server is calling ID 2 while that ID can't exist on the server
rasterman has quit [Quit: Gettin' stinky!]
<Zeroine>
is the inferring from XML somehow relevant? I really don't know.
junaid has quit [Remote host closed the connection]
nerdopolis has joined #wayland
<dottedmag>
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
rgallaispou has joined #wayland
pbsds has quit [Ping timeout: 480 seconds]
ohmadcs^ has quit [Remote host closed the connection]
<kennylevinsen>
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
ohmadcs^ has joined #wayland
pbsds has joined #wayland
<kennylevinsen>
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
nerdopolis has quit [Remote host closed the connection]
<Zeroine>
Thanks for the answers but that object that the client allocated the ID for must eventually exist on the server, right?
<Zeroine>
and it can't use object ID 2 then for example, what does it use then?
nerdopolis has joined #wayland
<Zeroine>
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?
<Arnavion>
The ID only has to make sense for that one particular client connection
<Arnavion>
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
<Zeroine>
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.
<Arnavion>
As was already explained to you, new_id is allocated by the sender. For wl_registry::bind, the sender is the client
<Arnavion>
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"
<Zeroine>
maybe I'm explaining my question very badly, I don't know
<Zeroine>
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.
<Arnavion>
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.
<Zeroine>
yeah
<Arnavion>
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"
<Arnavion>
The ball is the wl_registry object. "Bob" is ID 2.
<Arnavion>
(Earlier I said wl_registry::bind but I should've said wl_display::get_registry. The point is the same)
rgallaispou has quit [Quit: WeeChat 4.0.2]
<emersion>
this is called the BNS -- the Ball Name System
<Zeroine>
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
<Arnavion>
The object exists on the server and the ID is the sender's object ID.
<Arnavion>
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
<Arnavion>
The ID was initially *assigned* by you
<Arnavion>
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?
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
<Zeroine>
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.
<Arnavion>
I mean, the concept of a ball named Bob exists on both sides
paulk-bis has joined #wayland
paulk has quit [Read error: Connection reset by peer]
<Zeroine>
Okay, thanks for the help. Sorry this has taken so long.
<Arnavion>
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...
<Arnavion>
There is a wl_registry object and both parties in the conversation agreed that it should be called ID 2
<Arnavion>
because the client asked for it to be named ID 2 and the server agreed