Kein glx über ssh

[Kai-Martin Knaak]

Moin.

In meinem kleinen Linux-Pool hier hakelt es ein wenig, was Anwendungen mit
openGL angeht. Lokal auf dem Monitor des jeweiligen Rechners laufen sie
problemlos. Aber über ssh ernte ich Fehlermeldungen. Einfache X-Anwendungen
wie etwa das gute, alte oclock werden erfolgreich über ssh gestartet. Aber
alles, was openGL benutzt, scheitert mit Fehlermeldungen. Die gleichen
Meldungen bekomme ich auch mit glxinfo:

/--------------------------------
$ export LIBGL_DEBUG=verbose
$ glxinfo
name of display: localhost:10.0
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: Can't open configuration file /home/kmk/.drirc: No such file or directory.
libGL: Can't open configuration file /home/kmk/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 48
Current serial number in output stream: 47
$
\-------------------------------

Den Treiber
/usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
habe ich nicht. Laut apt-file gibt es den ganzen Order dri/tls in keinem
Debian-Paket..

Aber am anderen Pfad existiert ein Treiber:
$ ll /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
-rw-r--r-- 8 root root 9.3M May 11 13:11 /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so

Und nu?
Sieht so aus, als würde eine wesentliche Konfiguration fehlen. Nur welche?
(Alle beteiligten Rechner laufen mit monatlich aktuell gehaltenem testing/stretch.)


---<)kaimartin(>---
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211
Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de
GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get

[Stefan Baur]

Am 08.08.2016 um 20:15 schrieb Kai-Martin Knaak:
> Moin.
>
> In meinem kleinen Linux-Pool hier hakelt es ein wenig, was Anwendungen mit
> openGL angeht. Lokal auf dem Monitor des jeweiligen Rechners laufen sie
> problemlos. Aber über ssh ernte ich Fehlermeldungen. Einfache X-Anwendungen
> wie etwa das gute, alte oclock werden erfolgreich über ssh gestartet. Aber
> alles, was openGL benutzt, scheitert mit Fehlermeldungen. Die gleichen
> Meldungen bekomme ich auch mit glxinfo:

Ich rate ja selten dazu, bei bestehenden Problemsituationen noch etwas
Komplexität hinzuzufügen, aber hast Du es mal mit X2Go statt ssh -X
versucht?

Ich habe mal eben bei mir spaßeshalber glxgears über X2Go gestartet und
das lief.

Disclaimer: Ich bin der Community Manager des X2Go-Projekts. ;-)

Linkliste zum Einstieg:
http://wiki.x2go.org/doku.php/doc:newtox2go
http://wiki.x2go.org/doku.php/doc:installation:x2goserver#debian
http://wiki.x2go.org/doku.php/doc:installation:x2goclient#ubuntu_debian
http://lists.x2go.org/listinfo/x2go-user

Gruß
Stefan

[Kai-Martin Knaak]

Stefan Baur wrote:

> hast Du es mal mit X2Go statt ssh -X
> versucht?

x2go kannte ich bis eben noch nicht.

> Ich habe mal eben bei mir spaßeshalber glxgears über X2Go gestartet und
> das lief.

Jupp. Das mit x2go geht glxgears auch hier. Sieht alles so aus, wie
erwartet.

Das war die gute Nachricht.
Leider gibt's auch noch eine weniger gute.
Die Anwendung, auf die es mir eigentlich ankommt, stürzt zwar nicht mehr
ab. Sie bekommt aber ein Problem bei der Initialisierung von openGL:

/---------------------------------
$ pcb
Could not setup GL-context!

(pcb:5415): GtkGLExt-CRITICAL **: gtk_widget_set_gl_capability: assertion
'GDK_IS_GL_CONFIG (glconfig)' failed

(pcb:5415): GdkGLExt-CRITICAL **: gdk_gl_drawable_gl_begin: assertion
'GDK_IS_GL_DRAWABLE (gldrawable)' failed
No stencil bits available.
Cannot mask polygon holes or subcomposite layers
No more stencil bits available, total of 0 already assigned
No more stencil bits available, total of 0 already assigned
(...etwa zehn Wiederholungen...)
No more stencil bits available, total of 0 already assigned

(pcb:5415): GdkGLExt-CRITICAL **: gdk_gl_drawable_is_double_buffered:
assertion 'GDK_IS_GL_DRAWABLE (gldrawable)' failed

(pcb:5415): GdkGLExt-CRITICAL **: gdk_gl_drawable_gl_end: assertion
'GDK_IS_GL_DRAWABLE (gldrawable)' failed

