Identifying the real display server

[Mattias Andrée]

On Mon, 13 Apr 2015 20:59:42 +0100
Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:

> On 13/04/15 16:36, Mattias Andrée wrote:
> > Have you considered that you may want to have two
> > displays (for example two instances of X or two
> > instances of Mir) with the same $XDG_RUNTIME_DIR?
> 
> Then you can use DISPLAY and/or the X-replacement's
> equivalent, just like you can still use
> DBUS_SESSION_BUS_ADDRESS if you want to have more than
> one instance of the D-Bus session bus with the same
> XDG_RUNTIME_DIR. But I don't think this should be
> required in the simpler situations that ought to "just
> work", like running an X app from the context of a
> per-user service where the user in question has exactly
> one graphical desktop.

I just meant that it ushers unnecessary complexity.

> 
> Note that this is per-(user,machine), not per-machine:
> the unusual case here is having more than one Xserver
> *per user* per machine. That's quite an unusual thing to
> do even with multi-seat, because in my experience, people
> are usually in one physical place at any given time :-)

I'm always superpositioned.

> 
> If you do want to be on more than one display device at a
> time, it seems like it would be better to be able to
> attach/detach output devices to a single
> DISPLAY-equivalent and move windows between them (as
> opposed to "I can't usefully edit that document, because
> I left it open with unsaved changes on seat0", or worse,
> "I can't read my email without kill(1), because I left
> Thunderbird running on seat0"). That can't work if each
> application is bound to a display by the initial values
> of its environment variables.
> 
> >> dbus 1.9 defaults to using $XDG_RUNTIME_DIR/bus if it
> > 
> > I hope you mean $XDG_RUNTIME_DIR/dbus, otherwise someone
> > need to make an amendment to dbus.
> 
> I do mean XDG_RUNTIME_DIR/bus. The initial proposal was
> XDG_RUNTIME_DIR/dbus/user_bus_socket (as seen in
> user-session-units and other early work on having one bus
> per user), but the sd-bus/kdbus developers wanted
> X_R_D/bus, which had in fact been sd-bus' default for
> quite a while before this was merged into dbus:
> 
> """
> In the systemd context we tried to avoid using the name
> "dbus" too much for the generic bits. We just refer to
> the "bus", without any further naming, since we want to
> ensure that there's no doubt that this is the one and
> only bus that matters on the OS, and not just one project
> among many. """ -
> https://bugs.freedesktop.org/show_bug.cgi?id=61303#c27

I'm sorry to whomever wrote that. But that is amongst
the stupidest things I have every heard. It almost have
"the earth was created on year 0" beat. Of course, it
should be dbus, dbus is the project.

> 
> I wanted to get this merged rather than painting
> naming-related bike sheds: partly because many "session"
> services, e.g. dconf, really want to be user services;
> partly because the kdbus developers have indicated that
> they will never support multiple session buses per user,
> and I wanted to start getting implementation experience
> for that mode before kdbus lands; and partly because the
> other option for a default way to connect to D-Bus is
> dbus-launch, which is tied to X11 anyway, so Wayland/Mir
> is a natural opportunity to get rid of it.
> 
It is ridiculous, and I hope we can get rid of this
overused D-Bus crapware and kdbus. My computer is of
course not running D-Bus, nor will my display server.