ledy
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
Hi neben einer eingebauten Grafikkarte mit intel Treiber ist noch ein Displaylink USB2.0 im Einsatz.
Leider ist Unity nahezu eingefroren und sehr langsam im Dual Screen Modus.
Dabei ist aufgefallen, dass die intel Karte ohne Acceleration genutzt wird. Mit einer xorg.conf.d/20-intel.conf lässt sich das beheben.
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "AccelMethod" "sna"
EndSection
Leider funktioniert dadurch allerdings kein Dual Screen mehr, denn die Displaylink USB Grafikkarte wird nicht mehr geladen.
Diese benötigt fbdev als Treiber. Um zu vermeiden, dass der falsche Treiber verwendet wird, habe ich auch versucht:
Section "Device"
Identifier "Card0"
Driver "Intel"
Option "AccelMethod" "sna"
BusID "PCI:0:2:0"
EndSection
Weiterhin wird die USB Karte ignoriert. Also teste ich auch noch mit zusätzlicher Section:
Section "Device"
Identifier "DisplayLink"
Driver "fbdev"
BusID "USB"
EndSection
was ebenfalls nicht weiterhilft. Sobald die intel Section wieder deaktiviert wird, funktioniert die Erkennung der 2. Karte, aber Dual Screen bleibt unbenutzbar ohne Acceleration. Wie kann Xorg so konfigurieren, dass die autom. Erkennung weiterhin funktioniert, und dennoch der zusatz AccelMethod für die intel Karte am PCI Bus verwendet wird? Danke und Gruß PS: Ohne Compiz funktioniert die Erkennung perfekt. MATE kann somit ohne xorg config starten, erkennt alles korrekt und läuft flüssig. Sobald Compiz statt Metacity/Macro o.ä. verwendet wird, scheitert es bei mir.
Bearbeitet von Letalis Sonus: Bitte verwende in Zukunft Codeblöcke, um die Übersicht im Forum zu verbessern. Danke!
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
▶ „Welche Angaben zum System sind für ein neues Thema nötig?“ Man muss beachten, dass das DisplayLink Teil als vollwertige eigenständige Grafikkarte behandelt wird und somit alle damit zusammenhängenden Beschränkungen ebenfalls zutreffen, insbesondere da die DisplayLink Chips keinerlei Hardware-Beschleunigung anbieten. Man sollte daher von der xorg.conf einfach komplett die Finger lassen, den X Server sich selbst konfigurieren lassen und die Verwendung der Bildschirme schlicht und ergreifend mit dem jeweiligen Konfigurationsprogramm der Desktopumgebung einrichten. Der kritische Punkt in der Konfiguration liegt in der Verwendung von DMA-Buf für das Anflanschen des DisplayLink Monitors, damit der Intel Chip den gesamten Desktop rendert und den entsprechenden Teil an den DisplayLink Chip weiterreicht. Das läuft hinter dem Rücken des X Servers ab und wird schlicht und ergreifend wie üblich über RandR konfiguriert. ledy schrieb: PS: Ohne Compiz funktioniert die Erkennung perfekt. MATE kann somit ohne xorg config starten, erkennt alles korrekt und läuft flüssig. Sobald Compiz statt Metacity/Macro o.ä. verwendet wird, scheitert es bei mir.
Dann frickelst du wohl mit Xinerama rum, das ist mit der Composite Erweiterung inkompatibel, welche für Unity/Compiz zwingend benötigt wird. Xinerama ist neben diesem Manko aber auch so schon ziemlich fehlerbehaftet und sollte wenn möglich stets vermieden werden.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
Xinerama ist nicht installiert und auch wenn ich Mate nicht verwenden möchte, so funktioniert es dort out-of-the-box mackellos. Unter Mate spielt es auch keine Rolle, ob ich sämtliche Effekte, wie 3D oder Cube verwende, und scheinbar klappt es dort auch mit dem Framebuffer mit intel und displaylink. Wird Compiz mit Mate oder Gnome verwendet, sieht die Performance ebenso bescheiden aus wie beim Versuch mit Unity. Verstehe ich Deinen Hinweis richtig, dann ist RandR für die autom. Einstellung verantwortlich?
Ist es dabei möglich, die aktuell geladene bzw. automatisch vorgenommenen Einstellungen zu exportieren und anschließend in der anderen Umgebung wieder zu laden? lspci -nnk | grep "VGA\|'Kern'\|3D\|Display" -A2
00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b)
Subsystem: Lenovo Device [17aa:3978]
Kernel driver in use: i915
Displaylink USB2.0 (im aktivierten/funktionierenden Zustand, in Mate) T: Bus=01 Lev=03 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=17e9 ProdID=02ee Rev=01.03
S: Manufacturer=DisplayLink
S: Product=VGA Display Adapter
S: SerialNumber=721024
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=udl
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
Zum Vergleich im Anhang die xorg log jeweils nach dem Login mit Mate vs. Unity, beiden Displays aktiv und Unity unbenutzbar langsam auf beiden Screens (nicht nur der am Displaylink angeschlossenen Monitor) während Mate flüssig läuft. In beiden Logs sieht die Framebuffer Behandlung identisch aus: [ 1318.934] (II) FBDEV: driver for framebuffer: fbdev
...
[ 1324.191] (II) intel(0): resizing framebuffer to 3840x1080 Bin ich auf dem richtigen Weg oder müsste stattdessen eine andere Log (wo finde ich die Einstellungen von randr?) geprüft werden?
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
ledy schrieb: Zum Vergleich im Anhang die xorg log
...das musst du noch mal versuchen, der Anhang fehlt. ledy schrieb: Verstehe ich Deinen Hinweis richtig, dann ist RandR für die autom. Einstellung verantwortlich?
RandR ist nur ein Interface um die Anordnung der Bildschirme zu konfigurieren, die automatische Einrichtung übernimmt der X Server selbst. RandR selbst hat auch keinerlei gespeicherte Konfiguration, jede Desktopumgebung speichert die Konfiguration die über ihre eigenen Konfigurationsprogramme erstellt wurde auf ihre eigene Art und Weise ab und stellt sie nach dem Login über RandR wieder her.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
noch ein Versuch für den Anhang. Beim Editieren des Beitrags zeigt es den Anhang an, aber nicht öffentlich im Forum.
- xorg_mate-vs-unity.tar.gz (19.3 KiB)
- Download xorg_mate-vs-unity.tar.gz
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
Sieht eigentlich alles richtig aus... Vielleicht handelt es sich hierbei auch schlicht und ergreifend um einen Bug im Intel Treiber im Kontext von DMA-Buf/PRIME. fbdev wird übrigens nirgends verwendet, stattdessen wird der modeset Treiber genutzt, welcher im Gegensatz zu fbdev auch auf die vom Kernel Modul angebotenen Funktionen zurückgreifen kann.
Was ich mir auch vorstellen könnte: FullHD ist schon eine ziemlich große Belastung für so ein USB 2.0 Teil, da die Übertragungsgeschwindigkeit dafür eigentlich viel zu klein ist, weshalb das ganze nur mit Kompression annähernd brauchbar angesteuert werden kann. Ohne Compositing schreibt der X Server die Daten direkt auf den Framebuffer, hier werden bei einer fehlenden 2D Beschleunigung ganz gerne Tricks wie Shadow Buffering benutzt um die Schreibzugriffe zu minimieren. Wenn das ganze bei aktivem Compositing alles in Texturen gestopft und via OpenGL etc gerendert wird, dann wird stets das gesamte Bild neu aufgebaut - das verursacht möglicherweise auch einfach übermäßig viele Daten, die die USB Schnittstelle verstopfen. Im Arch Wiki findet sich sogar ein kurzer Eintrag zu Problemen mit Gnome 3 und einer zu kleinen Bildrate, die sich offenbar direkt auf diese Problematik bezieht: dort wird empfohlen ein einfacheres Hintergrundbild zu verwenden, was offensichtlich die Effizienz der Kompression steigern soll.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
Sieht eigentlich alles richtig aus...
Finde leider auch keinen Fehler, weshalb ich mich mit dem Issue an das Forum wende.
Beide configs sehen für mich so aus als würde das ebenso wieder der Framebuffer ohne Unterschied geladen werden. Am wenigsten kann ich allerdings das unterschiedliche Ergebnis je nach Window Manager, Compiz vs. Metacity bzw. alle nocht-Compiz Window Manager, die ja bestens funktionieren (auch mit 3D Spielereien).
Vielleicht handelt es sich hierbei auch schlicht und ergreifend um einen Bug im Intel Treiber im Kontext von DMA-Buf/PRIME.
Müsste dieser Bug dann nicht _immer_ auftreten anstatt nur in Kombination mit Compiz? Hatte gerade noch mit LiveCDs getestet, 32 und 64Bit, und die letzten 3 Versionen von Ubuntu. Sobald Compiz verwendet wird, klemmt es. Ein älteres Unity hat sich noch mit Alternative Window Manager testen lassen. Bei diesem funktioniert es tadellos. –-
FullHD
Sorry, wenn ich dem widerspreche, aber sobald Compiz ersetzt wird, liefert auch der OpenGL Benchmark und Texture Test ebenso wie die Videowiedergabe über beide Monitore hinweg sehr gute Ergebnisse. Versuche ich es mit Compiz im Hintergrund, kann ich die Pixel einzeln sehen. –- Eine Option wäre noch, die xorg.conf.d Section hinzubekommen, wobei das Problem war, dass nur die intel Karte geladen wird und die zweite nicht erkannt/geladen wird.
Gibt es eine Möglichkeit, die autom. Erkennung aktiviert zu lassen und nur für die Karte mit intel Treiber die Option anzuhängen? Ein Versuch war auch "Xorg --configure" erzeugt auch nur eine nutzlose config, die keine 2. Karte enthält. Ansonsten würde ich dort die Section der 2. Karte übernehmen und in einer weiteren config in xorg.conf.d vorgeben. Hättest Du sonst noch eine Idee oder einen Tipp, denn ich fürchte, dass ein Franebuffer Bug eine Sackgasse wäre bzw. keine Lösung möglich wäre. Compiz werde ich auch nicht umgehen können, außer ich gebe Unity auf ☹
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
ledy schrieb: und nur für die Karte mit intel Treiber die Option anzuhängen?
Dafür gibt es den BusID Parameter. ledy schrieb: die keine 2. Karte enthält.
Der X Server war auch nie dafür vorgesehen, USB Grafikkarten zu benutzen - das ist mehr oder weniger reingehackt worden. Im Netz müssten sich aber wohl entsprechende Configs finden lassen... im Arch Wiki bin ich darüber gestolpert, dass man als BusID schlicht und ergreifend "USB" angeben kann.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
Das war im ersten Posting versucht worden. Intel wird damit geladen, inkl. BusID PCI:0:2:0, aber Xorg versucht keine weiteren Karten zu finden. Also benötige ich wohl auch eine 2. Section anstatt Xorg automatisch konfigurieren zu lassen. Kann ich bei laufender Xorg ausgeben lassen, welcher Driver richtig wäre? fbdev hattest Du schon verneint. modeset/modesetting ist laut lsmod gar nicht geladen/vorhanden. Kann denn die Xorg conf, wie sie autom. beim Betrieb von Mate geladen wird, exportieren? ("Xorg --configure" war nicht hilfreich, lädt nur 1 Karte) Das Arch Wiki beschreibt mehrere Möglichkeiten und ich teste bereits seit Tage, aber nach wie vor kein aktuelles Manual gefunden, womit nicht nur Displaylink sondern beides funktioniert. Warum es letztendlich ohne Compiz funktioniert bzw. mit Compiz schleppend läuft, konnte auch in der Linux Mint und in der Arch Community niemand erklären. Ich hoffe, das ist dennoch lösbar...
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
ledy schrieb: modeset/modesetting ist laut lsmod gar nicht geladen/vorhanden
Jetzt nicht durcheinander kommen: modesetting ist ein reiner X Treiber der jedes KMS fähige Kernel Modul verwenden kann.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
mit beiden getestet und weder in der config von xorg beachtet worden, noch in lsmod o.ä. zu finden.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
Kann mich mit Mate nicht wirklich anfreunden und hätte weiterhin lieber Unity.
Dazu wieder stundenlang die Arch Wiki Tipps und xorg config Versuche fortgesetzt, leider immernoch erfolglos. Bzgl. intel oder framebuffer Bug: Mit größerem Aufwand habe ich nun auch beides getestet, mit und auch ohne proprietäre Intel Treiber. Das Ergebnis ist bei Aktivierung des 2. Monitors über Displaylink USB auch dasselbe, mit metacity akzeptabler Benchmark und mit compiz Endstation. Hättest Du doch noch einen Tipp für mich, wie sich
entweder Xorg und udev(?) dazu bringen lassen, für die eine Karte die xorg.conf.d/...intel... Definition zu verwenden und für die USB Karte die automatische Erkennung/Konfiguration zuzulassen
oder wie ich mir die "Section Device" Infos exportieren oder ablesen kann, während mate oder genaugenommen metacity an ist bzw. wenn beide Grafikkarten automatisch und richtig konifuriert sind inkl. Framebuffer Einstellungen?
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
ledy schrieb: mit und auch ohne proprietäre Intel Treiber.
Es gibt keinen prorprietären Intel Treiber. Der vorinstallierte freie Treiber ist der einzige, er wird bereits direkt von Intel entwickelt. Der von Intel angebotene Installer macht nichts weiter als die aktuelle Version des freien Treibers zu erstellen.
|
ledy
(Themenstarter)
Anmeldungsdatum: 24. August 2011
Beiträge: 26
|
OK, das erklärt, warum das Ergebnis dasselbe ist. Meinst du, es hat noch Sinn, das weiterzuverfolgen:
Hättest Du doch noch einen Tipp für mich, wie sich entweder Xorg und udev(?) dazu bringen lassen, für die eine Karte die xorg.conf.d/...intel... Definition zu verwenden und für die USB Karte die automatische Erkennung/Konfiguration zuzulassen oder wie ich mir die "Section Device" Infos exportieren oder ablesen kann, während mate oder genaugenommen metacity an ist bzw. wenn beide Grafikkarten automatisch und richtig konifuriert sind inkl. Framebuffer Einstellungen?
oder wird sich der Framebuffer Issue nicht lösen lassen?
|