(pcb:5415): GdkGLExt-CRITICAL **: gdk_gl_drawable_gl_begin: assertion
'GDK_IS_GL_DRAWABLE (gldrawable)' failed
No stencil bits available.
Cannot mask polygon holes or subcomposite layers
No more stencil bits available, total of 0 already assigned
(...etwa zehn Wiederholungen...)
No more stencil bits available, total of 0 already assigned

(pcb:5415): GdkGLExt-CRITICAL **: gdk_gl_drawable_is_double_buffered:
assertion 'GDK_IS_GL_DRAWABLE (gldrawable)' failed

(pcb:5415): GdkGLExt-CRITICAL **: gdk_gl_drawable_gl_end: assertion
'GDK_IS_GL_DRAWABLE (gldrawable)' failed
kmk@hoots:~$
\--------------------------------------------

"pcb" ist die Anwendung, mit der man beim Elektronik-Paket geda die
Leiterplatten erstellt. Damit ist es so etwas wie ein spezialisiertes
Malprogramm. Als Konsequenz von den GL-Problemen bekommt man keinen
Canvas, auf dem man malen kann. Damit ist die Anwendung im wesentlichen
unbenutzbar.

> Disclaimer: Ich bin der Community Manager des X2Go-Projekts. ;-)

Dann interessiert Dich vielleicht, was mir beim Schnelleinstieg
aufgefallen ist:

* Offenbar gibt es im Debian-Repo zwar diverse Pakete für den Clienten
aber keins für den Server. Warum ist das so? Lizenzprobleme?

> Linkliste zum Einstieg:
> http://wiki.x2go.org/doku.php/doc:newtox2go

* habe ich übersprungen


> http://wiki.x2go.org/doku.php/doc:installation:x2goserver#debian

verweist nach http://wiki.x2go.org/doku.php/wiki:repositories:debian

* Hier würde ich mir einen kurzen Hinweis auf die Client-Pakete im Debian-
Repo wünschen.

* In der Einleitung wird noch auf wheezy verwiesen → jessie

* "The lenny packages will be removed from our archives at the end of
2013." → sind vermutlich nicht mehr in den Archiven.

* "squeeze: X2Go packages will be offered for Debian squeeze at least
until squeeze is still officially supported as oldstable by the Debian
project." → oldstable ist jetzt wheezy

* "deb http://packages.x2go.org/debian jessie main"
^^^^^^
"stable" funktioniert auch und veraltet nicht
"testing" scheint nicht konfiguriert zu sein

* "If you have not got a folder /etc/apt/sources.list.d/ (...)"
Das "have got" in solchen Zusammenhängen hat man mir in der Schule mühsam
abgewöhnt. Vorschlag: "Alternatively, you can append the lines to (...)"

* "$ apt-get install x2go-keyring && apt-get update"
Übersichtlicher In zwei Zeilen:
$ apt-get install x2go-keyring
$ apt-get update



> http://wiki.x2go.org/doku.php/doc:installation:x2goclient#ubuntu_debian

* Auch hier wäre ein Update von wheezy/jessie auf jessie/stretch
wünschenswert.


Danke für den Hinweis. Jetzt bin ich einen Schritt weiter. Mit den
Initialisierungsfehlern sollte ich wahrscheinlich bei den geda-Entwicklern
aufschlagen.

[Stefan Baur]

Am 10.08.2016 um 23:04 schrieb Kai-Martin Knaak:

>> Disclaimer: Ich bin der Community Manager des X2Go-Projekts. ;-)
>
> Dann interessiert Dich vielleicht, was mir beim Schnelleinstieg
> aufgefallen ist:
>
> * Offenbar gibt es im Debian-Repo zwar diverse Pakete für den Clienten
> aber keins für den Server. Warum ist das so? Lizenzprobleme?

