Identifying the real display server

[Mattias Andrée]

On Fri, 10 Apr 2015 18:48:02 -0700
Giovanni Campagna <scampa.giovanni at gmail.com> wrote:

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

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150411/09ccc89b/attachment.sig>