X.org kann per "X -configure" eigenständig aus der vorhandenen Hardware eine X-Konfiguration erstellen. Die könnten wir parsen und für unsere Baseconfig-Variablen verwenden, anstatt immer Vesa und 1024x768 zu nutzen.
Ganz darauf verlassen kann man sich übrigens nicht, bei mir im VMplayer mit UCS 2.0 erkennt er korrekt vmware als Treibermodul, findet dann aber keine Maus.
Die volle Auto-Erkennung ist erst mit der 1.3er ABI der XServer möglich. Ein Blog-Eintrag eines der X.org-Entwickler dazu: http://bgoglin.livejournal.com/10513.html Mit der Version in 2.0/Etch sollten wir uns auf Display- und Grafikkarten-Erkennung beschränken, das funktioniert auch mit 1.2 schon zuverlässig.
Wir sollten per Default versuchen X die Konfiguration eigenständig zu erstellen. Durch das Setzen einer UCR-Variable sollte die alte X-Konfiguration wieder hergestellt werden können.
Die X Auto-Detection funktioniert so, dass man einfach die Xorg-Konfiguration leer lässt bzw. nur Dinge einträgt, die man definitiv setzen möchte. Alles andere wird automatisch erkannt. Ich habe jetzt eine Variable xorg/autodetect erstellt. Ist diese auf 'yes' gesetzt (per default im postinst), werden einfach alle Einstellungen ignoriert. Anderenfalls wird wie zuvor die Konfiguration erstellt. Im postinst werden jetzt weiterhin die Variablen auf Standardwerte gesetzt, die dann greifen, wenn xorg/autodetect auf no gesetzt wird. Für das GDM-Theme ist es weiter wichtig, dass die Auflösung des X-Servers bekannt ist, weil in Abhängigkeit von der Auflösung die Theme-XML-Datei umgeschrieben wird. univention-x-core mit dieser Variante wird gerade gebaut.
Das Update-Szenario ist etwas schwierig: Entweder das wird groß im Changelog dokumentiert oder der Default beim Update muss ein anderer sein. Da es aus UCS-Sicht ein minor-Update ist halte ich letzteres für sinnvoll. Das gilt auch für den Umgang mit Display-Richtlinien an Thin Clients.
(In reply to comment #5) > Das Update-Szenario ist etwas schwierig: Entweder das wird groß im Changelog > dokumentiert oder der Default beim Update muss ein anderer sein. Da es aus > UCS-Sicht ein minor-Update ist halte ich letzteres für sinnvoll. > > Das gilt auch für den Umgang mit Display-Richtlinien an Thin Clients. > Es sollte im Changelog und auch kurz in den Release Notes erwähnt werden. Das neue Verhalten sollte nur bei einer Neuinstallation Default sein. Bei Updates sollte das alte Verhalten so bleiben wie es ist. Sobald eine Richtlinie gesetzt ist, sollte diese verwendet werden.
(In reply to comment #6) > (In reply to comment #5) > > Das Update-Szenario ist etwas schwierig: Entweder das wird groß im Changelog > > dokumentiert oder der Default beim Update muss ein anderer sein. Da es aus > > UCS-Sicht ein minor-Update ist halte ich letzteres für sinnvoll. > > > > Das gilt auch für den Umgang mit Display-Richtlinien an Thin Clients. > > > > Es sollte im Changelog und auch kurz in den Release Notes erwähnt werden. Das fehlt noch > Das neue Verhalten sollte nur bei einer Neuinstallation Default sein. Bei > Updates sollte das alte Verhalten so bleiben wie es ist. Die Variable wird jetzt nur bei der Installation auf yes gesetzt, sonst auf no. > Sobald eine Richtlinie gesetzt ist, sollte diese verwendet werden. Dafür gibt es jetzt an der Richtlinie ein neues bool'sches Attribut, dass mittels mapping dafür sorgt, dass xorg/autodetect gesetzt wird.
ChangeLog und Release-Notes Eintrag habe ich hinzugefügt.
Auf einer VMware-Standard Installation habe ich jetzt einen GDM mit 640x480.
Die Automatische Erkennung wird jetzt nicht in der Voreinstellung aktiviert. Wird sie manuell durch setzen von xorg/autodetect auf yes aktiviert, so wird über ein gdm Init Skript dafür gesorgt, dass die erkannte Auflösung in xorg/resolution gesetzt wird, damit sich das GDM Theme anpassen kann.
Das funktioniert in meinem 2.3 Thin Client nicht: - nach Setzen der Richtlinie steht xorg/autodetect weiter auf "no" - nach Setzen von xorg/autodetect auf "yes" oder "1" bleibt die xorg.conf trotzdem erhalten Ein "echo "" > /etc/xorg.conf" ist übrigens auf dem Futro S300 hier erfolgreich.
(In reply to comment #11) > Das funktioniert in meinem 2.3 Thin Client nicht: > > - nach Setzen der Richtlinie steht xorg/autodetect weiter auf "no" > - nach Setzen von xorg/autodetect auf "yes" oder "1" bleibt die xorg.conf > trotzdem erhalten > > Ein "echo "" > /etc/xorg.conf" ist übrigens auf dem Futro S300 hier > erfolgreich. Was wird denn mit der Auto-Erkennung alles erkannt? Besteht die Möglichkeit, Hardware und Monitor-Parameter zu erkennen, die Auflösung aber fest vorzugeben oder wird dann automatisch die höchstmögliche genommen?
Es fehlt noch ein Mechanismus für das GDM-Theme, bei der autokonfiguration wurde hier korrekt Full-HD erkannt, der Login sitzt aber oben links. Sieht von den Abständen her aus wie für 1024x768. Über die wahl des geeigneten Hintergrundbildes müsste man auch nachdenken, je nach Seitenverhältnis und Auflösung ist das Bild verzerrt und/oder verpixelt.
(In reply to comment #13) > Es fehlt noch ein Mechanismus für das GDM-Theme, bei der autokonfiguration > wurde hier korrekt Full-HD erkannt, der Login sitzt aber oben links. Sieht von > den Abständen her aus wie für 1024x768. Das wurde meines Wissens als Pre-GDM-Skript implementiert. Ggf. wird das gerade aufgrund von Bug #15296 nicht ausgewertet.
(In reply to comment #12) > (In reply to comment #11) > > Das funktioniert in meinem 2.3 Thin Client nicht: > > > > - nach Setzen der Richtlinie steht xorg/autodetect weiter auf "no" > > - nach Setzen von xorg/autodetect auf "yes" oder "1" bleibt die xorg.conf > > trotzdem erhalten > > > > Ein "echo "" > /etc/xorg.conf" ist übrigens auf dem Futro S300 hier > > erfolgreich. > > Was wird denn mit der Auto-Erkennung alles erkannt? Besteht die Möglichkeit, > Hardware und Monitor-Parameter zu erkennen, die Auflösung aber fest vorzugeben > oder wird dann automatisch die höchstmögliche genommen? Das ist momentan noch nicht möglich. Dazu habe ich einen neuen Bug #15960 angelegt.
(In reply to comment #13) > Es fehlt noch ein Mechanismus für das GDM-Theme, bei der autokonfiguration > wurde hier korrekt Full-HD erkannt, der Login sitzt aber oben links. Sieht von > den Abständen her aus wie für 1024x768. > > Über die wahl des geeigneten Hintergrundbildes müsste man auch nachdenken, je > nach Seitenverhältnis und Auflösung ist das Bild verzerrt und/oder verpixelt. Stefans Vermutung war richtig. Das wird über das Skript /etc/gdm/Init/scripts/00_resolution gemacht. Das fehlte nur im Paket.
(In reply to comment #11) > Das funktioniert in meinem 2.3 Thin Client nicht: > > - nach Setzen der Richtlinie steht xorg/autodetect weiter auf "no" > - nach Setzen von xorg/autodetect auf "yes" oder "1" bleibt die xorg.conf > trotzdem erhalten > > Ein "echo "" > /etc/xorg.conf" ist übrigens auf dem Futro S300 hier > erfolgreich. Das kann ich nicht reproduzieren
Das UCR-Template für univention-gdm/conffiles/etc/gdm/Init/scripts/00_resolution muss eine 00_resolution-Datei erzeugen, die executable ist (das kann über eine mode:-Anweisung in der UCR-Registrierung erreicht werden), ansonsten wird die Datei durch das run-parts aus /etc/gdm/Init/Default nicht ausgewertet.
*** Bug 15986 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > *** Bug 15986 has been marked as a duplicate of this bug. *** svn revision 12928 Vor dem Commit war die Init-Datei nicht im UCR Template von univention-gdm deklariert.
Auf meinem 2.3 Master habe ich autodetect in vmware aktiviert, er fällt dann auf 800x600 zurück. Das eigentliche Problem: das GDM-Theme ist für 1024x768, der GDM ist nur schwer zu benutzen.
(In reply to comment #21) > Auf meinem 2.3 Master habe ich autodetect in vmware aktiviert, er fällt dann > auf 800x600 zurück. Das eigentliche Problem: das GDM-Theme ist für 1024x768, > der GDM ist nur schwer zu benutzen. Das ist jetzt korrigiert.
Ich habe mein X61 mit 2.3 neu installiert und mit den Standardwerten wird nur der VESA-Treiber verwendet. Erst wenn ich die Autoerkennung aktiviere, wird auch der Intel-Treiber verwendet und alles funktioniert wie erwartet. Da die X.org-Autoerkennung in Lenny und allen anderen Distributionen Standard ist, sollten wir das bei Neuinstallationen auch aktivieren, bzw. zumindest bei den Systemrollen Managed/Mobile Client aktivieren. Der Verhalten mit der niedrigen Auflösung in Vmware kann auch gut an unserer veralteten Vmware-Server-Version liegen kann. Alternativ könnte man eine Installation in Vmware auch im Postinst erkennen und dann xorg/autodetect auf no setzen.
(In reply to comment #23) > Ich habe mein X61 mit 2.3 neu installiert und mit den Standardwerten wird nur > der VESA-Treiber verwendet. Erst wenn ich die Autoerkennung aktiviere, wird > auch der Intel-Treiber verwendet und alles funktioniert wie erwartet. > > Da die X.org-Autoerkennung in Lenny und allen anderen Distributionen Standard > ist, sollten wir das bei Neuinstallationen auch aktivieren, bzw. zumindest bei > den Systemrollen Managed/Mobile Client aktivieren. Ich denke das macht Sinn, das sollte dann bei Neuinstallationen für Managed und Mobile Clients gesetzt werden.
(In reply to comment #24) > Ich denke das macht Sinn, das sollte dann bei Neuinstallationen für Managed und > Mobile Clients gesetzt werden. Das wird jetzt im postinst von univention-x-core umgesetzt.
Ich habe jetzt diverse dinge ausprobiert. Nach dem Update eines masters auf von 2.2-2 auf 2.3 war die Variable auf no gesetzt. => OK Nach der Installation eines Managed und eines Mobile Clients war die Variable auf yes gesetzt. Die Auto-Erkennung hat ebenfalls funktioniert. => OK Die Platzierung der Elemente im GDM war incl. des Hintergrundbilder richtig. Das hat auch bei geänderten Auflösungen funktionier. => OK Mit 16:9 Auflösungen habe ich das noch nicht richtig testen können. Soll das noch geprüft werden? Wenn die in der Display-Richtlinie vorgegebenen Werte nicht angewendet werden können wird ein Fall back versucht. (Ohne Auto-Erkennung) Es kann dadurch passieren das zwar eine Auflösung von 640x480 in der Richtlinie steht, aber eine von 1920x1200 benutzt wird. Dies führt dazu das die Elemente am GDM-Login viel zu klein/groß aussehen und ggf. auch nicht benutzt werden könne. (Keine Eingabe im Textfeld, Button ohne Funktion) => FEHLER?
(In reply to comment #26) > Mit 16:9 Auflösungen habe ich das noch nicht richtig testen können. Soll das > noch geprüft werden? Ja, das sollte nach dem Update in unserer Umgebung noch geprüft werden. > Wenn die in der Display-Richtlinie vorgegebenen Werte nicht angewendet werden > können wird ein Fall back versucht. (Ohne Auto-Erkennung) > > Es kann dadurch passieren das zwar eine Auflösung von 640x480 in der Richtlinie > steht, aber eine von 1920x1200 benutzt wird. Dies führt dazu das die Elemente > am GDM-Login viel zu klein/groß aussehen und ggf. auch nicht benutzt werden > könne. > (Keine Eingabe im Textfeld, Button ohne Funktion) > => FEHLER? Bitte einen separaten Bug dazu erstellen, das sollte gesondert umgesetzt werden. Im Moment setzen wir beim Starten von X in einem Pre-Skript die Auflösung auf den tatsächlichen Wert, so dass das richtige GDM-Theme verwendet werden kann. Das machen wir im Moment aber nur bei der automatischen Erkennung.
(In reply to comment #27) > Bitte einen separaten Bug dazu erstellen, das sollte gesondert umgesetzt > werden. Im Moment setzen wir beim Starten von X in einem Pre-Skript die > Auflösung auf den tatsächlichen Wert, so dass das richtige GDM-Theme verwendet > werden kann. Das machen wir im Moment aber nur bei der automatischen Erkennung. Wieder zu.
Zu dem Problem aus Kommentar 26/27 habe ich Bug #16383 auf gemacht. Ein Test mit einer 16:9'er Auflösung (HD, 1920x1080) war erfolgreich. Die Button am GDM Login waren korrekt positioniert. Der Boot-Splash war etwas verzogen aber ich nehme an das dies ein separates Problem ist. => VERIFIED
UCS 2.3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".