Mageia 7 in vmWare - Auflösung einstellen?

[Bolko]

Mageia 7 in vmWare - Wie kann man die Bildschirm-Auflösung einstellen?
Der Assistent bzw XFdrake funktionieren nicht, da die gewünschte Auflösung 1920x1080 nicht erreicht wird.

In anderen Distributionen wie ubuntu, Mint, Manjaro habe ich das bisher so gemacht:
Konsole:
cvt 1920 1080

ergibt:
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync

Konsole:
sudo xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
sudo xrandr --addmode Virtual1 "1920x1080_60.00"

fertig ist die neue Auflösung (allerdings nur temporär bis zum Neustart).

Um die Änderung zu behalten:
sudo nano ~/.profile
ganz unten 3 Zeilen ergänzen:

cvt 1920 1080
xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
xrandr --addmode Virtual1 "1920x1080_60.00"

speichern, nach Neustart ist die neue Auflösung eingestellt.

In Mageia 7 funktioniert diese Methode aber nicht.
~/.profile ist leer und wird nicht beachtet?
XFDrake bzw der Assistent (Kontrollzentrum, grafischer Server) zeigt beim Auflösungstest nur farbige Streifen an
in /etc/X11/xorg.conf habe ich die neue Modeline eingetragen
keine Wirkung...bzw nach der Anmeldung komme ich gar nicht mehr auf den Desktop, sondern falle zurück zur Anmeldung oder der Bildschirm bleibt schwarz.

Wo also trägt man die Auflösung ein und warum kann XFdrake das nicht?
Sorry, aber in dem Zustand ist Mageia einfach nicht zu gebrauchen, wenn man nichtmal normal auf grafischem Weg oder zumindest auf einem in anderen üblichen Distributionen zuverlässig funktionierenden frickel-Weg über die Konsole die Auflösung einstellen kann.

Status: Mageia Müll 7

 

[Ic3HanDs]

Hast denn auch die VMware Tools installiert? Viele Distros liefern die einfach mit bzw. installieren diese wenn die erkennen das es in einer vm läuft. Kann gut sein das Megeia es nicht macht.

 

[Bolko]

vmWare empfiehlt nicht mehr die vmware-Tools, sondern open-vm-tools.
Über den Mageia-Paketmanager habe ich die nicht gefunden, also habe ich sie dort runtergeladen und manuell installiert:
https://rpmfind.net/linux/rpm2html/search.php?query=open-vm-tools

https://rpmfind.net/linux/mageia/di...lease/open-vm-tools-10.3.10-1.mga7.x86_64.rpm

Zusatzfragen:
1. Wie füge ich ein repository zu dem Paketmanager hinzu, damit der mir die open-vm-tools anzeigt?
2. sollte man statt open-vm-tools doch besser die älteren vmware-Tools benutzen, obwohl vmware die nicht mehr empfiehlt?
3. Warum fehlt sowas in Mageia?

4. Warum fehlt die FullHD-Auflösung 1920x1080 in der Auswahlliste des Konfigurationsmenü?
Gerade diese Auflösung sollte doch drin stehen, weil sie ein wichtiger Standard ist.
Das betrifft seltsamerweise die meisten anderen Distributionen ebenso.
Darf man da mal kräftig am Verstand zweifeln?
Das ist ja so, als ob man ein Auto mit nur 3 Reifen ausliefert.

Ergänzung (16. Juli 2019)

In der Konsole:
su root
urpmi open-vm-tools open-vm-tools-desktop

Ergebnis:
das aktuelle open-vm-tools 10.3.10 war bereits installiert, aber der open-vm-tools-desktop fehlte und wurde nachinstalliert.
Das Repository ist also in Mageia vorhanden, aber das Paket wurde nur unvollständig installiert, weil der open-vm-tools-desktop fehlte.

Wenn ich anschließend in der Softwareverwaltung rpmDrake (sieht aus wie Synaptic) nach open-vm-tools suche, dann findet der immer noch nichts, obwohl die Tools jetzt definitiv installiert sind.
Bei anderen Distributionen wird es gefunden und als installiert angezeigt, in Mageia nicht.

