Wie ich schon im nvidia-Treiber Thread geschrieben habe, kann ich sowohl die Intel als auch die NVIDIA Grafik als 2 separate Xorg instanzen betreiben. Die nvidia-Karte kann ich als headless Xorg über vglrun (virtualgl) betreiben. Das ist ziemlich nutzlos, denn das performt schlechter als die Intel-Grafik. Aber immerhin verdoppelt es die Akku-Laufzeit, wenn der nvidia-Treiber aktiv ist (die Karte ber devctl abschalten bringt nichts).
Nun gibt es eine interessante Entwicklung, inzwischen habe ich mir ein TB3 (USB-C) auf DisplayPort Kabel besorgt und kann damit meinen Monitor auf dem Schreibtisch ansteuern. Allerdings nur über die NVIDIA-Hardware. Für Intel ist der Port unsichtbar. Das hat den Vorteil, dass ioquake3 in UHD mit 1000fps läuft (was ich natürlich nach dem ersten Flash gedrosselt habe, damit der Lüfter nicht röhrt). Erst mal geil, leider habe ich keinen Weg die Kontrolle über die Eingabe weiterzugeben. Jetzt könnte ich natürlich was frickeln damit der 2. Xorg Prozess einen festen Satz Eingabegeräte nimmt und der erste einen Anderen. Das sollte mit evdev sogar im laufenden Prozess klappen. Aber ich würde eigentlich lieber die gleichen Eingabegeräte hin und her reichen können, wobei die eingebaute Tastatur und das Mousepad immer beim primären Xorg (dem mit Intel) bleiben sollten. Geht da etwas?
Anderes Szenario. Ich kann auch beide Grafikkarten in einem Xorg-Prozess verwenden. Leider bekommt X es nicht hin aus dem Paar Intel/NVIDIA einen virtuellen Screen zusammenzupappen. Von der Bedienung her muss ich also anwendungen (inklusive WM) über die DISPLAY Variable auf dem 2. Screen starten. Die Screens heißen dann :0.0 und :0.1 statt :0 und :8. Sonst ändert sich an der Bedienung leider gar nichts. Ich kann zwar auf dem 2. Screen Fenster öffnen aber der fokus bleibt auf dem Ersten. Ich könnte also höchstens per mpv Videos abspielen. Aber das geht ja auch mit der Konfiguration in 2 Prozessen. Dazu kommt, dass beim Kombinieren der Treiber in einem einzigen Prozess 3-D statt mit beiden mit keiner Karte funktioniert. Das ganze hat also nur Nachteile.
Da versagt die Xorg Architektur leider vollkommen. Auch der unsägliche libGL Konflikt der durch die monolithische mesa-Architektur entstanden ist. LibGL sollte ein kleines Ding sein, dass nachschaut welcher Treiber den Bildschirm antreibt und den Fragen welche libGL zu laden ist und genau das tun.
Nun gibt es eine interessante Entwicklung, inzwischen habe ich mir ein TB3 (USB-C) auf DisplayPort Kabel besorgt und kann damit meinen Monitor auf dem Schreibtisch ansteuern. Allerdings nur über die NVIDIA-Hardware. Für Intel ist der Port unsichtbar. Das hat den Vorteil, dass ioquake3 in UHD mit 1000fps läuft (was ich natürlich nach dem ersten Flash gedrosselt habe, damit der Lüfter nicht röhrt). Erst mal geil, leider habe ich keinen Weg die Kontrolle über die Eingabe weiterzugeben. Jetzt könnte ich natürlich was frickeln damit der 2. Xorg Prozess einen festen Satz Eingabegeräte nimmt und der erste einen Anderen. Das sollte mit evdev sogar im laufenden Prozess klappen. Aber ich würde eigentlich lieber die gleichen Eingabegeräte hin und her reichen können, wobei die eingebaute Tastatur und das Mousepad immer beim primären Xorg (dem mit Intel) bleiben sollten. Geht da etwas?
Anderes Szenario. Ich kann auch beide Grafikkarten in einem Xorg-Prozess verwenden. Leider bekommt X es nicht hin aus dem Paar Intel/NVIDIA einen virtuellen Screen zusammenzupappen. Von der Bedienung her muss ich also anwendungen (inklusive WM) über die DISPLAY Variable auf dem 2. Screen starten. Die Screens heißen dann :0.0 und :0.1 statt :0 und :8. Sonst ändert sich an der Bedienung leider gar nichts. Ich kann zwar auf dem 2. Screen Fenster öffnen aber der fokus bleibt auf dem Ersten. Ich könnte also höchstens per mpv Videos abspielen. Aber das geht ja auch mit der Konfiguration in 2 Prozessen. Dazu kommt, dass beim Kombinieren der Treiber in einem einzigen Prozess 3-D statt mit beiden mit keiner Karte funktioniert. Das ganze hat also nur Nachteile.
Da versagt die Xorg Architektur leider vollkommen. Auch der unsägliche libGL Konflikt der durch die monolithische mesa-Architektur entstanden ist. LibGL sollte ein kleines Ding sein, dass nachschaut welcher Treiber den Bildschirm antreibt und den Fragen welche libGL zu laden ist und genau das tun.
