Identifying the real display server

[Giovanni Campagna]

On Fri, Apr 10, 2015 at 6:44 PM, Mattias Andrée 
<maandree at member.fsf.org> wrote:
> On Fri, 10 Apr 2015 18:24:52 -0700
> Thiago Macieira <thiago at kde.org> wrote:
> 
>>  On Saturday 11 April 2015 00:33:50 Mattias Andrée wrote:
>>  > 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 :-)
>> 
> 
> 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