Wine/Crossover Office – Positionierung und Größenänderung von KDE-Fenstern für MS Office 2007/2010

Im Rahmen von Beratungsaufträgen für Kunden bin ich immer mal wieder gezwungen, auf Windows Office-Anwendungen zurückzugreifen. Denn leider funktioniert in etlichen Fällen mit komplexeren Dokumenten oder Präsentationen der Weg

LibreOffice => Zip-File/Mail => MS Office => Zip-File/Mail => LibreOffice => Zip-File/Mail => MS Office

nicht völlig verwerfungsfrei.

Um Kundenbeschwerden aus dem Weg zu gehen, nutze ich deshalb – wenn erforderlich – MS Office 2010 Applikationen unmittelbar über Wine (in Form von Crossover Office) auf meinem Linux/KDE-Desktop. Nun habe ich mir kürzlich einen neuen Laptop zugelegt; zwangsläufig musste ich meine komplette SW-Umgebung vom Altsystem um- und nachziehen. Dabei stößt man dann im Zuge der Wine-, der Crossover Office- und der nachfolgenden MS Office-Installation unter einer passenden “Wine-Bottle” als MS-Laufzeit-Umgebung (oder nach einem Bottle-Ex/Import) zwangsläufig auf folgendes Thema:

Die KDE-Fenster für die Wine basierten MS Office-Applikationen lassen sich nach einer einmal durchgeführten Full-Screen-Maximierung nicht mehr wie andere Standardfenster mit der Maus über einen Drag-Vorgang mit der Maus auf der Menüleiste bewegen. Ferner funktionieren danach freie Größenänderungen des Fensters mit der Maus nicht mehr. Man kann nur zwischen maximaler Größe und einem vordefinierten Größen-Format hin und her schalten.

Das ganze Problem hatte ich früher schon mal durchlitten – und schließlich über KDE-Einstellungen gelöst – nur leider vergessen wie. Ärgerlich! Die Zeit zum Rumprobieren kann man sich beim nächsten Mal wirklich sparen. Deshalb hier eine Zusammenstellung der erforderlichen Schritte.

Einstellungen für die betroffene Wine/Crossover Bottle (“Flasche”) der Windows-Applikation

Hierzu das zentrale “CrossOver” Verwaltungsapplikation öffnen (im Terminal nach einer Standardinstallation z.B. über den Aufruf von “/opt/cxoffice/bin/crossover”).

Dort den Menüpunkt “Werkzeuge >> Flaschen verwalten” wählen. Die jeweilige “Flasche” für die Windows-Office-Installation im linken Seitenbereich auswählen, rechts den Tab “Systemsteuerung” wählen und darunter den Punkt “Wine Konfiguration” anklicken.

Im sich öffnenden Konfigurationsfenster den Reiter “Grafik” anklicken. Dort folgende Optionen auswählen:

  • Erlaube dem Fenstermanager die Fenster zu dekorieren
  • Erlaube dem Fenstermanager die Fenster zu kontrollieren

bottle1

Diese Einstellungen dienen dazu, dass der Window-Manager (ob unter Windows oder nicht) – zumindest grundsätzlich – die Kontrolle über die Applikationsfenster zu bekommt.

Wenn man bei einem Umzug auf ein anderes System die Export/Import-Funktionalität für Wine-Bottles nutzt, sollten diese Einstellungen auf dem neuen System bereits gegeben sein – soweit man sie auf dem Altsystem schon vorgenommen hatte.

Sonderregeln für KDE-Fenster-Einstellungen

Nun müssen wir noch die andere Seite – nämlich die des Window-Managers unter KDE betrachten. Hierzu die KDE Systemeinstellungen öffnen (im Terminal über das Kommando: systemsettings &).

Dort unter der Rubrik “Erscheinungsbild und Verhalten der Arbeitsfläche”
den Punkt “Fensterverhalten” anklicken. Im sich öffnenden Fenster “Fensterregeln” wählen. Dann den Button “Neu” klicken.

Wir landen im Reiter “Fensterübereinstimmung” eines sich neu öffnenden Dialogfensters.
Das Feld “Beschreibung” füllen wir mit Stichwörtern unserer Wahl (“MS Office 10 Regeln”). Nun ein Klick auf Button “Fenstereigenschaften ermitteln”. Dies hilft uns, Informationen dazu zu erhalten, unter welcher sog. Fensterklasse KDE die wine-basierten MS Office-Applikationen eigentlich führt. Klickt man mit dem angebotenen Kreuz-Cursor nun auf ein geöffnetes Crossover Fenster für Winword, so öffnet sich ein Fensterchen, in dem man bzgl. der sog. “Klasse” den Ausdruck “Wine (WINWORD.EXE Wine)” vorfindet.

Nach dieser Information klicken wir im Informationsfensterchen auf “Abbrechen” und landen wieder im Dialog zur “Fensterübereinstimmmung”.

bottle2

Bei der Combobox zum Punkt “Fensterklasse” nun den Punkt “Regulärer Ausdruck” wählen. Wir müssen einen Regex-Ausdruck festlegen, der die Fensterklassen, die KDE (bzw. X-Windows) den betroffenen Crossover-Fenstern zuordnet, am besten erfasst. In Anlehnung an die oben bereits ermittelte Information, die wir auf Excel und Powerpoint erweitern wollen, nehme ich

.*\b(winword.exe|excel.exe|powerpnt.exe)\b.*

Bzgl. evtl. Sorgen bzgl. einer Groß-/Kleinschreibungs-Thematik siehe den letzten Kommentar unter https://bugs.kde.org/show_bug.cgi?id=173544. Wer dem Regex wegen der Großschreibung z.B. der MS Office 2010-EXE-Dateien dennoch nicht traut, kann ja versuchsweise “i”-Modifikatoren einsetzen, wird aber feststellen, dass das i.d.R. Fehler nach sich zieht. Zusätzlich ist ein Haken beim Feld “Übereinstimmung mit gesamter Fensterklasse” erforderlich.

Wichtige Ergänzung 20.11.2015:

Speziell im Falle von Powerpoint gibt es mit den bisherigen und den nachfolgenden Einstellungen Probleme, da auch kleine Grafiken bei Verschiebungen und Größenänderungen zur Erzeugung kleiner Fenster führen, die z.B. die Verschiebung während der Mausaktion anzeigen. Man muss daher die Anwendung der nachfolgenden Regeln von vornherein weiter auf die Hauptfenster einschränken. Ein wenig Experimentieren führte mich dann zu folgender Lösung: Für das Feld “Fenstertitel” wählt man erneut “regulärer Ausdruck” und

.*\b(.*)\b.*

crossover_5_800

Nicht besonders elegant- aber wirksam. (Sicher gibt es bessere Lösungen, aber ich komme grad nicht drauf.)

Nun weiter zum Reiter “Größe und Position”. Wir wollen verhindern, dass der Fenstertyp sich beim erneuten Öffnen an eine evtl. vorgenommene Maximierung erinnert und dass wir auf eine bestimmte Geometrie festgelegt werden. Deshalb sind folgende Einstellungen erforderlich:

  • Vollbild => Erzwingen => Nein
  • Angeforderte Geometrie ignorieren => Erzwingen => Ja

bottle3

Wir bestätigen diese Einstellungen durch OK. Nach dem Schließen der Dialogfenster zu den konkreten Einstellungen aktivieren wir die geänderten Einstellungen noch über den Button “Anwenden”.

Danach verhalten sich die Crossover Fenster für MS Office Applikationen unter KDE
wie normale Fenster nativer Linux-Applikationen. Falls nicht: Einmal abmelden und dann wieder in den KDE-Desktop einloggen.

beispiel1_red

Alternative Fensterhandhabung

Ein “Alt-Klick” auf ein Fenster ermöglicht grundsätzlich dessen Verschiebung auf dem Desktop. Das gilt auch für Crossover-Fenster. Das Gleiche erreicht man über einen Klick mit der rechten Maustaste auf das Fenstersymbol zu unserem Crossover-MS-Office-Fenster in der KDE Fensterleiste und eine nachfolgende Wahl des Punktes “Weitere Aktionen” im sich öffnenden Menü. Dies führt uns zu einer Auswahl von Fensteroperationen, die sich auf diesem Wege auch für Crossover Fenster ausführen lassen. Eine dieser Fensteroperationen ist auch die Größenänderung.

Links

https://www.codeweavers.com/compatibility/crossover/forum/microsoft-office-2010?msg=157908
https://bugs.kde.org/show_bug.cgi?id=329227
http://www.linuxforen.de/forums/showthread.php?230623-Wine-Fenster-l%E4sst-sich-nicht-verschieben-und-ist-immer-im-Vordergrund
https://forum.winehq.org/viewtopic.php?f=8&t=20006

Viel Spaß dann noch mit Wine und Crossover Office! Dass man mit MS Office Spaß haben wird, ist bei den Lesern eines Linux-Blogs kaum zu erwarten. Seit MS Office 2007 frage ich mich persönlich immer wieder, welcher Wahnsinnige sich wohl die aus meiner Sicht chaotische und den Arbeitsfluss nicht fördernde, sondern eher behindernde Benutzerführung ausgedacht hat … Na ja, eingefleischte MS Fans können das sicher erklären. Ich bin jedenfalls froh, dass es ein inzwischen relativ ausgereiftes LibreOffice gibt und mir das Leben leichter macht.

Nvidia Treiber, KDE-Plasma-Desktop 4.14, Tearing-Effekt: Triple Buffering einschalten!

Meine Leser wissen, dass ich bzgl. des Linux-Desktops auf KDE setze. Den HW-technischen Unterbau liefern in meinen privaten Systemen, die ich meist selbst aufbaue, Nvidia-Grafikkarten. In der Regel verwende ich dafür den proprietären Treiber, dessen Modul ich über das Installationsskript von Nvidia kompilieren und installieren lasse. (Mit der unangenehmen Konsequenz eines “tainted” Kernel – aber das nur nebenbei).