Ergänzung (16. Juli 2019)

Fehlermeldung bei:
xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync

"kein Protokoll spezifiziert"
und
"can't open Display :0.0"

Ich weiß nicht, welches Protokoll gemeint sein könnte oder warum das Display nicht geöffnet werden kann und wozu sowas übnerhaupt notwendig sein sollte.

Andere Distributionen brauchen kein Protokoll, da geht das einfach so.
Ratlos.

Punkteabzug für:

• fehlender open-vm-tools-desktop
• falsche Anzeige in der rpmDrake (Synaptic-) Paketverwaltung, Paket ist installiert, wird aber nicht angezeigt
• fehlende Auflösung 1920x1080 in der Auswahlliste
• Konsolenbefehl funktioniert nicht, weil angeblich Protokoll und Display fehlen
• Im Assistenten funktioniert weder Automatik, noch Plug'nPlay, noch benutzerdefiniert, noch generische Auswahl des Monitors.

Status:
Mageia 7 ist bisher weiterhin unbrauchbar oder ich mache da irgendwas grundlegend falsch.

Ergänzung (16. Juli 2019)

Konsole:
xrandr

Fehlermeldung:
fehlendes Protokoll
Also fehlt xrandr in Mageia.

Synaptic finden statt dessen lxrandr und das ist installiert.
Also Konsole:
lxrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync

Ergebnis:
fehlendes Display :0.0
Aber die Protokollfehlermeldung ist weg.

Dafür gibt es eine weitere Fehlermeldung:
failed to load module: "canberra-gtk-module"

Also Versuch dieses nachzuinstallieren:

urpmi canberra-gtk-module

Ergebnis:
Kein Paket mit dem Namen canberra-gtk-module gefunden.

Na herzlichen Dank auch.

Was nun?

 

[Bolko]

ein paar Lösungen:
1. xrandr fehlte, weil ich im LXDE Desktop war anstatt im GNOME
2. Im GNOME meldet xrandr kein Protokollfehler und kein Displayfehler
3. Mageia 7 GNOME benutzt nicht Virtual1, sondern XWAYLAND0 für den "xrandr --addmode" Befehl

weitere Fehler:
Obwohl jetzt die xrandr-Befehle fehlerfrei durchgeführt werden konnten, erscheint die neue Auflösung 1920x1080 weiterhin nicht in der Auswahlliste des Assistenten XFdrake, trotz Neustart desselben.

Ergänzung (16. Juli 2019)

Obowhl ich die neue Modeline in die /etc/X11/xorg.conf eingetragen und die VM neu gestartet habe, erscheint die Auflösung weiterhin nicht im Assistenten XFdrake.

Also mal jetzt für die ganz Dummen wie mich:
Wie stellt man denn bitteschön die Auflösung in Mageia 7 GNOME XWAYLAND in einer vmWare ein?

Ergänzung (16. Juli 2019)

Fehlermeldung bei:
xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync

BadName Error of failed request (named font or color does not exist)
Major opcode of failed request : 139
Minor opcode of failed request : 16
Serial number of failed request: 20

Vorher gab es diese Fehlermeldung nicht, weil ich das per copy und paste über die Maustaste in die Konsole eingefügt hatte.
Die Konsole sprang dann ohne Fehlermeldung direkt in die neue Zeile ready zur Eingabe eines neuen Befehles.

Offenbar wurde aber der Befehl gar nicht ausgeführt.
Ist ja echt irre!

Die Konsole tut so als ob alles io wäre, gibt keine Fehlermeldung aus, dabei wurde der Befehl schlicht ignoriert.
Wo gibts denn sowas?
In Mageia 7.

Das wird ja immer besser - und ich fall vom Glauben ab.

In ubuntu, Mint, Manjaroo, debian geht es einfach so und Mageia zickt rum wie nur irgendw-ASS.

 

[Bolko]

Fundstück:

Red Hat Bugzilla (Mageia basiert auf Red Hat)

Bug 1134885 - gnome wayland session: impossible to change display resolution
Reported: 2014-08-28
Priority: none
Status: none

