ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
everfree has quit [Remote host closed the connection]
everfree has joined #wayland
bigmantom has joined #wayland
bigmantom has left #wayland [#wayland]
Brainium has quit [Quit: Konversation terminated!]
bluebugs has quit [Remote host closed the connection]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest415
floof58 has joined #wayland
Guest415 has quit [Ping timeout: 480 seconds]
lanodan_ has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
lanodan has joined #wayland
mr-rich has quit []
smallville7123 has joined #wayland
Leopold_ has quit []
nerdopolis_ has joined #wayland
nerdopolis has quit [Read error: Connection reset by peer]
<smallville7123>
is sendmsg ONLY used for sending descriptors?
<smallville7123>
or is it used for other types of data in wayland?
<smallville7123>
pq:
<kennylevinsen>
smallville7123: all data, fds are only sent occasionally
<smallville7123>
hmm
<smallville7123>
so, for wl_connection_flush, if connection->fds_out is non zero size then we have fd's to send, otherwise we only have connection->out data to send
<smallville7123>
and size > MAX_FDS_OUT * sizeof(int32_t) is due to each `fd` is a 32 bit integer, right?
junaid has joined #wayland
<smallville7123>
btw, libwayland is not thread-safe right?
<smallville7123>
hmmm
<smallville7123>
how would i enumerate the fd ringbuffer for items?
<smallville7123>
eg for(HANDLE fd in connection->fds_out) ...
<i509VCB>
libwayland I believe has some internal synchronization, but reading can be racy (sockets) so you'd need to block while dispatching or get a guard to read from the socket. I think wl_proxy also has a weird thing you need to watch for
<kennylevinsen>
It’s a byte buffer full of uint32’s. All the code to manipulate it is already there.
<smallville7123>
alright
<kennylevinsen>
and yes, either there is data to send, or data + fds to send.
<kennylevinsen>
if it logically matches the existing code with the changes you have determined you need, then maybe try rather than ask :)
<smallville7123>
as the ringbuffer would simply be a contigous array of [fd][fd][fd][fd]... right?
<smallville7123>
fd ringbufferthe *
<smallville7123>
the fd ringbuffer*
<kennylevinsen>
If you don’t know if it logically matches existing code, you should spend a bit more time studying it first as it contains code handling everything for other platforms already
<pq>
If you understand how the ring buffer head and tail pointers work, you'll have no problem writing the code to manipulate them, but you may still need to draw things on paper just to be sure. Never underestimate the power of pencil and paper. :-)
jgrulich has quit [Remote host closed the connection]
<smallville7123>
not sure if the fd ring buffer can have a mix of different descriptors or not
dcz_ has joined #wayland
<pq>
in Linux, an fd is an fd, there is no difference. If you make e.g. shared memory and graphics buffer handles be fundamentally different, then yes, there can be a mix of them, but it may be hard to hit that case in practise.
<pq>
IOW, you could have a hard-to-reproduce random failures
<pq>
fundamentally different, is in needing different code paths to send overe to another process
<smallville7123>
yea
<pq>
*as in
Dami_Lu has quit [Read error: Connection reset by peer]
<pq>
the nature of libwayland is to send many messages in one sendmsg() call, and those messages could be whatever
cool110 has quit [Remote host closed the connection]
junaid has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
x2s has joined #wayland
paulk-bis has joined #wayland
paulk has quit [Read error: Connection reset by peer]
<x2s>
Hi. I'm rather new to wayland, so I'm wondering a bit about a few things. I have an old project that I want to update/migrate where I'm using an X server to display a Qt program and for remote access VNC.
<x2s>
Now I know that this will not work like this anymore with Wayland and I wonder if someone has written some best practices how to deal with this.
<x2s>
Mostly the VNC part is where I'm scratching my head. I figured out that I can either run a minimal compositor and then my old app just recompiled against a newer Qt and have it running as client
<x2s>
or just add the compositor parts to my app
<x2s>
But how do I get the vnc working again?
<x2s>
I've thought about adding libvncserver to the compositor, but maybe someone did that already?
<x2s>
(would that even be possible? The compositor should have access to the whole picture it displays, right?)
Moprius has quit [Quit: bye]
<x2s>
and I'm a bit restricted what software I can use, because it's an old yocto-based thing. But I might be able to get away with running Debian on it
<pq>
x2s, some Wayland compositors do have VNC support. One question is whether you want the compositor to have a local display mirrored through VNC, or only VNC.
paulk-bis has quit []
paulk has joined #wayland
<x2s>
pq: mirrored. I just don't want to have to get up and look at the display :)
paulk has quit [Read error: Connection reset by peer]
paulk has joined #wayland
<x2s>
I just found sway, which might have vnc support. I'm currently researching if it is possible to use that (yocto can be very limited when it comes to that)
<pq>
sway is an option, and another is weston with its screen-share plugin
rgallaispou has joined #wayland
<pq>
weston's VNC support has no yet been released but it's in upstream. It does have RDP though, with severe caveats on security.
<x2s>
well, if someone manages to get access to that network he might just take the device :)
<pq>
ok then :-)
<x2s>
I think screenshare is the way to go. Many thanks for the hint!
<pq>
good luck, and follow the example in the weston.ini man page to the detail - it can be picky to get working
<x2s>
I already saw the part "don't do that or it will load the plugin again" :)
<smallville7123>
pq: would it be safe to just copy the entire out* ringbuffers to the recepient's in* ringbuffers?
<smallville7123>
like send(connection->fd, &connection->out, ring_buffer_size(&connection->out), 0); recv(connection->fd, &connection->in, out_size, 0);
<smallville7123>
or similar
<kennylevinsen>
you should really study what the *current* ring buffer handling is doing
<smallville7123>
or rather, the data in/out ringbuffers
<kennylevinsen>
sending the whole ring buffer is very wasteful. All the ring buffer handling is already there, you just have to keep that in place.
<smallville7123>
as emulating sendmsg itself is next to impossible without in-depth knowlege about how this works inside the linux kernel / cygwin
<kennylevinsen>
knowing how it works in linux is easy, it's written in the manpage. No idea about cygwin.
<smallville7123>
yes but the actual implementation specifics of it are not
<smallville7123>
plus it literally translates the socket fd into a kernel specific socket struct so...
<kennylevinsen>
what it does in the kernel doesn't matter as you're not writing kernel code anyway, only user-space API in the manpage matters ;)
<kennylevinsen>
the linux kernel could engrave the data on a potato and send it by snailmail on tuesdays, as long as the manpage holds userspace is unaffected
<smallville7123>
also manpages often dont document behaviour in such detail to be able to "re-create" such implementation
<kennylevinsen>
and in your case, what matters is finding windows docs that fit the bill - can't do much about what the kernel does internally if you're not planning a kernel driver
<kennylevinsen>
sendmsg is POSIX
<kennylevinsen>
linux and many other OS's are implementing the spec that the manpage is describing
<kennylevinsen>
we should not be relying on any behavior not in the manpage
<smallville7123>
for example "
<smallville7123>
If the socket is a connectionless-mode socket, the message shall be sent to the address specified by msghdr if no pre-specified peer address has been set. If a peer address has been pre-specified, either the message shall be sent to the address specified in msghdr (overriding the pre-specified peer address), or the function shall return -1 and set errno to [EISCONN]." how tf would we detect a "connectionless socket", and how tf do we detect a "
<smallville7123>
pre-specified peer", and how tf do we temporarily "override" such a "pre-specified peer"
<kennylevinsen>
you don't detect it, you *specify* it when you open the socket
<kennylevinsen>
SOCK_STREAM -> sonnection-based, as per `man socket`
<kennylevinsen>
*connection
<smallville7123>
we might be able to use "sendto" but then there is the matter of dealing with the actual msghdr
<kennylevinsen>
yeah you'd have to skip that and use send (identical to sendto for SOCK_STREAM). As you don't have iovec's then, you'll have to use multiple send's as needed.
<smallville7123>
which would still involve duping the handles and passing such references to the client, which would still involve multiple send/recv calls since sending a socket involves sending a protocol struct to create a socket from, which is definitely larger than a simple handle value
Kacper_ has joined #wayland
<smallville7123>
also such may end up being too large to send in a single message if we need to send a large amount of handles to the recepient
kasper93 is now known as Guest455
Kacper_ is now known as kasper93
MajorBiscuit has quit [Ping timeout: 480 seconds]
<smallville7123>
anyway...
Guest455 has quit [Ping timeout: 480 seconds]
<smallville7123>
i dont wanna deal with msghdr and all the needed structs and typedefs and defines and implementation specific details ;-;
<kennylevinsen>
I don't follow. If you're redefining fd as handle, then you'll need to change serialization type 'h' (fds) which write no data to writing the handle, which must happen after you've DuplicateHandle's to get the handle in the first place
<kennylevinsen>
you'll still only be sending one HANDLE value, and flushing would be either one or two send calls depending on whether you're at the edge of the ringbuffer
<smallville7123>
yea
<kennylevinsen>
I don't know why you're talking about dealing with msghdr - if you don't have sendmsg, you don't have msghdr, so you won't be using it
<smallville7123>
cus it would probs be safer to re-implement sendmsg as opposed to rewriting the write/read functions
<kennylevinsen>
definitely not
<kennylevinsen>
you can't reimplement sendmsg anyway, so it'll just be a vague shim
<smallville7123>
yup
<kennylevinsen>
which is not very productive, so just use send/recv :)
<kennylevinsen>
I can't help but wonder, do you have a clear goal defined for your project?
<smallville7123>
get libwayland to compile on windows :)
<kennylevinsen>
well, compiling it is one thing - what do you expect to be able to do with it afterwards?
<kennylevinsen>
after all, you've changed the core protocol to be windows specific, and will need windows-specific protocols on top to use e.g. GPU buffers
<smallville7123>
im just assuming it would somewhat work
jmdaemon has joined #wayland
<kennylevinsen>
that's what I mean by goal. You'd need this libwayland-windows fork, a Wayland compositor written for windows, and wayland clients written for windows, for your libwayalnd-windows fork and with the new windows-specific protocols ("windows-dmabuf" whatever)
<smallville7123>
yea
Kacper_ has joined #wayland
kasper93 is now known as Guest459
Kacper_ is now known as kasper93
Guest459 has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
<kennylevinsen>
then you're not just making libwayland compile, you're designing the windows wayland ecosystem (somewhat separate from the unix one)
<kennylevinsen>
much bigger task
<kennylevinsen>
I think it would be better to start with the high level design, e.g. how is GPU memory handled on windows and how would you share it between processes, how you'd deal with keymaps and otherwise how you'd implement Wayland features before you start implementnig with low-level connection details.
kasper93 has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
tzimmermann has quit [Quit: Leaving]
manuel1985 has quit [Ping timeout: 480 seconds]
manuel_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
junaid has joined #wayland
smallville7123 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
kasper93 has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
systwi_ has quit [Read error: Connection reset by peer]
systwi has joined #wayland
Leopold_ has quit [Remote host closed the connection]