Dieser Artikel betrifft ein Plasma-Problem, das ich auf Desktop-Systemen hatte. (Der Artikel bezieht sich nicht auf Laptop-Systeme mit Optimus-Technologie.) Seit geraumer Zeit (schätzungsweise seit KDE 4.12 bis heute unter KDE 4.14.9) plagte mich folgender, immer wiederkehrender Fehler:

Nach dem Starten des KDE Plasma Desktops mit aktivierten 3D-Effekten (OpenGL) – kam es bei der Bewegung von bestimmten Fenstern immer wieder zum sogenannten “Tearing”-Effekt. Besonders deutlich sichtbar wurde der für Fensterbegrenzungslinien von “konsole” oder Fenstern mit komplexeren GTK-Anwendungen. Dies erwies sich als unabhängig von der Voreinstellung der des OpenGL Composite Typs und des Qt-Grafiksystems (“native” oder “raster” Rendering)

Erstaunlicherweise verschwand dieser Effekt bei mir ebenso regelmäßig, wenn ich unter den KDE Systemeinstellungen auf dem Panel zu “Arbeitsflächen-Effekte” >> “Erweitert” eine der dortigen Einstellungen änderte und auf “Anwenden” drückte. Danach war für diese X-Sitzung Ruhe. Bei der Einstellungsänderung wurde offenbar etwas erkannt, was beim normalen KDE-Start nicht der Fall war). Aber solche manuellen Eingriffe bei jedem Start von KDE sind natürlich nervig.

Zufällig bin ich in anderem Zusammenhang vor ein paar Tagen über folgende Bug-Artikel gestolpert:
https://bugs.kde.org/show_bug.cgi?id=322060
https://bugs.kde.org/show_bug.cgi?id=330794
https://bugs.kde.org/show_bug.cgi?id=343184

Dadurch animiert habe ich nun mal “Triple Buffering” explizit in die “xorg.conf” eingetragen. Der Installer von Nvidia tut das nämlich nicht von sich aus. Er bewegte aber den einmal vorgenommenen händischen Eintrag bei der nächsten Treiber-Installation interessanterweise aus der “Device Section” in die “Screen Section”:

Auszug aus der /etc/X11/xorg.conf”:

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DVI-I-1: nvidia-auto-select +5120+0, HDMI-0: nvidia-auto-select +0+0, HDMI-1: nvidia-auto-select +2560+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    Option         "TripleBuffer" "true"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

 
Man erkennt hier, das ich Xinerama für 3 Schirme nutze. Der interessante Eintrag ist aber:

Option “TripleBuffer” “true”

Ich kann nur sagen:

Seitdem ist jegliches Tearing auf meinem 3-Schirme-Desktop verschwunden – ohne weitere Zusatzmaßnahmen und egal, was ich unter “Arbeitsflächen-Effekte” >> “Erweitert” für Einstellungen zum Punkt “Einzelbild-Zerreißen (Tearing) verhindern (Vsync)” einstelle. Auch ein spezieller Export der Umgebungsvariablen “__GL_YIELD” wie in einem der Bug-Reports beschrieben, erwies sich unter KDE 4.14 als überflüssig – diese Umgebungsvariable ist bei mir gar nicht gesetzt.

r
So einfach – man muss es halt nur wissen! Mein Dank an alle, die sich um diesen Bug in seinen verschiedenen Ausprägungen gekümmert haben! Ein schönes Beispiel dafür, dass der Open Source Prozess auch im Zusammenspiel mit Closed Source Komponenten funktioniert – auch wenn es manchmal etwas dauert.

Mouse / Keyboard frieren nach KDE-Login ein – ein .cache-Problem im Plasma-Desktop

In der letzten Woche hatte ich nach einigen Updates und Experimenten mit diversen Gnome Programmen (nautilus, tracker, …) unter KDE massive Probleme mit der Maus unmittelbar nach dem Einloggen in den KDE-Desktop (Opensuse 13.2; KDE 4.14.X mit KDE 5 Komponenten). Angemerkt sei, dass ich den aktuellen proprietären Nvidia-Treiber “352.41” benutze.

Die Maus ließ sich anfangs bewegen und man konnte auch genau einmal in ein Fenster – z.B. ein Terminal – klicken. Danach zeigten weder die Maus noch Navigationstasten des Keyboards eine Wirkung – und wenn doch, dann mit ganz erheblicher Zeitverzögerung.

Das Einzige was noch funktionierte war Ctrl-Alt-Del; man konnte danach zwar unter den erscheinenden Optionen nicht mehr per Tastaur/Maus wählen – aber nach 30 sek. wurde der automatische Logout durchgeführt. Nach einem erneuten Login gab es dann seltsamerweise keinerlei Probleme mehr mit der Maus oder Tastatur.