Ist dieser 5 Jahre alte Bug etwa immer noch nicht gefixt, weil es keinen interessierte, dass man die Auflösung nicht einstellen kann?
Also mir wäre so ein Bug peinlich und ganz weit oben auf der ToDo-Liste.

Fundstück #2:
Manually add a resolution to Gnome with Wayland
I could not find any way to do the same thing as I did for X11 but with Wayland.
override mit Kernel-Boot-Parameter:
video=DP-1:1920x1080@60
https://superuser.com/questions/1137574/manually-add-a-resolution-to-gnome-with-wayland/1168914

Ernsthaft?
Gibt es keinen anderen Weg außer Kernel-Boot-Parameter?

Ob ich eine Weston.ini habe weiß ich nicht (Weston = Wayland compositor, ob der bei Mageia eingesetzt wird weiß ich nicht).
Eine /boot/loader/entries/arch.conf sehe ich auch nicht (da kein arch linux)

Da zeigt sich auch einer meiner Denkfehler:
Da ja offenbar (oder vermutlich) Wayland benutzt wird, wird auch die /etc/X11/xorg.conf gar nicht benutzt, denn die ist ja von Xorg X11 statt von Wayland.
Wo jetzt Wayland seinen Config-Mist ablegt weiß ich nicht.

Zusatzfragen:
Wayland ist auch noch spürbar langsamer. Sollte eine Neuentwicklung (Wayland) nicht vielmehr schneller und natürlich auch leichter einfacher besser konfigurierbar sein und selbstverständlich (!!!!!) mit grafischen Tools einstellbar sein?
Welcher Vollidiot hat sich so einen Müll ausgedacht?
Wie kann ich mir überhaupt anzeigen lassen, ob jetzt Wayland benutzt wird oder etwas anderes?
Falls Wayland, warum gibt es dann noch die X11-Ordner und Konfigs?
Warum finde ich im Dateisystem Dateien, die "fedora"-irgendwas heißen, obwohl ich doch Mageia benutze?

Da hat wohl jemand einfach mal alles grob zusammengekippt, alle konfigs drin gelassen und mal hier, mal da etwas umbenannt und grafische Tools drübergelegt, die mit den konfig-Dateien nicht umgehen können.

Im Mageia-Wiki wird gleichzeitig von Wayland und xorg.conf geredet
https://wiki.mageia.org/en/Mageia_7_Errata#Non-working_graphics

Das sind doch konkurrierende Grafik-Server, im Sinne von entweder xorg X11 oder Wayland.
Dann dürfte der grafische Assistent XFdrake aber keine Konfig in die xorg.conf schreiben, wenn Wayland läuft.

Tut mir leid, aber das verstehe ich so nicht.

Also in dem Zustand echt total unbrauchbar und das bei Version 7 im Jahr 2019.

 

[Bolko]

So, ich habe ihn jetzt dazu gebracht, im Kontrollzentrum tatsächlich "korrekt" anzuzeigen (also die Soll-Werte, die ich haben möchte):

Monitor: 1920x1080
Auflösung: 1920x1080, 24 bit

Also so wäre es eigentlich richtig.
Allerdings ist die tatsächliche IST-Auflösung weiterhin natürlich völlig falsch zu klein und keinesfalls 1920x1080.

Die angezeigte Soll-Auflösung stimmt nicht mit der IST-Auflösung überein, trotz Neustart.

Zusatzfrage:
Warum zeigt mir das Kontrollzentrum dann diese falschen Werte an und warum merkt es die offensichtliche Diskrepanz zwischen Soll-Zustand und Ist-Zustand nicht?

Antwort:
Mageia 7 ist eine Verarschungs-Distribution, die so tut als ob sie etwas könnte, aber tatsächlich irgendwas anderes macht.
Das betrifft zumindest den Grafikserver (Wayland), den grafischen Assistenten XFdrake, den Paketmanager urpmi / rpmDrake

 

[lokon]

Status: none

https://bugzilla.redhat.com/show_bug.cgi?id=1134885

Status: CLOSED EOL

This issue is fixed on Fedora 25 with Gnome 3.22.

Der Bug ist geschlossen. Der getrackte Bug im Upstream Gnome der verlinkt wurde ist fixed seit 2016.

