Hacker News Reader

Comment by OJFord | Hacker News Reader

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

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?

View on HN

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.

thanks for posting this, but I don't think it meets the definition of "Pretty simple".

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).

Reply on news.ycombinator.com