Interessant war auch, dass das Problem offenbar User-spezifisch war. Ein initialer Login nach dem Booten unter einer anderen UserID führte zu keinen Freezes.

Es war praktisch unmöglich zu beurteilen, ob das Problem an Plasma, anderen KDE-Komponenten oder eben den Gnome-Programmen lag. Die üblichen Log-Einträge (systemd journal, .xsession-errors) gaben nichts her.

Nach ein wenig Recherche im Internet fand ich folgende Artikel:
https://bugs.kde.org/show_bug.cgi?id=341963
https://forum.kde.org/viewtopic.php?f=289&t=124690

Ich hatte keineswegs dort angesprochene Probleme mit einer voll-laufenden Partition oder ähnlichem. Aber einer der dort besprochenen Lösungsansätze half:

Nach einem Löschen der Einträge/Subverzeichnisse im Verzeichnis “~/.cache” lief alles wieder wie es sollte. Das geschilderte Problem ist seither nicht wieder aufgetaucht.

Herzlichen Dank an all diejenigen, die im Rahmen der Bewältigung ihrer eigenen Probleme das Thema potentieller “.cache”-Probleme des KDE-Plasma-Desktops herausgefunden haben! Es ist wert, diesen Punkt als KDE-Nutzer im Kopf zu behalten.

Welches der Programme, das im “.cache”-Verzeichnis Einträge hinterlegt, Schuld war, konnte ich nicht mehr nachvollziehen, da ich die “.cache”-Subverzeichnisse leider und idiotischerweise pauschal gelöscht habe. Es wäre besser gewesen, es für spätere Analysen einfach umzubenennen ….. Als potentiell schuldige Programme kommen in meinem Fall in Frage :
chromium, fontconfig, gstreamer, ibus, mozilla, tracker, webkit, xine-lib.

Linux – Nvidia GTX 750 TI – Parallelbetrieb von 2 Dell U2515H mit 2560×1440 plus einem 1920×1200 Schirm

Erst vor kurzem hatte ich in einem Artikel über positive Erfahrungen mit einem Dell U2515H an einer GTX 750 TI Graka unter Linux und KDE berichtet. Dabei hatte ich belegt, dass es möglich ist, einen Dell U2515H in der nativen Auflösung von 2560×1440 über HDMI zusammen mit 2 Schirmen in der Auflösung 19210×1200 über DVI-Ausgänge parallel an einer Gigabyte GTX 750TI zu betreiben. Siehe:

Linux – Nvidia GTX 750 TI – Dell U2515H – HDMI – 2560×1440 Pixel

Inzwischen hat einer der 1920×1200 Schirme an besagtem System nach vorhergehender Alterschwäche den Geist aufgegeben und wurde durch einen weiteren Dell U2515H ersetzt. Nachzutragen ist, dass auch eine Konfiguration mt 2 Dell U2515H mit je 2560×1440 px an 2 HDMI-Anschlüssen und einem 1920×1200 LCD an einem der DVI-Anschlüsse der Graka einwandfrei funktioniert. Zumindest bei Verwendung eines aktuellen proprietären Nvidia Treibers.

kde_3_screens_3

Voraussetzung sind – wie im letzten Artikel ausgeführt – gute, aktuelle HDMI-Kabel mit 4K-Unterstützung (und hinreichender Länge – in meinem Fall 2m und 3m).

Nachtrag, 14.12.2015, KDE-Anpassungen,, ältere Grafikkarten:
Ein Leser hat mich angeschrieben und Sorgen bzgl. der Anpassung von KDE-Anwendungen an die hohe Auflösung sowie bzgl. der Performance älterer Grafikkarten geäußert. Ich habe die Fragen in folgendem Artikel beantwortet:
Linux – Dell U2515H – questions regarding KDE adjustments and older graphics cards

Nachtrag, 14.12.2015, Nvidia GTX 960
Ich konnte inzwischen auch die Konfiguration aus 2 Dell U2515H per Display Port und einem 1920×1200 Schirm per DVI an einer Nvidia GTX 960 testen. Funktioniert problemfrei!

Linux – Nvidia GTX 750 TI – Dell U2515H – HDMI – 2560×1440 Pixel

An einem unserer Entwicklungssysteme nutzte ich bisher zwei 24 Zoll IPS-Schirme mit einer Auflösung von 1920×1200. Vor einigen Monaten hatte ich zudem meine alte Nvidia GTX 460 Grafikkarte gegen eine GTX 750 TI von Gigabyte ausgetauscht. Letztere bietet aus meiner Sicht einen annehmbaren Kompromiss zwischen 2D/3D-Leistung und Preis – zumal ich kein Interesse an PC-Spielen habe. Die Umstellung ging problemlos – soweit man mal von kleineren Problemen der proprietären Nvidia-Treiber in der aktuellen KDE 4.14 / KDE 5 Umgebung absieht (siehe die Off Topic Anmerkungen am Ende des Artikels).