Ansonsten einen neuen Bugreport erstellen.

Bei Windows hat vmWare unter Umständen genau die gleichen Probleme, sonst gäbe es den Eintrag darüber in der vmWare KB nicht Hardwareversion kann da eine Rolle spielen.
Noch 2018 gab es ähnliche Probleme wie du sie immernoch hast - da vmWare kommerziell ist, hat sich vielleicht noch kein Entwickler um Kompatibilität gekümmert.

Wo jetzt Wayland seinen Config-Mist ablegt weiß ich nicht.

Wayland = Protokoll, weston=compositor ; Projektseite
man weston

FILES
If the environment variable is set, the configuration file is read from the respective path.

$XDG_CONFIG_HOME/weston.ini
$HOME/.config/weston.ini

Das betrifft zumindest dien Grafikserver (Wayland), den grafischen Assistenten XFdrake, den Paketmanager urpmi / rpmDrake

Es kann jeder mitarbeiten und diese Fehler melden, dokumentieren, tests entwickeln, fixen usw.

 

[Bolko]

$HOME/.config/weston.ini

So eine Datei gibt es bei mir nicht.
Ich habe dort gelesen, dass Gnome bei Wayland gar kein weston benutzt:

If you're using the Weston implementation (which apparently Gnome isn't)
[...]
At first I thought Gnome used Weston for its Wayland layer, but apparently it doesn't work that way.

https://superuser.com/questions/1137574/manually-add-a-resolution-to-gnome-with-wayland/1168914

Weiß jemand, wie GNOME das konkret macht, wenn es kein weston benutzt?

Ergänzung (16. Juli 2019)

Noch 2018 gab es ähnliche Probleme wie du sie immernoch hast

Danke für den Link.
Das Problem mit dem nicht funktionierenden shared-clipboard habe ich auch.
Es ist also vermutlich tatsächlich eine Inkompatibilität zwischen den open-vm-tools und wayland.

Gut dass das jetzt geklärt ist.
Dann kann ich also grundsätzlich keine Distribution mit Wayland in vmWare benutzen.

Wayland / Weston ist langsamer, weil es noch nicht vollständig ist und daher immer noch einen Wrapper auf x11 benötigt (Xwayland).
Daher auch der XWayland0 Anschluss (statt Virtual1).

Fedora ab 25 und Debian ab 10 benutzen ebenfalls Wayland, sind also auch nicht vmWare-tauglich.

Da lobe ich mir doch Mint und Manjaro, denn da funktioniert alles.

 

[lokon]

Weiß jemand, wie GNOME das konkret macht, wenn es kein weston benutzt?

Äh... lt. Dokumentation mutter - die Dokumentation / Wiki Einträge weisen wie üblich Defizite in der Aktualität auf - bei wikipedia scheint der aktuelle Status zu stimmen.

Mutter kann mit xorg oder wayland laufen.

Ergänzung (16. Juli 2019)

Fedora ab 25 und Debian ab 10 benutzen ebenfalls Wayland, sind also auch nicht vmWare-tauglich.

Wenn du unter diesen Distributionen XFCE installierst, dann wird Xorg benutzt.

 

[Bolko]

Äh... lt. Dokumentation mutter
[ ...]
Mutter kann mit xorg oder wayland laufen.

Danke.
mutter bei xorg war mir geläufig, aber dass das auch bei wayland im Einsatz bleibt hatte ich jetzt nicht parat.

Wenn du unter diesen Distributionen XFCE installierst, dann wird Xorg benutzt.

Was wird bei LXQT benutzt?
Das ist nämlich moderner, schlanker und sehr schnell, ähnlich wie XFCE.
QT (LXQT, KDE) ist meiner Meinung nach auch technisch besser als GTK (GNOME, Cinnamon, MATE, XFCE)., obwohl ich die Cinnamon-Umgebung wesentlich lieber mag als KDE.

 

[lokon]

Was wird bei LXQT benutzt?

Default openbox, aber es gibt auch https://wiki.ubuntuusers.de/LXDE_Fenstermanager_wechseln siehe auch LXQt issues .