Running multiple Wayland window managers in different ttys

Dima Ryazanov dima at
Fri Oct 20 21:02:56 UTC 2017

1. Actually, Weston *should* set the right wayland socket automatically.
They're not mapped to ttys - but Weston tries them until it finds an
available one (at least, in my case). I see the following in the log:

[23:52:27.077] libwayland: unable to lock lockfile
/run/user/1000/wayland-0.lock, maybe another compositor is running

So to me, this looks like a bug in sway.

2. Setting "WAYLAND_DISPLAY=wayland-1" before running Weston causes Weston
to try to connect to a parent compositor instead of running directly on top
of the tty. But of course, there's no parent compositor listening on
Yeah, setting --socket=wayland-1 should work - but, as I said above,
shouldn't actually be necessary.

3. gnome-terminal works for me as expected, despite the server process. I'm
not really familiar with it, though.

On Fri, Oct 20, 2017 at 9:58 PM, Matt Hoosier <matt.hoosier at>

> Hi Deepak,
> On Fri, Oct 20, 2017 at 11:50 AM, Deepak Jois <deepak.jois at>
> wrote:
> > Hi
> >
> > I have read the Wayland docs and skimmed through the API reference,
> > and I am trying to understand some concepts better. The questions
> > below are probably a bit naive, but I appreciate any
> > suggestions/explanations.
> >
> > To illustrate my situation better, let me start with an actual
> > scenario I tried to make work. I am trying to run Gnome and another
> > Wayland-based window manager (Sway or Weston) in two different ttys as
> > the same user.
> >
> > I have Gnome running under Wayland on tty2. The Gnome session is
> > running some app like gnome-terminal.
> >
> > I do the following:
> >
> > * Press Ctrl-Alt-F3 (switching to tty3, the lowest free tty)
> > * Login as the same user running the Gnome session
> > * Launch sway
> > * Launch urxvt and try to launch gnome-terminal.
> >
> > Now I have two issues I am trying to understand better:
> >
> > 1. When I check the WAYLAND_DISPLAY variable in the sway session, it
> > shows 'wayland-0', which is the same as the one show in the Gnome
> > session. Why is it the same? Does Wayland have a concept of multiple
> > servers/sessions per user? Can I run the Gnome session and the Sway
> > session separately?
> Although you're right that the goal here is to bind the different
> Wayland sessions' values for WAYLAND_DISPLAY to unique virtual
> terminals, that won't happen automatically just because you launched
> them from separate tty's.
> The trick here is to inform each compositor that it should be
> listening on a different Wayland socket name. For example, if you use
> Weston:
>     $ weston --socket=wayland-1
> This will cause Weston to establish its listening socket under the
> name /run/user/<uid>/wayland-1 rather than the default
> /run/user/<uid>/wayland-0. I think you're running into collisions
> where each of your compositor instances is mislead into believing that
> it successfully managed to appropriate /run/user/<uid>/wayland-0 for
> itself.
> Also (at least for Weston), the value of the '--socket' parameter is
> used to automatically compute and set the value of the
> $WAYLAND_DISPLAY environment variable which is then passed along to
> all children of the compositor. Presumably for you, your desktop
> environment (e.g., Weston's desktop-shell) is the starting point from
> which you're launching other graphical programs. They will all in turn
> inherit this correct value of $WAYLAND_DISPLAY too.
> >
> > 2. I tried explicitly setting the WAYLAND_DISPLAY to wayland-1. It has
> > no effect on Sway. The WAYLAND_DISPLAY variable is reset inside the
> > session to wayland-0. But when I try to launch Weston, it errors out
> > (log below). Is this expected, or is this a bug?
> The way to get Weston to pass the right value of WAYLAND_DISPLAY to
> its spawn is to use --socket=.
> It's more difficult to invoke the Wayland gnome-session directly. I'm
> not sure how you would micromanage its selection of the server socket
> name.
> -Matt
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list