Nachfolgend möchte ich darstellen, dass und wie man diese Konfiguration unter Linux um einen DELL U2515H in dessen nativer Auflösung erweitern kann. Insgesamt ergibt sich damit ein Linux-System (in meinem Fall unter Opensuse 13.2 und KDE) mit 3 Schirmen und einer (virtuellen Xinerama) Screenbreite von 6400 Pixeln.

kde_3_screens_2

Verfügbare Schnittstellen der Gigabyte GTX750 GTI

Gigabytes GTX 750 TI hat 2 DVI- und 2 HDMI-Schnittstellen, aber leider keinen Display Port. 4K Auflösung wird auch nur in Spezialkonfigurationen unterstützt – die Schirme müssen hierzu einen bestimmten Modus mitmachen. Eine Auflösung von 2560×1440 bringt die Karte laut Spezifikation aber sehr wohl zustande – zumindest an einem Schirm. Über das Fehlen einer Display-Port Schnittstelle hatte ich beim Kauf nicht weiter nachgedacht. Da immer mehr Schirme jedoch keine DVI-Schnittstelle mehr anbieten, ist das ein Punkt, der künftig meine Graka-Entscheidungen sehr viel stärker beeinflussen wird.

25 Zoll Schirm Dell U2515H

Jetzt hat einer meiner älteren Schirme – ein von mir geliebter alter Samsung 244T mit S-PVA Panel (Samsung hat danach nie wieder so gute Monitore gebaut!) – eine Macke: Der Schirm kommt nach einer längeren Abschalt-Phase durch KDE’s Powersaving Funktionen u.U. nicht mehr hoch. Wir hatten solche Probleme schon früher – vermutete Ursache sind defekte oder altersmüde Kondensatoren der Schalt-Elektronik des Schirms. Das Panel selbst ist völlig OK. Zu anderen möglichen Ursachen s. die Off Topic Anmerkung weiter unten. Eine weitere Reparatur des Samsung lohnt sich jedenfalls nicht. Grund genug, über einen neuen Schirm für meinen Linux-Arbeitsplatz nachzudenken.

Die Wahl fiel nach Internet-Recherchen auf einen Dell U2515H. Dieser 25 Zoll (!) Schirm hat ein IPS AH Panel mit einer nativen Auflösung von 2560×1440 Pixeln und kostet z.Z. um die 300 Euro. Ich habe mir den Schirm bei einem netten Händler (Schwanthaler-Computer) gegen einen Aufpreis vorführen lassen und war recht angetan. Ein paar Stichpunkte:

Der hohe Kontrast der Standardeinstellung ist mir persönlich zu intensiv – aber das kann man sehr gut manuell nachregeln – ebenso wie die Helligkeit. Die Winkelabhängigkeit von Helligkeit, Farbtreue, Kontrast des Bildes halten sich in den Grenzen dessen, was man von einem besseren IPS-Panel erwarten kann. (Mit der Qualität eines PVA oder MVA Panels kann sich ein IPS Schirm in diesem Punkt von Haus aus nicht messen.) Ja – es gibt auch einen typischen IPS Glow – in vertikaler Richtung ausgeprägter als in horizontaler – besonders wenn man von unten nach oben auf den Schirm sieht. Es ist ein flächiger, weißlicher Effekt – er führt aber interessanterweise nicht zu Farbverfälschungen, wie ich sie schon bei anderen Schirmen gesehen habe. Der Effekt ist subjektiv geringer und auch homogener als bei einem ASUS 248PBQ.

Die Entspiegelung des U2515H hätte für meine Gefühl besser sein können; eine helle Tischplatte oder ein eigenes weißes Hemd wird im Schirm etwas verwaschen wahrnehmbar sein. Die Entspiegelung ist geringer als bei aktuellen ASUS Schirmen. Aber das ist vielleicht Geschmackssache und nicht jeder mag die Körnigkeit stark entspiegelter Schirme. Die Homogenität der Ausleuchtung ist zumindest bei meinem Exemplar recht gut; da habe ich im Netz schon anderes gelesen. Subjektiv meine ich, einen minimalen Helligkeitsabfall zu den Rändern links und rechts feststellen zu können – hier schlägt vielleicht aber auch schon die Winkelabhängigkeit des Bildes in Kombination mit der Breite des Schirms zu.

An die Bedienlogik und die Touch-Tasten konnte ich mich relativ schnell gewöhnen. Die manuelle Farbregelung ist für mein Gefühl zu sensibel – hier schlagen nichtlineare Effekte schnell zu – aber es ist durchaus möglich, die Farbeinstellungen manuell allein über die Steuerungsfunktionen des Schirms selbst anzupassen. (Eine echte Kalibrierung ersetzt das nicht). Schlechter als bei aktuellen Asus-Schirmen im Bereich zwischen 300 und 500 Euro ist die manuelle Bild-Regelung des Dell in keinem Fall – eher besser. Zudem bietet Nvidias Applikation “Nvidia X server Settings” für Linux die Möglichkeit pro Schirm individuelle Einstellungen der Farbkanäle vorzunehmen. Ein Manko des DELL : Eine stufenlose Gamma-Regelung ist leider nicht möglich. Hier muss man auf Möglichkeiten der Grafikkarte zurückgreifen.

