Identifying the real display server

[Mattias Andrée]

We are now getting a few new display server that can
emulate the X-interface. Notably X programs can run under
Wayland and Mir because of that have compatibility layers
for X. If you are running Wayland with the X compatibility
layer. Both of the environment variables DISPLAY and
WAYLAND_DISPLAY are set, and we can from this deduce that
Wayland is running with a X compatibility layer.

However if Wayland and Mir add compatibility layers for
each other, we will have the environment variables DISPLAY,
WAYLAND_DISPLAY and MIR_DISPLAY (I assume that is what Mir
is using). If both compatibility layers are costly and we
want the optimal performance we cannot be sure either we
should use Wayland or Mir (or even X if X adds
compatibility layers for Wayland and Mir,) by looking at
these environment variables.

Is there another way to identify which display server is
actually running? If not, I propose we add the environment
variable REAL_DISPLAY. The value of REAL_DISPLAY should be
then name of the environment variable used by the display
server that is actually running. For example if Wayland is
running with an X compatibility layer, the value of
REAL_DISPLAY should be WAYLAND_DISPLAY.

[Thiago Macieira]

Post by Mattias Andrée
Is there another way to identify which display server is
actually running? If not, I propose we add the environment
variable REAL_DISPLAY. The value of REAL_DISPLAY should be
then name of the environment variable used by the display
server that is actually running. For example if Wayland is
running with an X compatibility layer, the value of
REAL_DISPLAY should be WAYLAND_DISPLAY.

I'd recommend having one common variable that lists all the options, in the
order of preference of the compositing server. Suppose it's a Wayland server
with Mir and X compatibility layers and the X layer is better supported, we'd
have:

wayland:///run/user/1000/wayland-0|x11::0|mir:///run/user/1000/mir-0

I chose to use the pipe character (|) because it cannot appear unencoded in
URLs, so you can easily tokenise and parse each item as a URL. The space
character would have served just as well.

As for the name of the variable itself... I'll leave the bikeshed to others
:-)

[Mattias Andrée]

On Fri, 10 Apr 2015 18:24:52 -0700

Post by Thiago Macieira

Post by Mattias Andrée
Is there another way to identify which display server is
actually running? If not, I propose we add the
environment variable REAL_DISPLAY. The value of
REAL_DISPLAY should be then name of the environment
variable used by the display server that is actually
running. For example if Wayland is running with an X
compatibility layer, the value of REAL_DISPLAY should
be WAYLAND_DISPLAY.

I'd recommend having one common variable that lists all
the options, in the order of preference of the
compositing server. Suppose it's a Wayland server with
Mir and X compatibility layers and the X layer is better
wayland:///run/user/1000/wayland-0|x11::0|mir:///run/user/1000/mir-0
I chose to use the pipe character (|) because it cannot
appear unencoded in URLs, so you can easily tokenise and
parse each item as a URL. The space character would have
served just as well.
As for the name of the variable itself... I'll leave the
bikeshed to others :-)

List of preference is a good idea. But I think the
URL is overly complicated and redundant. The *DISPLAY
variable must still be set for each protocol.

I suggest the same specifications as my original
proposal with the addition that the value is a
space (\x20) separated list in order of preference.
Leading, duplicate and trailing spaces should be
allowed by are ignored.

The reason for using a space character as the
delimiter is that single ASCII character
delimiters is simplest to implement, it is
a character that never causes any problems
except for in once case that we can utilise,
shells do not support them in environment
variable names. Similarly, = is not supported
in variable environment names, but using it
as a delimiter is not as readable, and it
does not have the same nice property as
whitespace: $REAL_DISPLAY, without quotes,
in a shell is evaluated to one argument
display server listed in it.

[Giovanni Campagna]

On Fri, Apr 10, 2015 at 6:44 PM, Mattias Andrée

Post by Mattias Andrée
On Fri, 10 Apr 2015 18:24:52 -0700

Post by Thiago Macieira

Post by Mattias Andrée
Is there another way to identify which display server is
actually running? If not, I propose we add the
environment variable REAL_DISPLAY. The value of
REAL_DISPLAY should be then name of the environment
variable used by the display server that is actually
running. For example if Wayland is running with an X
compatibility layer, the value of REAL_DISPLAY should
be WAYLAND_DISPLAY.

