<div dir="ltr">There has been a surge of recent interest in the details of using Wayland on nontraditional systems that don't have the normal notion of human-user login sessions. Discussions are ongoing about the details of how to manage the allocation of TTYs and Weston's vision of the best practices for assigning Unix ownership modes to the hardware devices. Set those aside for the moment though.<div><br></div><div>I'd like to call attention to another difficult point in using Wayland for a device that acts more like a smartphone than a desktop: the main logic in wl_display_connect() always attempts to contact a server socket living at ${XDG_RUNTIME_DIR}/${WAYLAND_<wbr>DISPLAY}.</div><div><br></div><div>This creates a problem for a device that isolates each application in a different user ID. XDG_RUNTIME_DIR is expressly defined as a directory which is private to its user. The system must either abusively point numerous users' XDG_RUNTIME_DIR's all at the same path, or use an out-of-band hack such as hardlinking each application uid's /run/user/<application uid>/wayland-0 path to the true server socket /run/user/<weston uid>/wayland-0.</div><div><br></div><div>As a consequence, it is difficult to implement a security model similar to Android's, on a device that's adopted Wayland.</div><div><br></div><div>I can imagine several schemes for allowing a generic Wayland client program to transparently find some systemwide compositor instance. The client could automatically attempt to open /var/run/${WAYLAND_DISPLAY} if ${XDG_RUNTIME_DIR}/${WAYLAND_<wbr>DISPLAY} doesn't exist. That approach could also be modified to require the client to explicitly opt-in by setting some environment variable such as WAYLAND_RUNTIME_DIR that is treated as a fallback if XDG_RUNTIME_DIR contains no server socket.</div><div><br></div><div>Thoughts? It's very encouraging to see all the technical capabilities that allow Wayland/Weston to be a credible option for making embedded devices with great graphics support, but there are a few rough edges such as these that make deployment a challenge.</div></div>