Relativ beeindruckend ist die Darstellung von Grauverläufen in Testbildern. Ich konnte bei normalem Kontrast bislang keinerlei Streifigkeit erkennen. Bzgl. Spielen habe ich nur Alien Arena in verschiedenen Auflösungen angesehen. Kein akutes Problem erkennbar. Ich habe aber keine Ansprüche und spiele aus Zeitmangel so gut wie nie. Videos: Von meiner Seite kein Problem erkennbar.

Ausführliche Review-Berichte zum U2515H von professionellen Testern findet man z.B. hier:
http://www.tftcentral.co.uk/ reviews/ dell_u2515h.htm
http://www.prad.de/ new/ monitore/ test/ 2015/ test-dell-u2515h-teil10.html

Kein DVI-Anschluss für den Dell U2515H – funktioniert HDMI mit einer Auflösung von 2560×1440?

Das größte Problem stellte für mich bei der Kaufentscheidung die hohe Auflösung in Kombination mit der Tatsache dar, dass der DELL U2515H nur HDMI und Display-Port-Anschlüsse, aber keinen DVI-Eingang besitzt. Im Internet hatte ich vorab über erhebliche Probleme anderer Leute gelesen, die hohe Auflösung von 2560×1440 bei diesem und vergleichbaren Schirmen über HDMI (gem. 1.4 Standard) überhaupt zum Laufen zu bringen – und das an Arbeitsplätzen mit nur einem Schirm. Wenn überhaupt, so klappte das meist nur mit reduzierter Bildwiederholrate von 55 Hz oder gar nur 30 Hz – unter Linux wie unter MS Win. Weniger Probleme hatten Anwender dagegen bei Verwendung eines Displayports – aber genau einen solchen Anschluss bietet nun die Gigabyte GTX 750 TI nicht. Da sah ich doch ein erhebliches Risiko auf mich zukommen.

Dell 2515H parallel mit zwei 1920×1200 Karten an der GTX 750 TI unter Linux?

Meine Ansprüche waren aber noch höher: Ich wollte den Schirm in nativer Auflösung und in Kombination mit mindestens einem, besser aber zwei 1920×1200 Schirmen an der GTX 750 TI zum Laufen unter Linux bringen. Die gute Nachricht ist: Ja, das geht ! Voraussetzungen sind:

  • Ein gutes HDMI Kabel. Ich habe mir ein ca. 13 Euro teures Delock Kabel geleistet, das gem. Spezifikation u.a. Übertragungsraten von bis zu 10,2 Gb/s und Auflösungen bis zu 4096×2160 px unterstützen soll.
  • Der Einsatz des proprietären Nvidia-Treibers >= NVIDIA-Linux-x86_64-346.47
  • Etwas Experimentierwillen und der Einsatz des proprietären Nvidia-Treibers. (Ich sollte besser sagen: Mit dem proprietären Treiber geht es sicher. Mit dem nouveau-Treiber habe ich es bisher schlicht nicht getestet. Es mag damit ggf. auch funktionieren.)

Mein erster Versuch, auch nur einen weiteren Schirm zusammen mit dem DELL U2515H zum Laufen zu bringen, scheiterten allerdings. Ich nutzte und nutze zur Grundeinstellung Nvidias “NVIDIA X SERVER Settings”-Applikation und dort den Punkt “X Server Display Configuration”.

Ich schaffte es im ersten Anlauf einfach nicht, den Dell 2515H an der ersten HDMI Schnittstelle der Graka in Kombination mit einem ASUS PB248Q am ersten DVI-Anschluss so zum Laufen zu bringen, dass ich die Maximalauflösung am Dell bei 60 Hz erhalten hätte. Möglich waren nur Auflösungen von 2048×1152 oder 1920×1200. Die höchste Auflösung 2560×1440 wurde in der “Nvidia X Server Settings”-Applikation (unter KDE) gar nicht angeboten. Auch die Einstellmöglichkeiten unter den
“KDE Systemeinstellungen >> Hardware >> Anzeige und Monitor”
boten die maximale Auflösung nicht an. Ich kann nur sagen: Lasst euch dadurch nicht entmutigen. Was bei mir half, waren dann folgende Schritte:

Raus aus KDE auf ein Konsolterminal >> init 3 >> Neuinstallation des proprietären Nvidia-Treibers bei angeschlossenem Dell-Schirm am ersten HDMI-Ausgang der Graka (und den beiden anderen 1920×1200 Monitoren an den 2 DVI-Ausgängen) >> Reboot >> Start KDE >> Nvidia-X-Server-Einstellung => – und siehe da: Die volle Auflösung wird seitdem angeboten.

nvidia_screens

