X Server

Aus TippvomTibb
Zur Navigation springen Zur Suche springen

Problem

Habe gerade das Problem, dass ein Rechner mit einer NVIDIA GTX1050Ti (2 DVI, 1 HDMI, 1 DP) an der nur an HDMI ein Monitor angeschlossen ist, nach einem Bildschirm-TimeOut die Ausgabe nicht auf HDMI aktiviert. Ein Ausstecken und wieder Einstecken aktiviert den Montor wieder. Auf Dauer ist da aber keine Loesung. Wenn ich mich mit SSH auf den Rechner einlogge, quittiert xrandr zum Umschalten/Einschalten des Displays allerdings die Eingabe mit einem "Can't open DISPLAY". Das gleiche Problem hatte ich vor Jahren schon mal mit ferngesteuerten Schwarzen Brettern (Signature Displays). Ich kann mich nur noch dunkel an die Loesung erinnern, deshalb hier ein paar Gedankenstuetzen.

Ein weiteres Problem, beim Betrieb von mehreren Monitoren, habe ich hier beschrieben.

Loesungshinweise

  • Der Login ueber SSH muss/sollte mit dem gleichen Benutzer erfolgen unter dem der X-Server laeuft.
  • Den Befehlen wird/kann ein DISPLAY=:0.0 vorangestellt/werden. Dazu unten mehr.

Erst mal herausfinden welche Screens oder Display gibt es denn ueberhaupt. 

worker:/home/chris # export |grep DISP
declare -x DISPLAY=":0"

worker:/home/chris # export |grep XAUTH
declare -x XAUTHLOCALHOSTNAME="worker"
declare -x XAUTHORITY="/root/.xauthzQiHUM"

chris@worker:~> ps axu |grep X
root      2471  0.0  0.2 6886860 279712 tty2   Ssl+ Nov27   2:58 /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_qnDYsZ -noreset -displayfd 16

chris@server:/root> ps axu |grep X
root      9204  0.3  0.4 25577276 225592 tty7  Ssl+ Nov26  12:46 /usr/bin/X -nolisten tcp -auth /run/sddm/{e639dd90-50a8-4714-847c-c0f83977379d} -background none -noreset -displayfd 17 -seat seat0 vt7

Interessanterweise laeuft bei meinem Arbeitsplatzrechner (openSUSE 15.6) das virtuelle Terminal unter tty2, bisher war es standardmaeszig tty7.

Programme, die etwas mit X(Xorg) zu tun haben. 

X(7), Xserver(1), xdm(1), xinit(1), xorg.conf(5), xvidtune(1), xkeyboard-config (7), apm(4), ati(4), chips(4), cirrus(4), cyrix(4), fbdev(4), glide(4), glint(4), i128(4), i740(4), imstt(4), intel(4),  mga(4),  neo-magic(4),  nsc(4),  nv(4),  openchrome  (4),  r128(4),  rendition(4), s3virge(4), siliconmotion(4), sis(4), sunbw2(4), suncg14(4), suncg3(4), suncg6(4), sunffb(4), sunleo(4), suntcx(4), tdfx(4), tga(4), trident(4), tseng(4), v4l(4), vesa(4), vmware(4)

Die DISPLAY-Variable hat die Form H:D.S

  • Hostname default localhost, bzw. Socket
  • Display
  • Screen
Ein Display bezeichnet die gesamte Anzeigeumgebung, die durch einen X11-Server verwaltet wird. Ein X11-Server kann mehrere Displays unterstützen, die auf verschiedenen physikalischen Geräten oder auf verschiedenen Monitoren eines Systems laufen.

Ein Display besteht in der Regel aus einer Kombination von Hardware (Monitoren, Grafikkarten) und Software (dem X11-Server), die zusammen eine grafische Oberfläche bieten. 

Ein Screen ist ein einzelner virtueller Monitor innerhalb eines Displays, der auf mehrere physikalische Monitore aufgeteilt sein kann.

Da es in der Regel nur ein Display und einen Screen gibt, wird die DISPLAY-Variable verkuerzt mit :0 angegeben. 

declare -x DISPLAY=":0"

Folgender Befehl listet die aktiven Screens, Displays auf. 

cd /tmp/.X11-unix && for x in X*; do echo ":${x#X}"; done

Das echo plaziert noch einen Doppelpunkt davor und #X formatiert noch. [1]

Dieses kleine Bash-Script listet alle Screen-Sockets im Verzeichnis /tmp/.x11-unix auf. 

chris@server:/tmp/.X11-unix> ll X*
srwxrwxrwx 1 root root 0 Nov 26 20:40 X0

xdpyinfo scheint der richtige Weg zu sein. 

chris@worker:/tmp/.X11-unix> xdpyinfo | grep -A4 '^screen'
screen #0:
 dimensions:    7680x2160 pixels (1227x352 millimeters)
 resolution:    159x156 dots per inch
 depths (7):    24, 1, 4, 8, 15, 16, 32
 root window id:    0x23f

