Mauszeiger via rdesktop

Linux Clients
#1

Hallo,

RDP Sitzung wird nun auch gestartet, Problem nun ist, dass die Maus absolut nicht flüssig läuft…

Die Maus hängt aber nicht nach, sie läuft einfach nicht flüssig!

Wenn ich diese von A nach B schnell Bewege, sehe ich keine flüssige Führung auf dem Bildschirm, sondern eher ein leichtes ruckeln…

lG

#2

Hallo,

ich habe aus Ihrem Beitrag einmal ein eigenes Thema erstellt. Es wäre denkbar, dass die Ursache für Performanceprobleme hier bei einer langsamen Verbindung zum DVS-System oder auch langsamer Client-Hardware zu finden sind. Könnten Sie testen, inwieweit das Verhalten auch mit einer manuell gestarteten Rdesktop-Sitzung zu beobachten ist? Dies können Sie eventuell auch einmal mit der Option “-z” (Komprimierung) für rdesktop versuchen.

Generell lässt sich aber sagen, dass uns an dieser Stelle bislang keine allgemeinen Performance-Probleme bekannt sind.

Mit freundlichen Grüßen,
Tim Petersen

#3

Wie kann ich eine manuelle rdp sitzung starten??

#4

Hallo,

auf Linuxsystemen können Sie dazu rdesktop verwenden. Ein Beispielaufruf wäre:

rdesktop -u $USER -k de -g 1280x800 -a 16 host.domain.com

Weitere Informationen, auch zu der Angesprochenen Option -z, können Sie der Man-Page entnehmen.

man rdesktop

Mit freundlichen Grüßen
Tobias Scherer

#5

Hallo,

der Befehl selber ist mir schon klar, nur wie kann ich die grafische Oberfläche auf den Thin- Client starten, um den befehl absetzen zu können?!

#6

Habe das ganze nun auf einem Ubuntu Rechner getestet:

Hierbei muss ich feststellen, dass ich das Problem mit der Maus nicht habe!!

#7

Hallo,

was für Clients werden denn genau eingesetzt? Modell, Chipsatz, CPU, Grafik und RAM wären von Interesse. Ausserdem die verwendeten Grafiktreiber.

Mit freundlichen Grüßen
Tobias Scherer

#8

Es handelt sich hierbei um dieses Gerät:

google.at/imgres?q=fujitsu+f … 80&bih=902

Wie kann ich am geboteten thin client die hardware infos (hwinfo) auslesen? Wie gelange ich also zu einer command line?

#9

Hallo,

den Hardwarespezifikatonen nach ist in dem Client ein VIA VX800 Chipsatz mit entsprechendem Grafikchip verbaut. Es sind Probleme mit den auf Debian Lenny basierenden Treibern für diesen Chipsatz bekannt.
Siehe: bugs.debian.org/cgi-bin/bugreport.cgi?bug=590431

Ich vermute, dass nur der VESA Treiber verwendet werden kann, was die schlechte Performance währende der RDP Sitzung erklärt.

Haben Sie die Möglichkeit einen anderen Client zu verwenden?

UCS TCS 3.2 wird wie UCS 3.0 auf Debian Squeeze basieren, sodass dieses Verhalten dann verbessert sein sollte.

Durch Ausführen des Kommandos

univention-thin-client-sync-rootpassword

sollte auf dem Thinclient eine Anmeldung als root, mit dem entsprechenden Passwort des Terminalservers, via SSH möglich sein.

Zum ermitteln der Verbauten Chipsätze kann

lspci -vvv

verwendet werden.

Mit freundlichen Grüßen
Tobias Scherer

#10

Habe nun auf Debian 5 & 6 lokal auf der Maschine installiert, auf beiden das gleiche Phänomen…

Auf einen Ubuntu existiert dieses Problem nicht…

lG

#11

Hallo,

haben Sie Debian 5, Debian 6 und Ubuntu(welche Version?) direkt auf dem ThinClient installiert? Auf der internen Speicherkarte oder einem USB Stick?

Bitte stellen Sie die folgenden Informationen zur Verfügung:

Die Ausgabe von lspci -vvv als root auf dem ThinClient mit einem gebooteten Ubuntu(bitte Version angeben).

Die Datei/var/log/Xorg.0.log vom ThinClient mit einem gebooteten Ubuntu(bitte Version angeben).

Die Ausgabe von lspci -vvv als root auf dem ThinClient wenn dieser per PXE unter Verwendung von UCS TCS gebootet wurde.

Die Datei /var/log/Xorg.0.log vom ThinClient wenn dieser per PXE unter Verwendung von UCS TCS gebootet wurde.

Hinweise zum Debugging und der Anmeldung als root an einem Thinclient finden Sie im Univention Wiki unter den folgenden Links
SSH-Zugriff_auf_Thin_Clients
TCS-Fehlersuche_bei_Grafikproblemen

Ausserdem wäre es Hilfreich einmal einen Test mit einem anderen Gerät, bspw. einem Notebook oder Desktopsystem mit bestenfalls Intel Grafikkarte durchzuführen. Das Gerät sollte über PXE unter Verwendung von UCS TCS gebootet werden. Dann sollte geprüft werden ob dasselbe Verhalten beobachtet werden kann. Der Vollständigkeit halber sollten auch von diesem System die Ausgabe des Befehls lspci -vvv sowie die Datei /var/log/Xorg.0.log übermittelt werden.

Mit freundlichen Grüßen
Tobias Scherer

#12

Hallo,

soweit uns bekannt ist konnte das Problem auf den Futro S100 zurückgeführt werden. Mit einem alternativen Client (Futro S450-2) konnte das Problem nicht mehr reproduziert werden.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon