3 ms·

Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of atta

Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of attaching protocol headers and routing the packets. The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command. I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.

OJFord 5y ago
I found your comment grepping for someone sharing how to do it in Wayland, so here it is for the next person: docker run -e XDG_RUNTIME_DIR=/tmp \ -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \ --user=$(id -u):$(id -g) \ imagename waylandapplication Pretty simple and reasonable really, just needs to use the same Wayland socket and (in order to access it) user ID. From: https://unix.stackexchange.com/a/359244 https://unix.stackexchange.com/a/359244 I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?
- bdavis__ 5y ago
  thanks for posting this, but I don't think it meets the definition of "Pretty simple".
  - OJFord 5y ago
    It's verbose, but that's why I included the description 'just needs same socket and user ID'. That's simple isn't it? Of course it'll always need something. It could be made less verbose by encapsulating in a compose file, or by removing the env var to point into /tmp and instead using whatever the default is for the chosen image. Also it's not necessary to specify the value for an env var being passed through with the same name (I just copied from SO).
- nrdvana 5y ago
  You got me curious, so I looked it up: Transports To date all known Wayland implementations work over a Unix domain socket. This is used for one reason in particular: file descriptor messages. Unix sockets are the most practical transport capable of transferring file descriptors between processes, and this is necessary for large data transfers (keymaps, pixel buffers, and clipboard contents being the main use-cases). In theory, a different transport (e.g. TCP) is possible, but someone would have to figure out an alternative way of transferring bulk data. So, that is why I hear about needing X11 compat for remote connections; wayland connections are still sockets (not e.g. shared mem), but they require the ability to pass file descriptors through the socket, which can only be done with Unix sockets. (and those file descriptors provide access to shared mem) I don't see any details about how this interacts with OpenGL, like whether indirect rendering is possible or if applications would need /dev mounted.

OJFord 5y ago

I found your comment grepping for someone sharing how to do it in Wayland, so here it is for the next person: docker run -e XDG_RUNTIME_DIR=/tmp \ -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \ --user=$(id -u):$(id -g) \ imagename waylandapplication Pretty simple and reasonable really, just needs to use the same Wayland socket and (in order to access it) user ID. From: https://unix.stackexchange.com/a/359244 https://unix.stackexchange.com/a/359244 I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?

bdavis__ 5y ago
thanks for posting this, but I don't think it meets the definition of "Pretty simple".
- OJFord 5y ago
  It's verbose, but that's why I included the description 'just needs same socket and user ID'. That's simple isn't it? Of course it'll always need something. It could be made less verbose by encapsulating in a compose file, or by removing the env var to point into /tmp and instead using whatever the default is for the chosen image. Also it's not necessary to specify the value for an env var being passed through with the same name (I just copied from SO).
nrdvana 5y ago
You got me curious, so I looked it up: Transports To date all known Wayland implementations work over a Unix domain socket. This is used for one reason in particular: file descriptor messages. Unix sockets are the most practical transport capable of transferring file descriptors between processes, and this is necessary for large data transfers (keymaps, pixel buffers, and clipboard contents being the main use-cases). In theory, a different transport (e.g. TCP) is possible, but someone would have to figure out an alternative way of transferring bulk data. So, that is why I hear about needing X11 compat for remote connections; wayland connections are still sockets (not e.g. shared mem), but they require the ability to pass file descriptors through the socket, which can only be done with Unix sockets. (and those file descriptors provide access to shared mem) I don't see any details about how this interacts with OpenGL, like whether indirect rendering is possible or if applications would need /dev mounted.