You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wayland servers can have sockets added in several ways:
via wl_display_add_socket. Which either: uses a given display name, WAYLAND_DISPLAY or wayland-0. (In that order)
via wl_display_add_socket_auto. Which scans through $XDG_RUNTIME_DIR for an unused wayland-$d (where $d is < 32) and binds the first available.
via wl_display_add_socket_fd. Which accepts a file descriptor. This can be for:
sockets created and passed in by parent for socket activation, (eg by systemd),
or created specifically by the library user for fine grained control.
My initial thoughts:
The first method seems to be the documented behavior of create_display. But, I'm not seeing it happen. Although it may not be the best behavior. By which I mean create_display should probably only do what wl_display_create does (the get event loop is probably fine).
Perhaps adding add_socket methods to Display or EventLoop. eg:
fn add_socket(&mut self, name: Option<&OsStr>) -> Result<()>
just calls wl_display_add_socket
fn add_socket_auto(&mut self) -> Result<String>
calls wl_display_add_socket_auto. Returns the resulting string. (Which should be utf8, although an OsString might be better anyway)
fn add_socket_rawfd(&mut self, fd: RawFd) -> Result<()>
calls wl_display_add_socket_fd with the passed fd.
fn add_socket_intofd<F>(&mut self, fd: F) -> Result<()> where F: IntoRawFd
converts fd to a RawFd and calls add_socket_rawfd.
This as a convience method for use with unix-sockets.
I might be able to do somethings about this, but I'm a bit busy over the next week or two.
The text was updated successfully, but these errors were encountered:
Hmm, indeed, there is a doc issue on create_display, which really just creates a display. I'm not sure what I did here.
I completely agree with you here, I was planning to add these various methods at some point, in a quite similar way as you suggested. But I'm quite busy as well, an focused my efforts on wayland-client at first.
I'll add them as soon as I have the opportunity, should not be a lot of work.
Wayland servers can have sockets added in several ways:
wl_display_add_socket
. Which either: uses a given display name,WAYLAND_DISPLAY
orwayland-0
. (In that order)wl_display_add_socket_auto
. Which scans through$XDG_RUNTIME_DIR
for an unusedwayland-$d
(where $d is < 32) and binds the first available.wl_display_add_socket_fd
. Which accepts a file descriptor. This can be for:sockets created and passed in by parent for socket activation, (eg by systemd),
or created specifically by the library user for fine grained control.
My initial thoughts:
The first method seems to be the documented behavior of
create_display
. But, I'm not seeing it happen. Although it may not be the best behavior. By which I meancreate_display
should probably only do whatwl_display_create
does (the get event loop is probably fine).Perhaps adding
add_socket
methods toDisplay
orEventLoop
. eg:fn add_socket(&mut self, name: Option<&OsStr>) -> Result<()>
just calls
wl_display_add_socket
fn add_socket_auto(&mut self) -> Result<String>
calls
wl_display_add_socket_auto
. Returns the resulting string. (Which should be utf8, although anOsString
might be better anyway)fn add_socket_rawfd(&mut self, fd: RawFd) -> Result<()>
calls
wl_display_add_socket_fd
with the passed fd.fn add_socket_intofd<F>(&mut self, fd: F) -> Result<()> where F: IntoRawFd
converts fd to a RawFd and calls
add_socket_rawfd
.This as a convience method for use with unix-sockets.
I might be able to do somethings about this, but I'm a bit busy over the next week or two.
The text was updated successfully, but these errors were encountered: