[gelöst] Nur ein Bildschirm funktioniert will aber beide benutzen

[MaGe]

Wenn Du den propritären Nvidia Treiber nutzen willst, erfordert das zwingend eine xorg.conf. Dabei

Und da bist du dir sicher?
Die xorg.conf existiert standardmäßig nicht mehr.
Bei mir gibt es keine, mit nvidia



gruss MaGe

[KP97]

@MaGe
Ja, bin ich. Zumindest war das so, als ich noch eine zusätzliche Nvidiakarte im Rechner hatte. Das ist aber schon mehr als 10 Jahre her, ich nutze ausschließlich Intel auf dem Board.
Und so ist es auch bei einem Bekannten, der eine Nvidiakarte nutzt. Ohne xorg.conf übernimmt nouveau den Dienst.
In meinem Eigenbaukernel habe ich das nicht gesetzt, da ich diese Hardware nicht habe. In einem Standardkernel wird das aber aktiv sein.

# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set
# CONFIG_DRM_NOUVEAU is not set

Ich habe für meine Intelgrafik das Paket xserver-xorg-video-intel installiert, weil ich den Standardtreiber modesetting nicht will.
Daher habe ich auch eine entsprechende xorg.conf angelegt:

Section "Device"
Identifier "Intel"
Driver "intel"
EndSection

Wenn ich das auskommentiere, kommt modesetting zum Einsatz, wie bereits geschrieben.
Das kann ich im Xorg.0.log ablesen.

Warum bei Dir Nvidia ohne xorg.conf läuft, k.A. Ich frag jetzt zurück: Bist Du sicher?...;-)

@TE
Schau in Dein Xorg.0.log, zu finden im Homeverzeichnis ~/.local/share/xorg

[debiankaios]

Das ist aber schon mehr als 10 Jahre her, ich nutze ausschließlich Intel auf dem Board.

Habe auch gehört das man erst sein 2014 keine xorg.conf mehr braucht. Davor war das zwingend.

[MSfree]

Habe auch gehört das man erst sein 2014 keine xorg.conf mehr braucht. Davor war das zwingend.

Du weißt, daß das Quatsch ist. Zufällig habe ich hier noch ein laufendes Jessie, das ich 2013, als es noch Testing war, installiert habe: keine xorg.conf. Und auch Etch, das ich ursprünglich auf meinem Core2-Q9300 hatte, hat keine corg.conf benötigt. Die EeePC von 2008 mit dem ursprünglichen Xandros Linux kamen auch ohne xorg.conf aus...

[debiankaios]

OK dann habe ich vielleich das datum verlessen, war vielleicht auch 2004. Auf jeden fall braucht man schon lange keine mehr. Aber zurück zum Hauptprobelm: Die Abstürze nerven wenn man mitten in einer sache ist. Und ich weis immer noch nicht was sie verursacht!

[KP97]

@debiankaios
Warum weigerst Du Dich eigentlich beharrlich, die erbetenen Infos zu liefern? Die Frage nach z.B. der Xorg.0.log blieb unbeantwortet.
Auch eine ganze Ausgabe von inxi -F wäre hilfreich, denn aus Deinen halben Beschreibungen wird niemand so richtig schlau.
Das motiviert etwaige Helfer nicht sonderlich...

[debiankaios]

Upps! Sorry habe ich überlessen
Xorg.0.log: https://nopaste.debianforum.de/41611
Und inxi -F:

Code: Alles auswählen

System:
  Host: debiankaios Kernel: 5.10.0-12-amd64 x86_64 bits: 64 
  Desktop: Xfce 4.16.0 Distro: Devuan GNU/Linux 4 (chimaera) 
Machine:
  Type: Desktop Mobo: ASRock model: Z590M Phantom Gaming 4 
  serial: <superuser required> BIOS: American Megatrends LLC. v: P1.80 
  date: 07/26/2021 
CPU:
  Info: Quad Core model: Intel Core i3-10105F bits: 64 type: MT MCP 
  L2 cache: 6 MiB 
  Speed: 800 MHz min/max: 800/4400 MHz Core speeds (MHz): 1: 800 2: 800 
  3: 800 4: 800 5: 800 6: 802 7: 800 8: 799 
Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 730] driver: nouveau v: kernel 
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting 
  unloaded: fbdev,vesa resolution: 1: 1280x1024~60Hz 2: 1280x1024~60Hz 
  OpenGL: renderer: NV106 v: 4.3 Mesa 20.3.5 
Audio:
  Device-1: Intel driver: snd_hda_intel 
  Device-2: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel 
  Device-3: Sunplus Innovation Full HD webcam type: USB 
  driver: snd-usb-audio,uvcvideo 
  Sound Server: ALSA v: k5.10.0-12-amd64 
Network:
  Device-1: Intel Ethernet I219-V driver: e1000e 
  IF: eth0 state: up speed: 100 Mbps duplex: full mac: a8:a1:59:93:f9:25 
Drives:
  Local Storage: total: 1.82 TiB used: 21.13 GiB (1.1%) 
  ID-1: /dev/sda vendor: Samsung model: SSD 870 QVO 2TB size: 1.82 TiB 
Partition:
  ID-1: / size: 22.75 GiB used: 6.51 GiB (28.6%) fs: ext4 dev: /dev/dm-0 
  ID-2: /boot size: 469.4 MiB used: 83.2 MiB (17.7%) fs: ext2 dev: /dev/sda1 
  ID-3: /home size: 422.42 GiB used: 13.8 GiB (3.3%) fs: ext4 dev: /dev/dm-4 
  ID-4: /tmp size: 1.79 GiB used: 48 KiB (0.0%) fs: ext4 dev: /dev/dm-3 
  ID-5: /var size: 9.07 GiB used: 755.8 MiB (8.1%) fs: ext4 dev: /dev/dm-1 
Swap:
  ID-1: swap-1 type: partition size: 976 MiB used: 0 KiB (0.0%) 
  dev: /dev/dm-2 
Sensors:
  System Temperatures: cpu: 30.0 C mobo: N/A gpu: nouveau temp: 43.0 C 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 225 Uptime: 49m Memory: 15.5 GiB used: 4.21 GiB (27.1%) 
  Shell: Bash inxi: 3.3.01 

[willy4711]

Habe mich für die Neuinstallation entschieden.nouveau runter, neustart und dann kommt die grafische Oberfläche nicht mehr…

Also eine Nvidia ohne die entsprechenden Treiber / Pakete zu betreiben ist schlichtweg Blödsinn.
Was heißt denn "nouveau runter"
Hast du die Pakete xserver-xorg-video-nouveau und libdrm-nouveau2 deinstalliert ??

Das hat alles ziemlich wenig Sinn, was hier passiert.

Installiere den Nvidia-Treiber und melde dich dann wieder. alles andere ist verlorene Zeit, und sinnloses Diskutieren.

Code: Alles auswählen

apt install nvidia-driver nvidia-settings

[KP97]

Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting

Was ich schon vermutet und geschrieben habe. Das wird nix.
Mach das so, wie Willy gesagt hat, alles andere ist vertane Zeit.
Und auf dem Board ist entgegen Deiner Vermutung keine Intel Grafik, daher mußt Du der Karte auch einen passenden Treiber spendieren.

[baeuchlein]

Ich würde auch empfehlen, den X.Org-Treiber "xserver-xorg-video-nouveau" für nVidia zu installieren - und zwar denjenigen von Devuan, nicht irgendeinen direkt von nVidia heruntergeladenen Treiber!

Danach kann man die grafische Oberfläche erneut starten und sich die inxi-Ausgabe und auch Xorg.0.log ansehen. Achtung, Letzteres kann sowohl in /var/log/ erscheinen als auch in ~/.local/share/xorg/ - das ist vom jeweils von X geladenen Treiber abhängig! Ich würde da auch in der Konsole oder einem xterm-Fenster mit dem Befehl ls -lahtr /var/log/Xorg.0.log und ls -lahtr ~/.local/share/xorg/Xorg.0.log nachsehen, welche Datumsangaben die Dateien haben. Wenn es zwei Dateien Xorg.0.log gibt, wurde die ältere wahrscheinlich bei einem früheren X-Start erzeugt, aber nicht vom letzten (und das ist derjenige, der uns interessiert). Und es kann dann auch sein, dass inxi die falsche (ältere) Xorg.0.log-Datei ausliest und daraus falsche Angaben bezüglich Grafikkarte und Treiber ableitet - hab' ich alles schon mal gesehen hier.

Wenn dann laut inxi bzw. Xorg.0.log dieser nouveau-Treiber für X nicht benutzt wird, müsste man mal sehen, weswegen nicht bzw. welcher X-Treiber stattdessen genutzt wird. Eventuell muss man dann wirklich eine eigene Datei /etc/X11/xorg.conf anlegen. Ich selber muss das sehr häufig tun, weil die eine oder andere Hardware von X.Org nicht automatisch richtig erkannt wird. Da ist X nämlich auch nicht perfekt, auch wenn es bei vieler aktueller Hardware funktionieren mag, so dass dann keine xorg.conf nötig ist.

[KP97]

Achtung, Letzteres kann sowohl in /var/log/ erscheinen als auch in ~/.local/share/xorg/ - das ist vom jeweils von X geladenen Treiber abhängig!

Nein, in Debian wird alles von systemd gesteuert, der X Server läuft also unter dem User, daher ist das Log im Home des Users zu finden.
Früher, vor systemd, lief der X Server als Root, daher auch das Log im /var/log. Der jeweilige Treiber hat da keinen Einfluß.
Wie es bei Devuan aussieht weiß ich nicht, da ich dieses System nicht nutze.

Inxi liefert keine falschen Angaben, das halte ich für äußerst unwahrscheinlich...

[MSfree]

Nein, in Debian wird alles von systemd gesteuert, der X Server läuft also unter dem User, daher ist das Log im Home des Users zu finden.

Jein.

Der Loginscreen benötigt bereits einen Xserver und der läuft auch unter systemd mit root-Rechten. Erst mit dem Login werden die privilegierten Rechte runtergestuft. Folglich findet man in /var/log nach wie vor eine Xorg.0.log.

[KP97]

Folglich findet man in /var/log nach wie vor eine Xorg.0.log.

In Deinem System vielleicht, in meinem definitiv nicht, und das schon seit einer Ewigkeit.
Und nein, mein Sid hat keinen Fehler und läuft tadellos, auch schon seit einer Ewigkeit.

[MSfree]

In Deinem System vielleicht, in meinem definitiv nicht, und das schon seit einer Ewigkeit.

Wayland?

[KP97]

Nein, ich nutze Xfce, das hat noch kein Wayland.
Aber ich habe keinen Display-Manager im Einsatz, die ja bekanntlich startx verwenden Aber kann eigentlich auch nicht sein, das bezieht sich ja auf das xserver-log...
Hm na ja, bei mir ist jedenfalls nichts in /var/log.

[MSfree]

Aber ich habe keinen Display-Manager im Einsatz

Der Displaymanager braucht einen mit root-Rechten laufenden Xserver. Wenn du keinen nutzt, ist es klar, daß du keine Xorg.0.log unter /var/log findest.

[KP97]

Na dann...ich war bei startx immer nur vom xsession-log ausgegangen, was ich auch nicht habe, weil ich startxfce4 nutze. Das legt keine Logdatei an.
Dann sind wir uns ja einig...;-)

[baeuchlein]

Ich verwende startx zum Start von X, und statt eines Displaymanagers nutze ich nur einen Fenstermanager (fluxbox). Und da ist es so, wie ich es schrieb: Je nach verwendetem Treiber landet die Xorg.0.log in verschiedenen Verzeichnissen. AMDGPU und Radeon legen sie in ~/.local/share/xorg/ ab, vesa und fbdev in /var/log/. Ich habe es extra unter Debian 11.2 noch unmittelbar vor dem Posten nachgeprüft.

