← Back to team overview

sslug-teknik team mailing list archive

RE: Underlig $DISPLAY i X

 

Uddrag fra X11.R5 X-lib source (jeg har ikke nyere i naerheden, men jeg tror
ikke der er sket aendringer paa dette punkt), file XConnDis.c, siger
foelgende ..

 * Attempts to connect to server, given display name. Returns file
descriptor
 * (network socket) or -1 if connection fails.  Display names may be of the
 * following format:
 *
 *     [hostname] : [:] displaynumber [.screennumber]
 *
 * The second colon indicates a DECnet style name.  No hostname is
interpretted
 * as the most efficient local connection to a server on the same machine.
 * This is usually:
 *
 *     o  shared memory
 *     o  local stream
 *     o  UNIX domain socket
 *     o  TCP to local host

og senere inde i routinen

     * At this point, we know the following information:
     *
     *     phostname                hostname string or NULL
     *     idisplay                 display number
     *     iscreen                  screen number
     *     dnet                     DECnet boolean
     *
     * We can now decide which transport to use based on the ConnectionFlags
     * build parameter the hostname string.  If phostname is NULL or equals
     * the string "local", then choose the best transport.  If phostname
     * is "unix", then choose BSD UNIX domain sockets (if configured).
     *
     * First, choose default transports:  DECnet else (TCP or STREAMS)

og endvidere hvis Xlib configureres med unix sockets ..

     * Now that the defaults have been established, see if we have any
     * special names that we have to override:
     *
     *     :N         =>     if UNIXCONN then unix-domain-socket
     *     ::N        =>     if UNIXCONN then unix-domain-socket
     *     unix:N     =>     if UNIXCONN then unix-domain-socket
     *
     * Note that if UNIXCONN isn't defined, then we can use the default
     * transport connection function set above.

Sjovt nok siger "man XOpenDisplay" ikke noget reserverede host navne.

Det er derfor korrekt af startx at definere DISPLAY=:0 for at lokale
clienter vaelger den bedste (hurtigste) IPC metode. Hvis den bedste IPC
metode saa viser sig at vaere en unix socket, saa vil :0 vaere identisk med
unix:0. 

Rapporter det som en fejl til 'maintainer'ne af de 2 programmer der volder
problemer. Et hack kunne vaere en linie i .profile i stil med ..

test x"$DISPLAY" = xunix:0 && {
  DISPLAY=:0
  export DISPLAY
}

men det vil ikke redde situationen for programmer der startes direkte fra
fvwm2.

Mvh.
Kurt Alstrup

-----Original Message-----
From: torben fjerdingstad [mailto:tfj@xxxxxxxxxxxxxxx]
Sent: Thursday, January 06, 2000 12:30 PM
To: sslug-teknik@xxxxxxxx
Subject: Re: [TEKNIK] Underlig $DISPLAY i X


> torben fjerdingstad wrote:
> 
> > Jeg kan ikke forstår hvorfor mit X DISPLAY er sat til unix:0.0.
> > Min host hedder noget helt andet. Det er redhat-6.1.
> > Jeg bruger startx til at starte serveren med.
> 
> Hos mig er variablen slet ikke sat hvis jeg ikke selv
> sætter den i en passende shell-opstartsfil.

Det er debian, ikke!?

> Måske redhat har lavet noget sjov i en af sysconfig filerne
> eller andet steds. Eller det er nogle af de globale xsession/xinit
> filer ?

Jeg kan bare ikke finde det. Men jeg har fundet ud af at fejlen
ligger i fvwm2. Der står faktisk i manualsiden at den sætter
DISPLAY til unix:0.0 eller :0.0. Men der står ikke hvordan man
kan styre det, eller hvordan den afgør det :-(
Der er intet at finde om det i dot filer eller system.fvwm2rc.

> Sæt selv variablen til noget fornuftigt i /etc/profile
> eller /etc/csh.login eller i dine lokale udgaver under ~/

/etc/profile ved da ikke om jeg senere har tænkt mig at
starte X eller ej. Og $DISPLAY bruges af en del applikationer,
f.eks. linuxconf, rundoom, .. for at afgøre om man har
et X display.

startx er et script, og det sørger faktisk for at starte
serveren med :0 som default. Men jeg vil ikke være med
til at rette i det da det ikke er en konfigurationsfil,
og da den derfor bliver overskrevet uden backup ved
næste opgradering.

Så jeg er faktisk på bar bund. Jeg kan godt finde på
et hack, men jeg vil hellere have en løsning.

-- 
torben fjerdingstad        | linux-2.2.10-smp/GNU/gnome-1.0
tfj@xxxxxxxxxxxxxxx        | linux får den op og stå