Wayland : Was für ein Trauerspiel
- Ersteller bluescreen
- Erstellt am
bluescreen
verstört
Moin nochmal !
@pit234a Zum Thema neu-lernen !
Als erstes vorweg , Wayland an sich wird nicht Konfiguriert ! Das wird alles vom DE oder WM übernommen !
Die Grafikkarte läuft von Haus aus , vorausgesetzt die Karte unterstützt DRM/KMS !
Was bei Intel- und AMD Karten eigentlich der Fall ist !
Als Beispiel mal die config (weston.ini) für den Weston-WM :
[core]
backend=drm-backend.so
xwayland=false
[keyboard]
keymap_layout=de
[output]
name=card0-DP-1
mode=3840x1080
transform=90
[shell]
type=desktop-shell.so
background-image=/home/bluescreen/bilder/green.jpg
#background-color=0xff002200
panel-color=0x55550000
locking=true
animation=zoom
binding-modifier=ctrl
num-workspaces=4
[launcher]
icon=/home/bluescreen/.icons/Hedera/24/applications/utilities-terminal.png
path=/usr/bin/xfce4-terminal
Das ist alles und das meiste ist selbsterklärend ! Und so funktioniert es bei allen anderen
Wayland-Compositor`s auch !
Unterschiede gibts im Speicherformat der Ini-Dateien . XML,YML .... und so weiter .....
Also eher schmerzbefreit....
Gruss
@pit234a Zum Thema neu-lernen !
Als erstes vorweg , Wayland an sich wird nicht Konfiguriert ! Das wird alles vom DE oder WM übernommen !
Die Grafikkarte läuft von Haus aus , vorausgesetzt die Karte unterstützt DRM/KMS !
Was bei Intel- und AMD Karten eigentlich der Fall ist !
Als Beispiel mal die config (weston.ini) für den Weston-WM :
[core]
backend=drm-backend.so
xwayland=false
[keyboard]
keymap_layout=de
[output]
name=card0-DP-1
mode=3840x1080
transform=90
[shell]
type=desktop-shell.so
background-image=/home/bluescreen/bilder/green.jpg
#background-color=0xff002200
panel-color=0x55550000
locking=true
animation=zoom
binding-modifier=ctrl
num-workspaces=4
[launcher]
icon=/home/bluescreen/.icons/Hedera/24/applications/utilities-terminal.png
path=/usr/bin/xfce4-terminal
Das ist alles und das meiste ist selbsterklärend ! Und so funktioniert es bei allen anderen
Wayland-Compositor`s auch !
Unterschiede gibts im Speicherformat der Ini-Dateien . XML,YML .... und so weiter .....
Also eher schmerzbefreit....
Gruss
Hallo Azazyel,
Irgendwo auf der Welt gibt es immer jemanden der sich über alte Hardware freut.
Ich hatte vor einiger Zeit über jemanden aus Südamerika gelesen, der hat sich so unfassbar gefreut, dass sich auf seiner alten Mühle ein OpenBSD auch in einer neuen Version installieren ließ. Die Mühle war über zwanzig Jahre alt.
Auf meinem alten Dell (OptiPlex 330 von 2008) macht OpenBSD auch einen netten Eindruck. Ich wüßte jetzt nicht, warum den zum Wertstoffhof bringen sollte.
Nur mal so als Gedanke. :-)
Beste Grüße und sonniges Wochenende.
Jonas
Der Wertstoffhof nimmt die gerne entgegen.
Irgendwo auf der Welt gibt es immer jemanden der sich über alte Hardware freut.
Ich hatte vor einiger Zeit über jemanden aus Südamerika gelesen, der hat sich so unfassbar gefreut, dass sich auf seiner alten Mühle ein OpenBSD auch in einer neuen Version installieren ließ. Die Mühle war über zwanzig Jahre alt.
Auf meinem alten Dell (OptiPlex 330 von 2008) macht OpenBSD auch einen netten Eindruck. Ich wüßte jetzt nicht, warum den zum Wertstoffhof bringen sollte.
Nur mal so als Gedanke. :-)
Beste Grüße und sonniges Wochenende.
Jonas
Ja, irgendwelche Kinder in Afrika die die einschmelzen müssen um an die Edelmetalle zu kommen
Weil du für 0,0 EUR (Landet sonst auch auf dem Schrott) wesentlich neuere Kisten bekommen kannst.Wenn du im Schrott wesentlich neuere Kisten vollfunktionsfähig bekommst, warum dann noch die älteren weiterverwenden?
Bitte nicht falsch verstehen, ich habe aus "Bastelspaß" und "Nostalgie" auch diverse ältere Geräte, z.B. Thinkpads X31, X61 der Pentium 4 und Core2Duo Generation.
Ich finds toll da aktuelle OSSes drauf installieren zu können (ein X61 hat sogar Windows 10) und denen begrenzt sogar noch eine Nutzung zukommen zu lassen, aber wenn dann feature X (Wayland) nicht mehr geht ist das halt für mich so. Die meisten älteren Geräte verwende ich auch eher mit der Software aus der Zeit, halt "Nostalgie" - und natürlich mit passenden Schutzmaßnahmen..
Ne gewisse Kompatibilität für ältere Geräte finde ich auch gut, gerade aus Umweltschutz um Ressourcen bei der Herstellung und im "Recycling" sparen zu können.
Aber man muss 2020 wirklich keine Core2Duo oder 1. Generation i5 oder so zwangsweise noch unterstützen wenn die unterstützung die ohnehin begrenzten Ressourcen zu stark belastet.
Idefixx
Well-Known Member
Eine gewisse Kompatibilität . . . zum Glück gibt es die unter Windows wirklich.
Ich nutze auch heute noch CorelDRAW 9 von 1999; mehr brauche ich heute auch nicht. Seit Vista läuft es allerdings nur noch unter FAT32, aber da problemlos. Auch Photoshop 7.1 funktioniert unter Win 10 Pro 2004 absolut problemlos; ohne FAT32. Das nenne ich nachhaltig. Wo gibt es so etwas bei den X-Systemen?
Ich bin zwar seit 2002/2003 kein Webdesigner mehr, aber wenn ich es noch wäre . . . ob ich mich da dieser verdammten abhängigen Cloud unterwerfen würde? Nur wenn es um die blanke Existenz ginge. Mit PS 7.1 könnte ich alles machen, was man auch mit dem neusten Cloud-Krempel macht, es wäre nur mehr Handarbeit; aber die würde Zeit & Geld kosten.
Über PS gibt es ja genug Bilder, hier mal eins, was man mit CorelDRAW 9 machen konnte, wenn man es konnte.
Und CorelDRAW 9 läuft wirklich noch.
Anhänge
berni51
Open-Net-FreeBSD user
Hab mir gerade mal einen Live-stick mit RebeccaBlackOS-Linux gebastelt. Das System läuft mit Wayland und so hab ich mal 2 Stündchen gespielt. Ist eigentlich recht nett, aber ganz sicher noch unfertig.
Aber es hat sich nur ganz wenig nach einem Unix angefühlt, mehr wie seinerzeit die ersten Betaversionen von OS/2. Schätze trotzdem, dass daraus was wird im Laufe der Zeit.
Jedenfalls ein nettes Spielzeug, auch für pit234a, kann ja nix kaputt gehen dabei.
Aber es hat sich nur ganz wenig nach einem Unix angefühlt, mehr wie seinerzeit die ersten Betaversionen von OS/2. Schätze trotzdem, dass daraus was wird im Laufe der Zeit.
Jedenfalls ein nettes Spielzeug, auch für pit234a, kann ja nix kaputt gehen dabei.
Da muss man eigentlich gar nicht zu Exoten greifen. Wenn ich mich recht erinnere bietet Debian mit Gnome automatisch Wayland an (zumindest als Option im GDM).
Läuft bei mir seit Monaten problemlos und unauffällig. Bewusst wird es einem eigentlich nur wenn man mal was spielen will und die Grafikeinstellungen die Auflösung nicht ändern lassen oder man mit alten Tools nen Screenshot machen will. Ich bin damit an sich zufrieden.
Läuft bei mir seit Monaten problemlos und unauffällig. Bewusst wird es einem eigentlich nur wenn man mal was spielen will und die Grafikeinstellungen die Auflösung nicht ändern lassen oder man mit alten Tools nen Screenshot machen will. Ich bin damit an sich zufrieden.
bluescreen
verstört
@Rakor Kleiner Tipp fürs Spielen .
Aus dem Arch-Wiki :
SDL2
To run a SDL2 application on Wayland, set SDL_VIDEODRIVER=wayland.
Note: Many proprietary games come bundled with old versions of SDL, which don't support Wayland and might break entirely if you set SDL_VIDEODRIVER=wayland. To force the application to run with XWayland, set SDL_VIDEODRIVER=x11.
Gruss
Aus dem Arch-Wiki :
SDL2
To run a SDL2 application on Wayland, set SDL_VIDEODRIVER=wayland.
Note: Many proprietary games come bundled with old versions of SDL, which don't support Wayland and might break entirely if you set SDL_VIDEODRIVER=wayland. To force the application to run with XWayland, set SDL_VIDEODRIVER=x11.
Gruss
Ohne jetzt den ganzen Thread gelesen zu haben: Ich bin bei sowas kein "early adopter". Wobei "early" beim Thema "Wayland" so langsam seine eigene Ironie birgt. Ich hab n bisschen was dazu gelesen, ich kann die Gründe nachvollziehen, warum X11 vielleicht nicht "die Zukunft" ist. Es ist Tatsache, dass heute keiner mehr das "nackte" X11 Protokoll über ein Netzwerk nutzen möchte, viel zu ineffizient. Es ist auch Tatsache, dass X-Clients ohne jede Klassifizierung laufen, was sowas wie "Bildschirm sperren" zur Herausforderung werden lässt -- wohlgemerkt zu einer, die nicht absolut zufriedenstellend gelöst werden kann. Trotzdem: Ein Projekt wie Wayland muss sich erst mal beweisen. Es braucht da Überzeugungsarbeit, wenn man etwas im Prinzip gut funktionierendes ersetzen will, denn es steht immer die Frage im Raum: könnte man nicht die Schwächen des existierenden beseitigen, ohne es komplett über den Haufen zu werfen? Solche Dinge sind einer der Gründe, warum ich Linux den Rücken gekehrt habe und inzwischen mit FreeBSD recht glücklich bin. FreeBSD musste nicht /dev/dsp durch etwas überkomplexes (also, kompliziertes, im wahrsten Sinne des Wortes) wie ALSA ersetzen, um gut zu klingen ... nur so als ein kleines Beispiel
Wir werden ja sehen, was aus der Wayland Ecke noch kommt. Wenn es wirklich überzeugend ist, wird es X11 ersetzen. Mal sehen
Wir werden ja sehen, was aus der Wayland Ecke noch kommt. Wenn es wirklich überzeugend ist, wird es X11 ersetzen. Mal sehen
-Nuke-
Well-Known Member
Das ist halt das Problem an grundlegenden Design-Problemen. Du kannst sie nicht einfach "fixen". Man hat ewig an X herumentwickelt, konnte aber viele Probleme nie richtig lösen. Darum sind so Dinge wie VSync auch heute noch eine ziemliche Herausforderung bei X.
Dieses "Wir fixen einfach X" wurde einfach viel zu lange betrieben und besteht aus zu vielen Workarounds und Hacks. Jetzt sind wir halt schon soweit, dass kaum noch jemand an dem Moloch "Xorg" arbeiten will. Die Codebasis ist die reinste Katastrophe.
-Nuke-
Well-Known Member
Ein Intel-Entwickler hat es ja vor kurzem mal gewagt das auszusprechen, was viele immer gerne unter den Teppich kehren: "xserver is abandonware" ( https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/533#note_670522 ). Es hat sich jetzt dann auch der ehemalige Release-Manager von Xorg gemeldet: https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html
tl;dr: Ja, der XServer ist Abandonware. Niemand hat mehr Lust daran zu arbeiten. Wer was daran ändern will, soll sich melden.
tl;dr: Ja, der XServer ist Abandonware. Niemand hat mehr Lust daran zu arbeiten. Wer was daran ändern will, soll sich melden.
Ich hab das auch gelesen (auf Golem) und zum anlass genommen, mal wieder Wayland zu probieren.
Ich hab hier ein aktuelles Tumbleweed mit KDE 5.20.1.1
Fazit: Touchpad vom Thinkpad funktioniert nicht ordentlich, Fenster per Tastatur verschieben funktioniert nicht, das Design von nicht KDE Anwendungen (vorallem über Flatpak installierte Sachen) ist schrecklich. Habs dann nach ner halben Stunde wieder entfernt.
Auch wenn ichs gern probieren würde, X läuft leider immer noch um längen besser. Vielleicht wärs mit ganz viel frikelarbeit brauchbar, aber die bin ich nicht bereit zu investieren. Die Zeiten der xorg.conf wünsche ich mir ja auch nicht zurück.
Ich hab hier ein aktuelles Tumbleweed mit KDE 5.20.1.1
Fazit: Touchpad vom Thinkpad funktioniert nicht ordentlich, Fenster per Tastatur verschieben funktioniert nicht, das Design von nicht KDE Anwendungen (vorallem über Flatpak installierte Sachen) ist schrecklich. Habs dann nach ner halben Stunde wieder entfernt.
Auch wenn ichs gern probieren würde, X läuft leider immer noch um längen besser. Vielleicht wärs mit ganz viel frikelarbeit brauchbar, aber die bin ich nicht bereit zu investieren. Die Zeiten der xorg.conf wünsche ich mir ja auch nicht zurück.
Ich hatte ebenfalls ein KDE 5.20 mit Wayland getestet, wie eigentlich jedes KDE-Release der letzten Zeit. Und ich kann deine Erfahrungen bestätigen. Auch wenn es tendenziell besser wird und gegenüber KDE 5.19 durchaus Fortschritte erkennbar sind, ist es im derzeitigen Zustand unbrauchbar. Das sieht woanders übrigens nicht besser aus. Alle Compositoren mit Ausnahme von Mutter (Gnome) und Sway sind meiner Erfahrung nach für den täglichen Einsatz zu unausgereift.
Allerdings ist eine klare Ansage, was die Zukunft des xorg-server als Displayserver berifft, vielleicht genau das, was lange überfällig war. xorg-server ist ausgereifter Code, zumindest so ausgereift, wie er denn sein kann. Auch wenn niemand mehr neue Features entwickelt oder wenigstens Bugfixes vornimmt, wird xorg-server wahrscheinlich noch einige Jahre anstandslos funktionieren. Und Adam Jackson hat bereits klar gestellt, dass Red Hat den xorg-server bis EOL von RHEL 8 (ich glaube Ende 2024) maintainen wird, was die Gnadenfrist noch einmal verlängert. Es ist also kein akuter Beinbruch, aber ein deutlicher Hinweis, dass die verschiedenen Desktop-Projekte ihre Wayland-Unterstützung in den Griff bekommen müssen. Sonst heißt es zwangsläufig irgendwann zusammen mit dem xorg-server unterzugehen.
Zumindest bei KDE scheint die Nachricht angekommen zu sein, man hat gerade mehrere X11-Features (u.a. Skalierung pro Display) gestrichen, um sich voll und ganz auf Wayland zu konzentrieren.
Es ist aber auch ein Tritt in Richtung Nvidia auf der einen und den Entwicklern freier Treiber auf der anderen Seite den endlosen, in Teilen nur noch aus Prinzip geführten Kleinkrieg irgendwie zu beenden. Denn solange Nvidia auf EGLStreams besteht und GBM nicht unterstützt, werden Wayland-Compositoren es schwer haben sich durchzusetzen. Anzunehmen, dass man sie mit der Brechstange gegen Nvidias Marktmacht durchsetzen kann, ist naiv. Damit schwächt man letztendlich die eh schon nicht gerade rosige Position des Linux-Desktops nur noch mehr.
Allerdings ist eine klare Ansage, was die Zukunft des xorg-server als Displayserver berifft, vielleicht genau das, was lange überfällig war. xorg-server ist ausgereifter Code, zumindest so ausgereift, wie er denn sein kann. Auch wenn niemand mehr neue Features entwickelt oder wenigstens Bugfixes vornimmt, wird xorg-server wahrscheinlich noch einige Jahre anstandslos funktionieren. Und Adam Jackson hat bereits klar gestellt, dass Red Hat den xorg-server bis EOL von RHEL 8 (ich glaube Ende 2024) maintainen wird, was die Gnadenfrist noch einmal verlängert. Es ist also kein akuter Beinbruch, aber ein deutlicher Hinweis, dass die verschiedenen Desktop-Projekte ihre Wayland-Unterstützung in den Griff bekommen müssen. Sonst heißt es zwangsläufig irgendwann zusammen mit dem xorg-server unterzugehen.
Zumindest bei KDE scheint die Nachricht angekommen zu sein, man hat gerade mehrere X11-Features (u.a. Skalierung pro Display) gestrichen, um sich voll und ganz auf Wayland zu konzentrieren.
Es ist aber auch ein Tritt in Richtung Nvidia auf der einen und den Entwicklern freier Treiber auf der anderen Seite den endlosen, in Teilen nur noch aus Prinzip geführten Kleinkrieg irgendwie zu beenden. Denn solange Nvidia auf EGLStreams besteht und GBM nicht unterstützt, werden Wayland-Compositoren es schwer haben sich durchzusetzen. Anzunehmen, dass man sie mit der Brechstange gegen Nvidias Marktmacht durchsetzen kann, ist naiv. Damit schwächt man letztendlich die eh schon nicht gerade rosige Position des Linux-Desktops nur noch mehr.
Die KDE-Probleme sind bekannt und in Arbeit - aktuell ist KDE und Wayland eine schlechte Kombination, was aber nicht an Wayland liegt.
Siehe oben - probier es mal z.B. mit GNOME/mutter, sway oder einem anderen Compositor, dessen Wayland-Support besser ist.
Das sind hervorragende Nachrichten für den Unix-Desktop, wenn jemand mit Autorität mal den Finger in die Wunde legt und das Offensichtliche ausspricht.
Wer würde sich freiwillig melden, um auf ein totes Pferd aufzusteigen?
Wer möchte enorme Energie aufwenden, um den Stillstand auf dem Unix-Desktop zu unterstützen, anstatt an der Verbesserung desselbigen zu arbeiten?
Es wird in unser aller Interesse Zeit, dass der XServer stirbt.
Wer nicht mit der Zeit geht, wird mit der Zeit gegangen. Wenn ein Projekt bis 2024 die Ablösung nicht schafft, dann hat es sich den Untergang redlich verdient.
Auf die Auflösung dieses Dramas bin ich auch gespannt.
-Nuke-
Well-Known Member
Nvidia hat mehrfach gezeigt, dass sie kein Interesse haben. Wenn es nach Nvidia gehen würde, hätte man schon längst komplette (geschlossene) Nvidia-Only Pfade im Kernel. Das ganze CUDA und RTX Ökosystem zeigt auch, dass Nvidia kein gesteigertes Interesse an offenen Lösungen hat. Sämtliche Alternativen einstellen, nur weil ein Hersteller kein Bock hat, ist halt auch nicht zielführend.
Und unmöglich ist nichts. Schaut euch mal an was ein Anfangs kleines Container Tool namens Docker bei so Industrie Riesen wie Microsoft angerichtet hat. Wer hätte das damals vermutet. Und Wayland hat mehr Einsatzbereiche als nur KDE oder GNOME zu bedienen.
Und unmöglich ist nichts. Schaut euch mal an was ein Anfangs kleines Container Tool namens Docker bei so Industrie Riesen wie Microsoft angerichtet hat. Wer hätte das damals vermutet. Und Wayland hat mehr Einsatzbereiche als nur KDE oder GNOME zu bedienen.
Wir hatten ja vor einem halben Jahr die großangelegte Diskussion zum Thema, wie Container nicht nur Windows das Wasser ziemlich abgegraben.
Im Embedded-Bereich wird der Support für X11 schon nach und nach eingestellt.
Auf dem Desktop bin ich mir aber ziemlich sicher, dass der Kombination aus Solaris, X11 und Sparc die Zukunft gehört.
turrican
Well-Known Member
Auf dem Desktop bin ich mir aber ziemlich sicher, dass der Kombination aus Solaris, X11 und Sparc die Zukunft gehört.
YMMD...
Wie es aussieht, muss man am Ende so oder so akzeptieren, dass mit Xserver auch viele Anwendungen und Tools sterben werden, die man im Moment noch tagtäglich nutzt. Als Beispiel: Openbox. Stattdessen wird sich waybox oder labwc oder sonst eine andere Entwicklung durchsetzen - mit neuen Tools und Lösungen. Ich denke, die aktuelle Situation ist wohl der klassische Fall von "ein Schritt zurück, um zwei Schritte nach vorne" machen zu können.
Ein gutes Jahr später will ich den Thread nochmal ausgraben. Ich habe gerade ein wenig mit labwc - https://github.com/johanmalm/labwc - gespielt. Nicht dem letztem Release aus den FreeBSD Ports, denn das ist schon wieder einige Monate alt. Stattdessen mit einem gebautem
master von heute morgen. Inzwischen ist es anders als letzten Herbst eine durchaus benutzbare, praxistaugliche Alternative. Läuft schnell, soweit man das nach einem kurzen Ausflug sagen kann stabil und implementiert genügend Openbox-Funktionalität für die meisten Einsatzzwecke. Mir persönlich wären die strength Attribute noch wichtig, andere Nutzer haben sicher eigene Wünsche. Der derzeitige Stand findet sich unter https://github.com/johanmalm/labwc/wiki/Acceptance-criteria Zusammen mit zum Beispiel waybar und alacritty auf der Software- und Nvidias angedachtem GBM-Support auf der Treiberseite haben wir Fans von leichtgewichtigen Stacking Window Managern damit in absehbarer Zukunft hoffentlich eine robuste Grundlage, die auch auf (Free)BSD gut funktioniert.
bluescreen
verstört
Hallo !
Schoene Tools sind auch die "NWG" - Tools !
Wie z.B. die Menu-Bar !
Passt gut zu labwc
Gruss
Schoene Tools sind auch die "NWG" - Tools !
Wie z.B. die Menu-Bar !
Passt gut zu labwc
Gruss
dschmid
Metal Fan
@bluescreen vielen lieben dank für den hinweis
Es kommt drauf, wie viele der Openbox-Funktionen du brauchst. Wenn dir die Funktionen oder besser rc.xml-Optionen aus https://github.com/johanmalm/labwc/wiki/Acceptance-criteria reichen, könntest du gleich loslegen und würdest kaum einen Unterschied bemerken. Das Theme rendert minimal anders, aber herje.
ach ja, Nachtrag: Man braucht genauso wie für Sway und Cage einen Seat-Manager. Unter Linux macht das logind (schüttel), unter FreeBSD kann man
seatd nehmen. Muss nicht weiter konfiguriert werden, sondern nur laufen.