Dass inxi u.U. die falsche Xorg.0.log auswertet, und dass es auch sonst schon mal über verwirrende Angaben in dieser Log-Datei stolpert, habe ich ebenfalls vor Kurzem erst gesehen/ausprobiert. Eines der ersten Postings des Threadstartes enthielt meines Wissens auch Ausgaben von inxi, denen zufolge nouveau und vesa zugleich als Treiber genutzt würden. Wäre mir neu, dass X zwei Treiber zugleich nutzen kann.

Kann sein, dass solche Dinge auf euren Systemen aus irgendeinem Grund nicht auftreten, aber bei mir schon. Und was dann beim Threadstarter passiert, das wissen wir wohl kaum - wir haben ja schon Probleme zu verstehen, welchen Kernel-Support und welchen Treiber er überhaupt benutzt. Insofern rate ich weiter davon ab, diese Probleme einfach vom Tisch zu wischen, nur weil man selber sie nicht hat.

[debiankaios]

Code: Alles auswählen

deb http://deb.devuan.org/merged chimaera main
deb-src http://deb.devuan.org/merged chimaera main

deb http://deb.devuan.org/merged chimaera-security main contrib non-free
deb-src http://deb.devuan.org/merged chimaera-security main contrib non-free

deb http://deb.devuan.org/merged chimaera-updates main contrib non-free
deb-src http://deb.devuan.org/merged chimaera-updates main contrib non-free

und:

Code: Alles auswählen

$ sudo apt install nvidia-driver nvidia-settings
[sudo] Passwort für debiankaios: 
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paket nvidia-driver ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.

E: Für Paket »nvidia-driver« existiert kein Installationskandidat.
E: Paket nvidia-settings kann nicht gefunden werden.

[baeuchlein]

Tja. Das hatten wir auf der ersten Seite im Thread schon mal, mein' ich. Ich befürchte, dass entweder irgendwas im Devuan-System kaputt gegangen ist, oder aber dass Devuan hier anders funktioniert als Debian. In Letzterem gibt es "nvidia-driver" als Installationspaket definitiv, ich hab's gerade unter Debian 11.2 noch mal nachgeprüft.

Sollte keiner eine Idee haben, wie man "nvidia-driver" aus den Devuan-Paketquellen installieren kann, dann könnte man es noch mit dem anderen nVidia-Treiber, unter Debian als "xserver-xorg-video-nouveau" in der Paketliste vorhanden, probieren. Das ist der X-Treiber "nouveau", nicht der Kernel-Support namens "nouveau".

Kann man auch den nouveau-X-Treiber nicht aus den Devuan-Paketquellen installieren, dann wär's vielleicht doch mal 'ne gute Idee, Kompatibilitäts-Alternativen wie "vesa" oder "fbdev" auszuprobieren.

EDIT: Willys folgender Beitrag könnte das Problem mit dem "nvidia-driver" lösen. Ich hatte ganz vergessen, die sources.list mal mit dem zu vergleichen, was man auf www.devuan.org so findet.

[willy4711]

Code: Alles auswählen

deb http://deb.devuan.org/merged chimaera main
deb-src http://deb.devuan.org/merged chimaera main

Ich nehme mal an, dass das das Hauptrepo ist.
Da fehlt

Code: Alles auswählen

 contrib non-free

[debiankaios]

Hat funktioniert und es läuft jetzt auch flüssiger. Und bisher kamen noch keine Abstürze vor(ich habe es mit was ausprobiert wo normalerweise immer Abstürze kamen) Aber ich habe den neuen Treiber auch erst 10 Minuten…

[debiankaios]

Der Nvidiatreiber ist perfekt außer ein Problem: es dauert sehr lange(20-60 sekunden) zum wechseln der ttys was ich oft tue.

[willy4711]

es dauert sehr lange(20-60 sekunden) zum wechseln der ttys was ich oft tue.

Seltsam.
Vielleicht mal das Journal mitlaufen lassen ? Ach so gibt es bei dir ja nicht.
Musst also selber gucken, in welchem Log das steht.

Oder mal ~/.xsession-errors nachsehen.

[debiankaios]

Hoffe ich kann wieder posten:
Die nividia-treiber klappen super nur das wechseln der ttys kann lang dauern.