Auch unter KDE’s “systemsettings” wird die Maximalauflösung korrekt wiedergegeben:

kde_screens_2

Bilder

Im Moment sieht mein resultierendes physikalisches Screen-Layout wie folgt aus:

kde_3_screens_live_1200

Das nachfolgende Bild stellt dagegen einen Screenshot – erzeugt mit Ksnapshot dar:

kde_3_screens_1

Dort bleibt links und rechts ein schwarzer Streifen am unteren Bildrand. Der findet sich auf den Schirmen selbst natürlich nicht (s.o.). Auf die Unterschiede in den bildlichen Darstellungen würde ich nicht zuviel geben – die Kamera sieht anders als das menschliche Auge und die Schirme sind unterschiedlich eingestellt. Subjektiv finde ich, dass der Dell kleine Farbnuancen und filigrane Bildstrukturen bei etwas heruntergeregeltem Kontrast sehr gut wiedergibt.

Simple xorg.conf

Die xorg.conf, die der proprietäre Nvidia-treiber erzeugt, hat folgenden Inhalt:

xorg.conf

# nvidia-xconfig: X 
configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 346.59  (buildmeister@swio-display-x86-rhel47-04)  Tue Mar 31 14:42:07 PDT 2015

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 346.47  (buildmeister@swio-display-x86-rhel47-01)  Thu Feb 19 19:18:25 PST 2015

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Ancor Communications Inc PB248"
    HorizSync       30.0 - 83.0
    VertRefresh     50.0 - 61.0
    Option         "DPMS" "false"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 750 Ti"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DVI-I-1: 1920x1200_60 +0+0, DVI-D-0: 1920x1200_60 +1920+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Der dort erscheinende Ancor Schirm – eigentlich ein ASUS PB248Q – ist der primäre Schirm; die anderen Schirme (Dell U5215, Samsung 244T) sind über die xinerama-Konfiguration in den nahtlosen “Screen0” mit einer Breite von 6400 px integriert.

Keine niedrige Taktung der Grafikkarte bei 3 Schirmen

Wenn jemand eine ähnliche Konfiguration mit drei Schirmen ausprobieren will, wird er schnell feststellen, dass die Grafikkarte auch bei Auswahl eines adaptiven Leistungsmodus nicht mehr in den Level 0 mit geringer Taktung zurückschaltet. Sie arbeitet immer im oberen Taktungsbereich für maximale Performance. Nachfolgend das Bild zum “Powermizer”-Eintrag des Nvidia-Tools:

nvidia_screens_2

Dies ist bei zwei Schirmen noch anders. Da reicht eine geringere Leistungsfähigkeit. Woran immer der Nvidia-Treiber den Leistungsbedarf misst und welchen Grenzwert er dabei für die Höhertaktung beachtet. Die Lüfter-RPM steigt aber auch bei der höheren Taktung nur unwesentlich an. Im Office- und Entwicklungseinsatz, bei einer aktuellen Zimmertemperatur von ca. 26 Grad Celsius und geschlossenem Gehäuse liegen die GPU Temperatur bei ca. 41 Grad und die Lüfter RPM-Werten um die 1650 (Speed 33%).

Die hohe Auflösung des Dell U2515H – wo macht das was aus ?

Nun noch ein paar Worte zu den unterschiedlichen Auflösungen – besser zu der extrem hohen Auflösung des Dell
unter 25 Zoll. Das erste was hier zu sagen ist, ist dass ein 25 Zoll 16:9 Schirm in der Höhe etwa 1 cm kleiner ist als ein konventioneller 4:3 24 Zoll Schirm. In der Breite gewinnt man dagegen knapp 3.5 cm. In der physikalischen Ausdehnung fällt der Unterschied zu einem 4:3 24 Zoll Schirm also nicht sofort ins Auge (s. auch das Bilder zu den Schirmen oben). Demzufolge hat die doch deutlich höhere Auflösung bei gleicher Schrifteneinstellung spürbare Auswirkungen auf die Font-Darstellung. Das Bild ist gestochen scharf – aber die Schriften sind erwartungsgemäß deutlich kleiner als auf den 24 Zöllern mit 1920×1200. Nun sehe ich auf die Schirmdistanz auch in meinem Alter noch recht gut. Dennoch : Kleine Fonts sind anstrengender als große. Leider bietet KDE bisher keine Möglichkeit, Schriftfonts schirmspezifisch einzustellen. Wo kommt das beim Arbeiten unter Linux zum Tragen?

Auf der Desktop-Oberfläche kann man innerhalb der eingesetzten Plasmoide in vielen Fällen bzgl. Symbol- und Schriftgröße nachregeln. Kein Problem macht auch das Arbeiten mit Dokumenten oder dem Browser – hier kann man nahtlos und individuell skalieren.