Mit inxi -Ga erhaelt man noch mehr Klarheit, obwohl das ssh-Terminal im Gegensatz zum loakalen Terminal, die Screens nicht anzeigt.

server:/etc/X11 # inxi -Ga 

Graphics:
 Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti] vendor: ASUSTeK driver: nvidia
   v: 550.135 alternate: nouveau,nvidia_drm non-free: 530.xx+
   status: current (as of 2023-05) arch: Pascal code: GP10x
   process: TSMC 16nm built: 2016-21 pcie: gen: 1 speed: 2.5 GT/s lanes: 16
   link-max: gen: 2 speed: 5 GT/s ports: active: none off: DP-1,HDMI-A-1
   empty: DVI-D-1,DVI-D-2 bus-ID: 0f:00.0 chip-ID: 10de:1c82 class-ID: 0300
 Display: server: X.Org v: 1.21.1.11 with: Xwayland v: 24.1.1
   compositor: kwin_x11 driver: X: loaded: nvidia gpu: nvidia,nvidia-nvswitch
   display-ID: :0 screens: 3 default screen: 0
 Screen-1: 0 s-res: 1920x1080 s-dpi: 93 s-size: 524x292mm (20.63x11.50")
   s-diag: 600mm (23.62")
 Monitor-1: DP-1 note: disabled pos: primary
   model: HannSpree/HannStar HE247DPB serial: 123456789XXXX built: 2012
   res: 1920x1080 hz: 60 dpi: 94 gamma: 1.2 size: 521x293mm (20.51x11.54")
   diag: 598mm (23.5") ratio: 16:9 modes: max: 1920x1080 min: 640x480
 Monitor-2: HDMI-A-1 mapped: DVI-D-1 note: disabled model: Sony TV
   serial: 168XXXXX built: 2007 res: 1920x1080 dpi: 30 gamma: 1.2
   size: 1600x900mm (62.99x35.43") diag: 1836mm (72.3") ratio: 16:9 modes:
   max: 1920x1080 min: 640x480
 Screen-2: 1 s-res: 1920x1080 s-dpi: 30 s-size: 1626x914mm (64.02x35.98")
   s-diag: 1865mm (73.44")
 Screen-3: 2 s-res: 640x480 s-dpi: 75 s-size: 217x163mm (8.54x6.42")
   s-diag: 271mm (10.69")
 API: OpenGL v: 4.6.0 NVIDIA 550.135 renderer: NVIDIA GeForce GTX 1050
   Ti/PCIe/SSE2 direct-render: Yes

Die Kernelmodul-Parameter sind bei mir z.B. auf dem Server (GTX1050Ti) und dem Worker (Quadro M2000)identisch. 

chris@server:~> cat /proc/driver/nvidia/params
ResmanDebugLevel: 4294967295
RmLogonRC: 1
ModifyDeviceFiles: 1
DeviceFileUID: 0
DeviceFileGID: 483
DeviceFileMode: 432
InitializeSystemMemoryAllocations: 1
UsePageAttributeTable: 4294967295
EnableMSI: 1
EnablePCIeGen3: 0
MemoryPoolSize: 0
KMallocHeapMaxSize: 0
VMallocHeapMaxSize: 0
IgnoreMMIOCheck: 0
TCEBypassMode: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
NvLinkDisable: 0
RmProfilingAdminOnly: 1
PreserveVideoMemoryAllocations: 1
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
RegisterPCIDriver: 1
EnablePCIERelaxedOrderingMode: 0
EnableResizableBar: 0
EnableGpuFirmware: 18
EnableGpuFirmwareLogs: 2
EnableDbgBreakpoint: 0
OpenRmEnableUnsupportedGpus: 1
DmaRemapPeerMmio: 1
ImexChannelCount: 2048
RegistryDwords: ""
RegistryDwordsPerDevice: ""
RmMsg: ""
GpuBlacklist: ""
TemporaryFilePath: ""
ExcludedGpus: ""

Einstellen kann man die Parameter unter /etc/modprobe.d mit einem conf-File.


xauth

Gleicher Rechner einmal als Hauptbenutzer und einmal als root. 

chris@worker:~> xauth
Using authority file /home/chris/.xauthFAgo86
xauth> list
worker/unix:0  MIT-MAGIC-COOKIE-1  4608d1c4cf9a0d32e9b31fe3a04e768d
#ffff##:0  MIT-MAGIC-COOKIE-1  4608d1c4cf9a0d32e9b31fe3a04e768d
xauth> 

worker:/home/chris # xauth
Using authority file /root/.xauthzQiHUM
xauth> list
worker/unix:0  MIT-MAGIC-COOKIE-1  4608d1c4cf9a0d32e9b31fe3a04e768d
#ffff##:0  MIT-MAGIC-COOKIE-1  4608d1c4cf9a0d32e9b31fe3a04e768d
xauth>

Was auffaellt:

  • Das Authority-File liegt unter home.
  • Der Name des Authority-Files wird gebildet, beginnend mit Punkt gefolgt von xauth und einem 6-stelligen Zufallsstring.

Das ist deswegen bemerkenswert, da auf meinem Server, beim root-Nutzer, dies nach den gleichen Regeln erkennbar ist. Beim Hauptnutzer aber nicht!

Dort lag das Auhority-File unter /run/user/1000 und begann, ohne Punkt, mit xauth, Unterstrich und einem 6-stelligen Zufallsstring.

Ein "Mitbenutzen" des Xauth-Files fuehrt zum Fehler. 

xauth: error in locking auhority file ...

Das MAGIC-COOKIE ist fuer beide Nutzer gleich.

Loesung

Das Vorgehen, welches bei mir den gewuenschten Erfolg erbracht hat, war im ersten Schritt, zum Testen, den Zugriff fuer jeden freizuschalten. Dazu benutze ich das Programm xhost (Das musste ich noch nachinstallieren: zypper in xhost) 

worker:/home/chris # xhost +
access control disabled, clients can connect from any host

Dies muss allerdings in einem Terminal in der X-Umgebung stattfinden. Erst dann hat man den Zugriff, z.B. mit xrandr von der Konsole, oder per SSH.Besser ist es natuerlich nur einem Nutzer dieses Recht einzuraeumen. 

xhost +SI:localuser:username

Durch Fernbedienbarkeit kann ich nun den Monitor wieder aufwecken, ohne das HDMI-Kabel aus-/einzustecken.

Xrandr zeigte den Monitor als 'active' und 'connected'.

Wenn ich die Aufloesung mit mode kurz umschalte ist das Bild wieder da. Also stimmt irgendwas mit dem Timing nicht, oder vielleicht ist sogar das Kabel daran schuld. 

chris@server:~> DISPLAY=:0 xrandr --output HDMI-0 --mode 1920x1080
chris@server:~> DISPLAY=:0 xrandr --output HDMI-0 --mode 3840x2160

Loesung dauerhaft

Das Dumme an der o.g. Loesung ist, dass die Freigabe durch xhost ein reboot nicht ueberlebt.

Ein Hinweis im Internet meint den entsprechenden Eintrag in /etc/X0.hosts vorzunehmen. Eine solche Datei existiert bei meiner Distri (openSuSE 15.6) nicht.

Ein Mitstreiter meint dazu: 


X0.hosts ignored and also ssh login problem with X apps

    I have just downloaded and installed the 32 bit server version on a couple of machines.

    These machines are remote displays, no keyboards or mice, requiring a kick of from ssh to start the app. Its just bare sever install with TWM, X, and XDM.

    Problem is they don't seem to read my /etc/X0.hosts file until theres been a keyboard login. After that locally xhost returns the names from the file.

    I removed the exec /usr/bin/X -nolisten tcp "$@" line
    from /etc/X11/xinit/xserverrc but this also is no help. 

    In the user .profile I have these 2 lines,

    DISPLAY='0.0'
    xhost +

    This is a real chicken and egg thing, no auto login, no keyboard for login and no ssh X access before a local login. And no easy way to make it auto login with out installing GWM.

    Is there something else to be done with this new Xorg release to enable starting an app on X by ssh?

   Harry 

    fixed silly typo

    DISPLAY=:0.0;
    export DISPLAY

Die Freigabe mit xhost wird durchweg aus Sicheheitsgruenden nicht empfohlen. In der Regel wird ein ssh-X-Tunnel (ssh -XY) vorgeschlagen.

Beifang

Bei der Recherche habe ich gerade noch ein netten kleines Tool gefunden. 

worker:/home/chris # hostnamectl 
Static hostname: worker
      Icon name: computer-desktop
        Chassis: desktop 🖥
     Machine ID: 3423XXXXXXXXXXXXXXXXXXXXXXXe0fea
        Boot ID: 722dXXXXXXXXXXXXXXXXXXXXXXX77dd5
Operating System: openSUSE Leap 15.6              
    CPE OS Name: cpe:/o:opensuse:leap:15.6
         Kernel: Linux 6.4.0-150600.23.25-default
   Architecture: x86-64
Hardware Vendor: Hewlett-Packard
 Hardware Model: HP Z840 Workstation
Firmware Version: M60 v02.62
  Firmware Date: Thu 2024-01-04
   Firmware Age: 10month 3w 5d

Noch ein nettes Tool. 

chris@server:~> loginctl session-status
11 - root (0)
          Since: Fri 2024-11-29 17:49:35 CET; 2h 32min ago
         Leader: 9216 (sshd)
            TTY: pts/3
         Remote: 192.168.178.218
        Service: sshd; type tty; class user
          State: active
           Unit: session-11.scope
                 ├─  1807 loginctl session-status
                 ├─  1808 less
                 ├─  9216 "sshd: root [priv]" "" "" ""
                 ├─  9234 "sshd: root@pts/3" "" "" "" ""
                 ├─  9238 -bash
                 ├─ 32710 su chris
                 └─ 32711 bash
Abgerufen von „https://tippvomtibb.de/wiki/index.php?title=X_Server&oldid=3809“