Längere Geschichte, liegt aber nicht an Lizenzen, wir sind komplett
F/LOSS und werden das auch bleiben. Hat damit zu tun, dass wir in der
Serverkomponente Code mitschleppen, der auf einem Fork des X-Servers von
2005 oder so basiert. So was will Debian nicht im Repo haben ("Wir
brauschen kainän Gral^WX-Server, wir abän schon ainän!") - kann ich auch
verstehen. Das ist aber Work in Progress, mit dem Ziel, dass der Code im
aktuellen X-Server so weit wie möglich integriert wird, damit landet er
automatisch in Debian (und bekommt darüber auch zeitnah
Sicherheitsupdates), und der Rest sind dann Sachen, die nicht nochmal
irgendwo im X-Server-Source eh schon rumstehen, also auch keine
Dubletten mehr.
So der Plan. Das ist wie gesagt schon Work in Progress, und es gibt
Firmen, die hier finanziell involviert sind, dass das vorangetrieben wird.


[...]

>> http://wiki.x2go.org/doku.php/doc:installation:x2goserver#debian
>
> verweist nach http://wiki.x2go.org/doku.php/wiki:repositories:debian
>
> * Hier würde ich mir einen kurzen Hinweis auf die Client-Pakete im Debian-
> Repo wünschen.

Der Client mag da vorhanden sein, ist da aber noch auf Version 4.0.3.1-4
vom 07. Februar 2015.
Was wir im Projekt als "stable" ansehen, ist
4.0.5.1-0x2go1+git20160619.1180+jessie.main.1 vom 19. Juni 2016 - die
bekommst Du aus unserem Repo.

> Danke für den Hinweis. Jetzt bin ich einen Schritt weiter. Mit den
> Initialisierungsfehlern sollte ich wahrscheinlich bei den geda-Entwicklern
> aufschlagen.

Die können wiederum daher kommen, dass unser X-Server zu alt ist und von
denen benötigte Extensions (GLX, Composite, Render, ...) nicht in der
Version unterstützt, die vom Programm gefordert wird. Wenn das Programm
die Version gar nicht abprüft, sondern einfach stillschweigend davon
ausgeht, dass die Extension neu genug ist ... ich würde mal sagen, das
kann dann einen Initialisierungsfehler geben.

Genaueres können Dir sicher auch unsere kompetenten Freiwilligen
erzählen, wenn Du Dich auf der X2Go-User-Mailingliste [0] subscribest
und Deine Frage da auf Englisch stellst. Wobei, wenn es wirklich an den
Extensions liegt, X2Go-Dev [1] die passendere Mailingliste wäre.

Gruß
Stefan
[0] http://lists.x2go.org/listinfo/x2go-user
[1] http://lists.x2go.org/listinfo/x2go-dev

[Kai-Martin Knaak]

Nachtrag:

Die Verbindung mit x2go gelang mit pyhoca-cli und mit pyhoca-gui, wo man
außer der gestarteten Anwendung nur eine Art lokales Terminal hat.

Mit x2goclient konnte ich meine normale XFCE-Session starten. Die sieht so
aus und benimmt sich auch so, als ob Compositing nicht funktioniert.
(Keine Schatten, Panels nicht transparent, ...) Die Anwendung pcb zeigt in
dieser Session die gleichen Symptome wie mit pyoca.

In dem Terminal, das x2goclient auf dem Clienten gestartet hat, sehe keine
verdächtigen Warnungen:
$ x2goclient
x2go-INFO-1> "Starting X2Go Client..."
x2go-WARNING-1> "English language requested, not loading translator."
x2go-WARNING-1> "English language requested, not loading translator."
x2go-INFO-3> "Started X2Go Client."
x2go-INFO-8> "Starting connection to server: hoots:22"


Bis auf das fehlende Compositing ist das alles sehr schick und
überzeugend! Mit der Einstellung "lan" für die Netzgeschwindigkeit bemerke
ich keine Verzögerung gegenüber einem lokalen Monitor. Sogar Cairo-Dock
kommt mit seinen Animationen beim Remote an.

[Stefan Baur]

Am 10.08.2016 um 23:40 schrieb Kai-Martin Knaak:

> Die Verbindung mit x2go gelang mit pyhoca-cli und mit pyhoca-gui, wo man
> außer der gestarteten Anwendung nur eine Art lokales Terminal hat.

pyhoca-* hat einen anderen Fokus als x2goclient.
Es erlaubt z.B. mehrere parallele Sitzungen, und ist eher für
Admin-Plätze interessant. Der Entwickler nutzt es selbst und wird daher
sicher auch noch den einen oder anderen Bugfix einbauen, wenn er
notwendig wird, aber er hat sich doch stark aus dem X2Go-Projekt
zurückgezogen. Ich würde nicht sagen, pyhoca-* ist unmaintained, aber
für einen Flächeneinsatz würde ich eindeutig zu x2goclient raten.

> Mit x2goclient konnte ich meine normale XFCE-Session starten. Die sieht so
> aus und benimmt sich auch so, als ob Compositing nicht funktioniert.
> (Keine Schatten, Panels nicht transparent, ...) Die Anwendung pcb zeigt in
> dieser Session die gleichen Symptome wie mit pyoca.

Ja, das ist durchaus denkbar. Verschiedene GUIs werden mit verschiedenen
Leveln von Kompatibilität unterstützt.
KDE3/Trinity läuft wunderbar, KDE4 sollte ebenfalls tun (benutze ich
selbst nicht), Gnome2 läuft, Gnome3 dagegen (noch - ebenfalls wegen dem
alten X-Server-Code) nicht, MATE als Fork von Gnome2 funktioniert
dagegen wieder, hat aber gerade ein Problem beim Logout, dass die
Sitzung nicht sauber schließt, wenn man den offiziellen Logout-Button
benutzt (mit einem Kommandozeilenbefehl geht es, den kann man sich
natürlich auch als Icon-Link anlegen), LXDE und XFCE tun soweit ... aber
ich glaube bei LXDE war etwas, dass man eine bestimmte App kurz starten
musste, sonst wurden die Mauszeiger nicht angezeigt und man sah nur das
"X" als Mauszeiger.

> In dem Terminal, das x2goclient auf dem Clienten gestartet hat, sehe keine
> verdächtigen Warnungen:
> $ x2goclient
> x2go-INFO-1> "Starting X2Go Client..."
> x2go-WARNING-1> "English language requested, not loading translator."
> x2go-WARNING-1> "English language requested, not loading translator."
> x2go-INFO-3> "Started X2Go Client."
> x2go-INFO-8> "Starting connection to server: hoots:22"

Du kannst x2goclient --debug aufrufen, dann siehst Du mehr.

> Bis auf das fehlende Compositing ist das alles sehr schick und
> überzeugend!

Danke. Ein sehr interessantes Feature von X2GoClient sind übrigens die
Published Applications. Damit werden nur einzelne Applikationen statt
des gesamten Desktops übertragen. Dann kannst Du z.B. lokal auf Deinem
Client Gnome3 verwenden, und bekommst ein zweites Startmenü via
x2goclient eingeblendet, was Dir die auf dem Server zur Verfügung
stehenden Anwendungen anzeigt. Also im Prinzip das, was ssh -X macht,
nur mit einem schönen grafischen Startmenü.
Standardmäßig ist /etc/x2go/applications ein Symlink auf
/usr/share/applications, man kann aber auch statt dessen einen echten
Ordner anlegen und dort nur die *.desktop-Dateien anlegen/hinkopieren,
die man auch tatsächlich remote anbieten will.
Mit "Categories=X2Go-Top" in der *.desktop-Datei erhält man ein
"flaches" X2Go-Startmenü.

> Mit der Einstellung "lan" für die Netzgeschwindigkeit bemerke
> ich keine Verzögerung gegenüber einem lokalen Monitor. Sogar Cairo-Dock
> kommt mit seinen Animationen beim Remote an.

Den optimalen Wert für Slider und JPG/PNG-Kompression kannst Du
eigentlich nur durch Experimentieren ermitteln, das kommt einfach zu
sehr auf die jeweiligen Netzwerkgegebenheiten an (nicht nur Bandbreite,
auch Latenz etc.).
In meinem Heimnetz ist z.B. "WAN" performanter als "LAN".

X2Go bzw. die darunterliegende NX-Lib-Komponente ist ja schließlich
gerade dafür gemacht, auf schlechten Leitungen Bandbreite zu sparen und
Latenz zu verbessern. Wenn Du ein 10GBit-Netz hast, wird es ziemlich
sinnfrei. ;-)