I'd recommend having one common variable that lists all
the options, in the order of preference of the
compositing server. Suppose it's a Wayland server with
Mir and X compatibility layers and the X layer is better
wayland:///run/user/1000/wayland-0|x11::0|mir:///run/user/1000/mir-0
I chose to use the pipe character (|) because it cannot
appear unencoded in URLs, so you can easily tokenise and
parse each item as a URL. The space character would have
served just as well.
As for the name of the variable itself... I'll leave the
bikeshed to others :-)

List of preference is a good idea. But I think the
URL is overly complicated and redundant. The *DISPLAY
variable must still be set for each protocol.
I suggest the same specifications as my original
proposal with the addition that the value is a
space (\x20) separated list in order of preference.
Leading, duplicate and trailing spaces should be
allowed by are ignored.
The reason for using a space character as the
delimiter is that single ASCII character
delimiters is simplest to implement, it is
a character that never causes any problems
except for in once case that we can utilise,
shells do not support them in environment
variable names. Similarly, = is not supported
in variable environment names, but using it
as a delimiter is not as readable, and it
does not have the same nice property as
whitespace: $REAL_DISPLAY, without quotes,
in a shell is evaluated to one argument
display server listed in it.

Well, at this point you're essentially reinventing GDK_BACKEND, but at
server side. Given that the level of support is very much toolkit
specific, what's the advantage of this proposal over setting the
variables for the different toolkits with the compositor preferred
order?

(I would expect Qt and SDL to have similar environment variables, but I
don't know)

Cheers

Giovanni

[Mattias Andrée]

On Fri, 10 Apr 2015 18:48:02 -0700

On Fri, Apr 10, 2015 at 6:44 PM, Mattias Andrée

Post by Mattias Andrée
On Fri, 10 Apr 2015 18:24:52 -0700

On Saturday 11 April 2015 00:33:50 Mattias Andrée

Post by Mattias Andrée
Is there another way to identify which display
server is actually running? If not, I propose we
add the environment variable REAL_DISPLAY. The
value of REAL_DISPLAY should be then name of the
environment variable used by the display server
that is actually running. For example if Wayland is
running with an X compatibility layer, the value of
REAL_DISPLAY should be WAYLAND_DISPLAY.

I'd recommend having one common variable that lists
all the options, in the order of preference of the
compositing server. Suppose it's a Wayland server with
Mir and X compatibility layers and the X layer is
wayland:///run/user/1000/wayland-0|x11::0|mir:///run/user/1000/mir-0
I chose to use the pipe character (|) because it
cannot appear unencoded in URLs, so you can easily
tokenise and parse each item as a URL. The space
character would have served just as well.
As for the name of the variable itself... I'll leave
the bikeshed to others :-)

List of preference is a good idea. But I think the
URL is overly complicated and redundant. The *DISPLAY
variable must still be set for each protocol.
I suggest the same specifications as my original
proposal with the addition that the value is a
space (\x20) separated list in order of preference.
Leading, duplicate and trailing spaces should be
allowed by are ignored.
The reason for using a space character as the
delimiter is that single ASCII character
delimiters is simplest to implement, it is
a character that never causes any problems
except for in once case that we can utilise,
shells do not support them in environment
variable names. Similarly, = is not supported
in variable environment names, but using it
as a delimiter is not as readable, and it
does not have the same nice property as
whitespace: $REAL_DISPLAY, without quotes,
in a shell is evaluated to one argument
display server listed in it.

Well, at this point you're essentially reinventing
GDK_BACKEND, but at server side. Given that the level of
support is very much toolkit specific, what's the
advantage of this proposal over setting the variables for
the different toolkits with the compositor preferred
order?
(I would expect Qt and SDL to have similar environment
variables, but I don't know)
Cheers
Giovanni

Was not aware of GDK_BACKEND. But perhaps we should
standardise this. Having this toolkit-dependant is
just silly. We should not have to enumerate all
toolkits and add a variable for each of them. And
programs that do not use toolkits should not have
too look enumerate all toolkits and look at their
variables to figure out what to use.

[Simon McVittie]

Post by Giovanni Campagna
Well, at this point you're essentially reinventing GDK_BACKEND, but at
server side.

GDK_BACKEND, or a cross-toolkit generalization of it, seems like a
better model: a list of protocols, not a list of environment variables.

XDG_RUNTIME_DIR gives us the opportunity to reduce the number of
miscellaneous environment variables that need to be copied around, and I
would prefer to be aiming for a future where nobody needs to set
WAYLAND_DISPLAY or DBUS_SESSION_BUS_ADDRESS or GPG_AGENT_INFO or
SSH_AUTH_SOCK or whatever Mir's DISPLAY-equivalent is (maybe even not
DISPLAY either, on a sufficiently legacy-free system) unless they are
doing something unusual.