Am meisten Probleme bereitet mir zur Zeit eher Eclipse. Unter Luna funktionieren die in
http://stackoverflow.com/ questions/ 6948374/ how-to-change-font-size-quickly-in-eclipse
angegebenen Tools für PDT nicht. Selbts wenn sie es täten – eine individuelle Font-Regelung pro geöffnetem Eclipse-Fenster gibt es zur Zeit leider genausowenig wie ein Reinzoomen in den Code eines Eclipse Fensters. Man muss also Schriftgrößen für die Code-Darstellung wählen, so dass man in den Eclipse-Fenstern, die am Dell angezeigt werden, noch gut lesen kann, auf den anderen Schirmen aber nicht zuviel Platz verliert. Mit 12-er Fonts kann ich im Moment ganz gut leben. Wirklich komfortabel ist das aber nicht. Der Request bzw. Bug zu Eclipse, in dem eine Editor- und Window-spezifische Zoom-Funktion gewünscht wird, hat nun leider schon einige Zeit am Buckel, ohne dass etwas Greifbares passiert wäre.

Nachtrag, 14.12.2015:
Die Nvidia GTX 750 TI funktioniert auch mit 2 Dell U2515H per HDMI und einem 1920×1200 Schirm per DVI. Siehe:
Linux – Nvidia GTX 750 TI – Parallelbetrieb von 2 Dell U2515H mit 2560×1440 plus einem 1920×1200 Schirm

Off Topic Anmerkung 1 – Nividia Treiber und Tearing

Ich habe auf allen unseren Opensuse-Systemen unter KDE immer wieder ein Problem mit den proprietären Drivern von Nvidia, die das Tearing der Kanten von schnell bewegten Fenstern betreffen nach dem KDE-Start. So erfordert eine tearing-freie Darstellung oftmals einen manuellen Switch in den OpenGL-Einstellung der KDE “systemsettings” (z.B. vom Raster-Modus auf Native oder auch von OpenGL 2.0 auf OpenGL 3.1). Den Einstellungswechsel man danach sofort wieder rückgängig machen. Es ist, als ob die Karte sich erst dann wirklich auf die vertikale Synchronisierungsfrequenz einstellt, obwohl das in den KDE-Einstellungen eigentlich bereits vorgegeben sein mag. Initial beim KDE-Start ist vollständige Tearing-Freiheit jedenfalls nicht für alle Typen von Fenstern gegeben. Zumindest nicht so, wie es ein (nachfolgender) manueller Einstellungswechsel bewirkt.

Ergänzung, 14.12.2015:
Der beschriebene Effekt liegt an einer unzureichenden Buffer-Konfiguration, die man über die xorg.conf beheben kann. Siehe:
Nvidia Treiber, KDE-Plasma-Desktop 4.14, Tearing-Effekt: Triple Buffering einschalten!

Off Topic Anmerkung 2 – Probleme mit Samsung T244 nach Screen Abschaltung durch KDE’s Energiesparfunktionen

Zwei unserer älteren Samsung 244T Schirme haben beim Einsatz an Linux-Systemen unter KDE bereits das Problem bekommen, dass sie eine Weile (ca. 1 Stunde) nach Abschaltung durch die KDE Stromsparfunktionen nicht mehr hochzubekommen sind. So flackert auch die Statusleuchte danach unkontrolliert. In der Phase bis dahin blinkt de Leuchte regulär. Einer der Schirme wurde daraufhin bereits zweimal repariert. Der Schirm, der das Problem aktuell wieder hat, ist nur nach längerem Abschalten, einem Reset und ein paar Tricks wieder zum Leben zu erwecken. Die Probleme liegen in der Schaltelektronik, nicht am Panel selbst. Es tritt übrigens nicht auf, wenn man den PC regulär runterfährt. Auch dann schaltet sich der Schirm ab – er schaltet sich dann aber beim Hochfahren des PCs auch wieder regulär an. Wegen des Alters und des Recovery nach längerer Abschaltzeit mag man natürlich an defekte Kondensatoren denken.

Ehrlich gesagt, glaube ich persönlich allerdings nicht, dass diese Probleme ausschließlich mit der Altersschwäche von Kondensatoren zu tun haben. Ich hege den Verdacht, dass hier auch eine fehlerhafte oder wiedersprüchliche Kombination eigener Stromsparfunktionen der Nvidia-Karten-Treiber mit Signalen der KDE-Stromsparfunktionen an Schirme, die nicht den aktuellen sondern älteren TCO-Normen gehorchen, verursacht werden. Diese Gefühl hängt mit folgenden Beobachtungen zusammen: Der Übergang von einem normalen Abschaltzustand des Schirms in einen unkontrollierten Zustand geschehen offenbar abrupt nach einem definierten Zeitintervall. Und ich habe ein System, an dem KDEs Screen Powersaving Funktionen nie aktiviert wurden – der dortige 244T hat null Probleme – obwohl er 1 Jahr älter als die anderen ist. Aber dass so eine Gefühl eine echte Grundlage hat, kann man nicht oder nur sehr schwer beweisen …

Der neue Dell tut jedenfalls bzgl. der Stromsparfunktionen genau das, was er soll.