(Anekdote: OpenOffice über eine 9600bit/s-Verbindung - also was man so
vor 1993 als Analogmodem hatte bzw. was bei GSM-Datenverbindungen
Standard ist/war - war mal flüssig bedienbar, mit den richtigen
Einstellungen im X2Go-Client. Habe das aber lange nicht mehr
ausprobiert, kann durchaus sein, dass es mit aktuellem OOorg/LibreOffice
nicht mehr so schön funktioniert. Youtube-Filmchen über einen 9k6-Link
anschauen sollte man dagegen gar nicht erst probieren. Im LAN
funktioniert es dagegen.)

Schleichwerbung: Wir haben vom 19.-21. August - also am Wochenende der
kommenden Woche - unser jährliches X2Go-Anwender- und Entwicklertreffen
im Linuxhotel in Essen. Da Du aus Hannover kommst, wären das 3 Stunden
einfache Fahrt mit dem Auto für Dich.
Die offizielle Anmeldefrist für die Teilnahme mit Übernachtung ist schon
abgelaufen, aber "Tagesgäste" bekommen wir auf jeden Fall nach
vorheriger Anmeldung (an <X2Go...@baur-itcs.de>) noch unter.
Für Schlafplätze ... da werden wohl Bestechungs- und Opfergaben ans
Hotelpersonal notwendig. Wir rechnen aber alles, ob Tagesgast oder
Übernachtung, zum Selbstkostenpreis ab.

Gruß
Stefan
PS: Noch etwas Schleichwerbung, wir bieten auch kommerziellen
X2Go-Support, Wartungsverträge mit garantierten Reaktionszeiten,
übernehmen Entwicklungsaufträge für Featurewünsche, etc. - mehr gerne
Off-List via kon...@baur-itcs.de.

--
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243