dbus 1.9 defaults to using $XDG_RUNTIME_DIR/bus if it exists and
DBUS_SESSION_BUS_ADDRESS is unset, and my understanding is that Wayland
does something similar. People have been talking about a similar thing
for DISPLAY for a long time, although nothing seems to have come of it.
That's a future that I'd prefer to head towards.

(tl;dr: PREFERRED_DISPLAY="wayland mir x11" would be better than
PREFERRED_DISPLAY="WAYLAND_DISPLAY MIR_DISPLAY DISPLAY".)

[Mattias Andrée]

On Mon, 13 Apr 2015 12:14:02 +0100

Post by Simon McVittie

Post by Giovanni Campagna
Well, at this point you're essentially reinventing
GDK_BACKEND, but at server side.

GDK_BACKEND, or a cross-toolkit generalization of it,
seems like a better model: a list of protocols, not a
list of environment variables.
XDG_RUNTIME_DIR gives us the opportunity to reduce the
number of miscellaneous environment variables that need
to be copied around, and I would prefer to be aiming for
a future where nobody needs to set WAYLAND_DISPLAY or
DBUS_SESSION_BUS_ADDRESS or GPG_AGENT_INFO or
SSH_AUTH_SOCK or whatever Mir's DISPLAY-equivalent is
(maybe even not DISPLAY either, on a sufficiently
legacy-free system) unless they are doing something
unusual.

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?

Post by Simon McVittie
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.

Post by Simon McVittie
exists and DBUS_SESSION_BUS_ADDRESS is unset, and my
understanding is that Wayland does something similar.
People have been talking about a similar thing for
DISPLAY for a long time, although nothing seems to have
come of it. That's a future that I'd prefer to head
towards.

Whilst irrelevant, I am going to comment. I think this
is a bad idea. It makes the systems more complex for
no significant benefit.

