You have it right.
When a client does a connect on a socket that another process is listening to
(the listen is at line 692), this makes the other end get a "readable" on its
end of the socket. You then do an accept, which gives you a new fd for your
end of the connection. You then have a bid
Greetings,
I'm wondering what exactly sets off the socket_data function in
wayland/wayland-server.c at approximate line 640. I can see that we add a
file descriptor object of our socket to the main loop in
wl_display_add_socket that uses socket_data as the callback function when a
client connects
The major problem with PropertyNotify events, or with having generalized
properties of any kind, is that they are too much like polled interrupts rather
than vectored interrupts. You get the event, but you then have to poll to see
which thing changed.
Also, the protocol design seems to be more
I expect Wayland will add a "attach this blob of data to this
window+key" similar to X window properties, for IPC to the compositor
and other software.
The question is whether software is going to be required to keep these
things up to date for information that Wayland must know anyway.
Requi