Post by Simon McVittie
(tl;dr: PREFERRED_DISPLAY="wayland mir x11" would be
better than PREFERRED_DISPLAY="WAYLAND_DISPLAY
MIR_DISPLAY DISPLAY".)

I don't know how you came to that conclusing, but
after some consideration I agree. It makes it easier
to use an abstraction layer. We will have to restrict
the protocol names to [a-z0-9+-]-characters only.

[Simon McVittie]

Post by Mattias Andrée
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.

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

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.

Post by Mattias Andrée

Post by Simon McVittie
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 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.

[Mattias Andrée]

On Mon, 13 Apr 2015 20:59:42 +0100

Post by Simon McVittie

Post by Mattias Andrée
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.

Post by Simon McVittie
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.

Post by Simon McVittie
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.

Post by Mattias Andrée

Post by Simon McVittie
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
"""
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.

Post by Simon McVittie
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.

[Thiago Macieira]

Post by Mattias Andrée
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.

Every time you say something like that, you insult the developers who work on
that project (like Simon and I). Do you want us to take you seriously? Please
be considerate of everyone's efforts.

[Thiago Macieira]

Post by Simon McVittie
(tl;dr: PREFERRED_DISPLAY="wayland mir x11" would be better than
PREFERRED_DISPLAY="WAYLAND_DISPLAY MIR_DISPLAY DISPLAY".)

If we're going to do that, why not put the full identifiers in the variable?
Then we wouldn't have to look up another environment variable for the details.

[Mattias Andrée]

On Mon, 13 Apr 2015 10:14:32 -0700

Post by Thiago Macieira

Post by Simon McVittie
(tl;dr: PREFERRED_DISPLAY="wayland mir x11" would be
better than PREFERRED_DISPLAY="WAYLAND_DISPLAY
MIR_DISPLAY DISPLAY".)

If we're going to do that, why not put the full
identifiers in the variable? Then we wouldn't have to
look up another environment variable for the details.

Are you asking why we should have PREFERRED_DISPLAY=x11
rather than PREFERRED_DISPLAY=DISPLAY or are you asking
why we should have PREFERRED_DISPLAY=x11 rather than
PREFERRED_DISPLAY=x11=:0?


If the former:

Assume have program that uses an abstraction layer.
Then we can, for example, do something like

for proto in os.environ['PREFERRED_DISPLAY'].split():
if not proto == '':
if my_abstraction_layer.select_protocol(proto):
break
else:
my_abstraction_layer.select_protocol('dri'):


If the latter:

If we do not to it this way, it makes the example above,
and similar things, more complex.
I think that WAYLAND_DISPLAY &c should _not_ be removed.
So it would be redundant, and doing a second look up is
cheap. And a program that only supports Wayland would
have to parse PREFERRED_DISPLAY.

[Thiago Macieira]

Post by Mattias Andrée

Post by Thiago Macieira
If we're going to do that, why not put the full
identifiers in the variable? Then we wouldn't have to
look up another environment variable for the details.

Are you asking why we should have PREFERRED_DISPLAY=x11
rather than PREFERRED_DISPLAY=DISPLAY or are you asking
why we should have PREFERRED_DISPLAY=x11 rather than
PREFERRED_DISPLAY=x11=:0?

The latter.

Post by Mattias Andrée
If we do not to it this way, it makes the example above,
and similar things, more complex.
I think that WAYLAND_DISPLAY &c should _not_ be removed.
So it would be redundant, and doing a second look up is
cheap. And a program that only supports Wayland would
have to parse PREFERRED_DISPLAY.

That's until someone figures out another display server besides the ones that
already exist. This avoids having 4+ environment variables set when one could
do it just fine.

# pseudo-code, I don't know Python
for url in os.environ['PREFERRED_DISPLAY'].split():
if isDisplaySupported(url.scheme()):
initDisplay(url.path())
else:
croak()

[Mattias Andrée]

On Mon, 13 Apr 2015 13:49:07 -0700

Post by Thiago Macieira

Post by Mattias Andrée

Post by Thiago Macieira
If we're going to do that, why not put the full
identifiers in the variable? Then we wouldn't have to
look up another environment variable for the details.

Are you asking why we should have PREFERRED_DISPLAY=x11
rather than PREFERRED_DISPLAY=DISPLAY or are you asking
why we should have PREFERRED_DISPLAY=x11 rather than
PREFERRED_DISPLAY=x11=:0?

The latter.

Post by Mattias Andrée
If we do not to it this way, it makes the example above,
and similar things, more complex.
I think that WAYLAND_DISPLAY &c should _not_ be removed.
So it would be redundant, and doing a second look up is
cheap. And a program that only supports Wayland would
have to parse PREFERRED_DISPLAY.

That's until someone figures out another display server
besides the ones that already exist. This avoids having
4+ environment variables set when one could do it just
fine.
# pseudo-code, I don't know Python
initDisplay(url.path())
croak()

Consider the URL parsing code too, and
the fact that you need in object oriented
languages need to create an instance of an
URL class. Additionally, we cannot assume
that the generic syntax covers all display
server's syntax. In fact, x11 is not
covered. There is also the complexity of
URL encoding the pathnames. In shell scripts.
Furthermore at least DISPLAY must remain
for because of legacy programs.

[Thiago Macieira]

Post by Mattias Andrée
Consider the URL parsing code too, and
the fact that you need in object oriented
languages need to create an instance of an
URL class. Additionally, we cannot assume
that the generic syntax covers all display
server's syntax. In fact, x11 is not
covered. There is also the complexity of
URL encoding the pathnames. In shell scripts.
Furthermore at least DISPLAY must remain
for because of legacy programs.

I hadn't considered shell scripts. What's the use you're thinking for them
here? To use as a wrapper for the front-end application but launching different
backends or passing different options depending on the display server?

As for x11, it is covered just fine with x11::0.

[Mattias Andrée]

On Mon, 13 Apr 2015 14:17:20 -0700

Post by Thiago Macieira

Post by Mattias Andrée
Consider the URL parsing code too, and
the fact that you need in object oriented
languages need to create an instance of an
URL class. Additionally, we cannot assume
that the generic syntax covers all display
server's syntax. In fact, x11 is not
covered. There is also the complexity of
URL encoding the pathnames. In shell scripts.
Furthermore at least DISPLAY must remain
for because of legacy programs.

I hadn't considered shell scripts. What's the use you're
thinking for them here? To use as a wrapper for the
front-end application but launching different backends or
passing different options depending on the display server?

<https://github.com/maandree/epkill/blob/master/src/dpkill>
- pkill but it only kills programs within the same display.

Post by Thiago Macieira
As for x11, it is covered just fine with x11::0.

But that is not convered by the generic syntax for URL:s.

It would have to be x11:///0 for :0 and x11:///0/1
or (less preferable) x11:///0.1 for :0.1.
And x11://localhost/0.1 or x11://localhost/0/1
for localhost:0.1

The generic syntax is
scheme://[[username[:password]@]host[:port]][/[path][?query][#fragment]]
And we must assume that libraries will parse <port> as an
integer.

[Thiago Macieira]

Post by Mattias Andrée

Post by Thiago Macieira
As for x11, it is covered just fine with x11::0.

But that is not convered by the generic syntax for URL:s.

Yes it is. RFC 3986, Appendix A has the ABNF for URIs.

Decoding (only the relevant parts):
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty

path-rootless = segment-nz *( "/" segment )

segment-nz = 1*pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

So it decodes to
scheme "x11"
":" ":"
hier-part ":0"
path-rootless ":0"
segment-nz ":0"

Post by Mattias Andrée
It would have to be x11:///0 for :0 and x11:///0/1
or (less preferable) x11:///0.1 for :0.1.
And x11://localhost/0.1 or x11://localhost/0/1
for localhost:0.1
The generic syntax is
And we must assume that libraries will parse <port> as an

Your syntax is incorrect. The authority and the double slash are optional. And
even when they are present, the expansion for authority → host → reg-name
allows for it to be empty too:

reg-name = *( unreserved / pct-encoded / sub-delims )

If that weren't the case, file:///etc/passwd wouldn't be valid.

[Mattias Andrée]

On Mon, 13 Apr 2015 16:41:12 -0700

Post by Thiago Macieira

Post by Mattias Andrée

Post by Thiago Macieira
As for x11, it is covered just fine with x11::0.

But that is not convered by the generic syntax for
URL:s.

Yes it is. RFC 3986, Appendix A has the ABNF for URIs.
URI = scheme ":" hier-part [ "?" query ]
[ "#" fragment ] scheme = ALPHA *( ALPHA / DIGIT /
"+" / "-" / "." )
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
path-rootless = segment-nz *( "/" segment )
segment-nz = 1*pchar
pchar = unreserved / pct-encoded /
"-" / "." / "_" / "~"
So it decodes to
scheme "x11"
":" ":"
hier-part ":0"
path-rootless ":0"
segment-nz ":0"
This is the same expansion that allows for

Post by Mattias Andrée
It would have to be x11:///0 for :0 and x11:///0/1
or (less preferable) x11:///0.1 for :0.1.
And x11://localhost/0.1 or x11://localhost/0/1
for localhost:0.1
The generic syntax is
And we must assume that libraries will parse <port> as
an

Your syntax is incorrect. The authority and the double
slash are optional. And even when they are present, the
expansion for authority → host → reg-name allows for it
reg-name = *( unreserved / pct-encoded /
sub-delims )
If that weren't the case, file:///etc/passwd wouldn't be
valid.

As I wrote it, the only thing that was mandatory was
scheme://, of course the absolute minimum was scheme:
But arguing whether it is covered or not is uninteresting;
it was just an example.

[Ted Gould]

Post by Mattias Andrée
Is there another way to identify which display server is
actually running? If not, I propose we add the environment
variable REAL_DISPLAY. The value of REAL_DISPLAY should be
then name of the environment variable used by the display
server that is actually running. For example if Wayland is
running with an X compatibility layer, the value of
REAL_DISPLAY should be WAYLAND_DISPLAY.

I think this is backwards. The system is more likely to want to setup
the environment for the application rather than the application adapting
to the system based on a list.

As an example we're discussing supporting current applications that
required X on the Ubuntu Desktop when running Mir. If a user is running
applications that all can talk to Mir directly we're not going to start
any type of X compatibility, there's no reason to have it. If the
application needs that X compatibility we'll start that proxy as part of
the application startup and the application will start in a world that
it has X and it is happy.

So, it seems to me, that a better solution is to add a key to the
desktop file that is something like:

PerferredDisplayProtocol=mir;x11;wayland;

Then we could also not show applications (or show them disabled or some
such) that require a protocol that we can't support on a particular
system.

Ted

[Mattias Andrée]

On Mon, 13 Apr 2015 16:32:52 -0500

Post by Ted Gould

Post by Mattias Andrée
Is there another way to identify which display server is
actually running? If not, I propose we add the
environment variable REAL_DISPLAY. The value of
REAL_DISPLAY should be then name of the environment
variable used by the display server that is actually
running. For example if Wayland is running with an X
compatibility layer, the value of REAL_DISPLAY should
be WAYLAND_DISPLAY.

I think this is backwards. The system is more likely to
want to setup the environment for the application rather
than the application adapting to the system based on a
list.
As an example we're discussing supporting current
applications that required X on the Ubuntu Desktop when
running Mir. If a user is running applications that all
can talk to Mir directly we're not going to start any
type of X compatibility, there's no reason to have it. If
the application needs that X compatibility we'll start

How do you know if the application requires X?

Post by Ted Gould
that proxy as part of the application startup and the
application will start in a world that it has X and it is
happy.
So, it seems to me, that a better solution is to add a
PerferredDisplayProtocol=mir;x11;wayland;

It works fine for .desktop files, we will just have to
patch all programs that start programs based on .desktop
files. But it is completely useless if I start from
dmenu, a terminal or a similar program.

But there seems to be a misunderstanding here.
It is not about what the program prefers, it is about
what the real display server supports best, probably
best performance. So the list to .desktop files does
not solve _this_ problem, the list is specific to what
display server is running and its compatibility layers.

Post by Ted Gould
Then we could also not show applications (or show them
disabled or some such) that require a protocol that we
can't support on a particular system.

In .desktop files could specify a list of supported
display servers.

A solution for this, when .desktop files are not used,
that I'm planning to implement is to have programs in
separate directories:
/{,s}bin Programs that run in the terminal or
can run anywhere.
/{,s}nbin Programs that can only run in the VT
(they use the the framebuffer some other
subsystem that is no accessible from a
display.)
/{,s}xbin Programs that support X
/{,s}wbin Programs that support Wayland
and so on.

Post by Ted Gould
Ted

[Ted Gould]

Post by Mattias Andrée
On Mon, 13 Apr 2015 16:32:52 -0500

Post by Ted Gould

Post by Mattias Andrée
Is there another way to identify which display server is
actually running? If not, I propose we add the
environment variable REAL_DISPLAY. The value of
REAL_DISPLAY should be then name of the environment
variable used by the display server that is actually
running. For example if Wayland is running with an X
compatibility layer, the value of REAL_DISPLAY should
be WAYLAND_DISPLAY.

I think this is backwards. The system is more likely to
want to setup the environment for the application rather
than the application adapting to the system based on a
list.
As an example we're discussing supporting current
applications that required X on the Ubuntu Desktop when
running Mir. If a user is running applications that all
can talk to Mir directly we're not going to start any
type of X compatibility, there's no reason to have it. If
the application needs that X compatibility we'll start

How do you know if the application requires X?

Right now we're using how it's installed. If it is a Click package we
assume that it wants Mir unless otherwise specified, and backwards if it
is a deb.

Post by Mattias Andrée

Post by Ted Gould
that proxy as part of the application startup and the
application will start in a world that it has X and it is
happy.
So, it seems to me, that a better solution is to add a
PerferredDisplayProtocol=mir;x11;wayland;

It works fine for .desktop files, we will just have to
patch all programs that start programs based on .desktop
files. But it is completely useless if I start from
dmenu, a terminal or a similar program.

In Unity 8 we only allow starting applications via a desktop file, so
that isn't a concern for us. I could see how it is a concern for others,
but in that case I think they should only allow their display servers
protocol (i.e. not start any proxies or compatibility layers) in that
case.

Post by Mattias Andrée
But there seems to be a misunderstanding here.
It is not about what the program prefers, it is about
what the real display server supports best, probably
best performance. So the list to .desktop files does
not solve _this_ problem, the list is specific to what
display server is running and its compatibility layers.

So then, for us, it will always be set to "mir" as there will be no
other compatibility layers running unless we think the application needs
them.

Post by Mattias Andrée

Post by Ted Gould
Then we could also not show applications (or show them
disabled or some such) that require a protocol that we
can't support on a particular system.

In .desktop files could specify a list of supported
display servers.

I think that makes the most sense.

Ted