my way to WAYLAND and inside

Um hier mal etwas konstruktives beizutragen, ich hab auf meinen "ich probier mal mit FreeBSD rum" Notebook (Ein schon etwas historisches Thinkpad X230 mit i5-3230M, SSD und 8GB Ram) das ich bislang mit xorg und xfce installiert hab versucht mit Wayland und KDE zu nutzen. FreeBSD hatte ich gestern auf 14.3 hochgezogen. Bitte bedenken das ich weiterhin eher blutiger FreeBSD anfänger bin ;)

Installation:

pkg install kde plasma6-sddm-kcm sddm wayland seatd

Dann hab ich in der rc.conf den lightdm auskommentiert und dafür seatd und sddm ergänzt und neugestartet.

So wie es aussieht scheint das auf anhieb zu funktionieren, sddm hat mir automatisch plasma und wayland vorgeschlagen.
Unter Plasma musste ich noch kurz meine deutsche Tastatur hinterlegen, das kenn ich schon von KDE unter Linux.

Bislang scheint bei einem kurztest* alles zu funktionieren, lediglich scheinen bei manchen anwendungen nicht alle Symbole oben in der KDE-Fensterleiste zu sein (Villeicht fehlt dafür noch ein Paket?)

Aufwand: Villeicht 20 Minuten inkl. googeln für einen FreeBSD neuling (Aber nicht die Paket-Downloadzeit mit eingerechnet, das ding geht bei mir nie über 600Kbit/s, meist dümpelts zwischen 200 und 400 rum ... ja ich habe Gigabit Glasfaser die auch sonst funktionieren)

*(Da ich das Gerät nur sehr selten hochfahre wird es vermutlich auch dabei bleiben, es existiert nur um mal mit nem FreeBSD auf BareMetal rumzuspielen und kleinere erkentnisse zu erlangen)
also, wenn das nicht Mut macht....
Vielen Dank.
 
mein eigenes Vorankommen in labwc macht womöglich weniger Mut, was aber durchaus zu erwarten war.
Auf Details möchte ich nicht eingehen, dafür ist hier nicht der Platz, das gehört dann in einen eigenen labwc-Thread.

Weshalb dann der Beitrag?

ich möchte mal einen Time-Stamp setzen:
Code:
pit@Mifcom ~:- > date
Sa. 21 Juni 2025 17:45:21 CEST
Und ich bin seither mit Wayland ON.

Das Neue ist, dass ich es mal Versuchsweise ausschließlich mit labwc probieren will.
Die zuvor automatisch genutzte und parallel gestartete X-Session ignoriere ich hier nun vollkommen.
Ich erwarte nicht, dass dies problemlos laufen wird.
Deshalb berichte ich hier auch noch nicht von meinen Teilschritten.

Es ist derzeit auch ganz gut möglich, dass ich alles verwerfe und anders fortfahre.
Deshalb der Time-Stamp, zum Verfolgen.
 
Also ich hätte ein gesonderten Thread darüber sehr interessant gefunden für Einblicke betr.labwc. Aber ja, verstehe, du weisst ja noch nicht ob du verwerfen wirst. Wie ist das mit der Wayland Sache? Gibt es zur Zeit ein DM oder WM wo man sagen kann, das läuft schon rund?
Darf ich fragen, was genau daran schleppend ist, geht es um die Anwendung selbst die mal für das Xorg, X11 gemacht wurden und irgendwie noch nicht für Wayland funktionieren? Oder hat das etwas mit dem Kernel oder Betriebssystem zu tun?
 
Also ich hätte ein gesonderten Thread darüber sehr interessant gefunden für Einblicke betr.labwc. Aber ja, verstehe, du weisst ja noch nicht ob du verwerfen wirst. Wie ist das mit der Wayland Sache? Gibt es zur Zeit ein DM oder WM wo man sagen kann, das läuft schon rund?
Darf ich fragen, was genau daran schleppend ist, geht es um die Anwendung selbst die mal für das Xorg, X11 gemacht wurden und irgendwie noch nicht für Wayland funktionieren? Oder hat das etwas mit dem Kernel oder Betriebssystem zu tun?
Was genau schleppend meint, weiß ich nun nicht. Das Wort ist vermutlich in vorhergehenden Beiträgen mehrfach gefallen.
Alle Übergänge gehen fast immer irgendwie schleppend. Nur selten und meist aus der Not geboren, werden ad hoc irgendwelche Neuheiten unbedingt implementiert.
@Yamagi hatte zuvor mal etwas zu den Grundlagen erklärt und daraus kann man ablesen, dass Entwickler sich umstellen müssen, wenn sie Ihre Anwendungen für Wayland auslegen wollen. Sie können sich nicht mehr so halbwegs bequem zurück lehnen und erklären: X wird das schon machen. Heute müssen Sie selbst ihren Teil beitragen, wenn sie auf Wayland und einem passenden Compositor laufen wollen. Das kann vielleicht dann schon schleppend passieren, weil die Entwickler nicht recht wollen oder einfach auch überfordert sind.
Also, wenn das in etwa gemeint war, kann man das bei verschiedenen Anwendungen beobachten.

@bluescreen erklärt, er nutzt nur noch Wayland-Anwendungen, vermeidet also den Weg über das pseudo-X Xwayland und wenn das für ihn geht, sollte man daraus ableiten können, dass die Entwicklung nicht wirklich schleppend verläuft und man nur nach entsprechenden Komponenten suchen muss. Nun ist natürlich die Suche für einen selbst dann wieder schleppend. Ein Beispiel: ich benutze gern ein Panel, das zugleich Dock und Arbeitsflächenumschalter enthält. Davon gibt es viele. Dann möchte ich aber auch, dass es unten rechts platziert ist, Durchsichtigkeit, eine Uhr enthält und einige Dinge mehr. Es muss oder sollte zumindest umfänglich konfigurierbar sein. Das engt meine Suche dramatisch ein, aber im Voraus weiß ich nicht, was vielleicht am Besten für mich passt. Ich muss dann schon durch probieren.
Andererseits habe ich gelesen, dass ein xfce4-panel meine Wünsche zu rund zwei drittel erfüllt. Also installiere ich erst einmal dieses und schaue, wie weit ich damit komme. Das macht mich nicht 100% glücklich, ist aber benutzbar und vielleicht gewöhne ich mich auch daran?
Gewöhnung impliziert aber über die Zeit betrachtet.

Meine eigene Erfahrung bisher sagt nun wiederum genau das Gegenteil: ich finde viele Empfehlungen, die inzwischen schon veraltet sind, weil die Entwicklung schneller stattfindet, als diese Dokumente erneuert werden können.
Im Gegensatz zu @bluescreen will ich noch nicht vollständig von X lassen, weil ich dann viele Anwendungen ersetzen müsste und das bedeutet, viel neu lernen müsste. Das kommt womöglich erst mit der Zeit. Ein prominentes Beispiel ist XSANE. Ich habe nun nicht nachgelesen, aber der Name scheint mir schon zu sagen, dass das für X gemacht ist und ich starte bei mir Xwayland und XSANE funktioniert und dann brauche ich mich vorerst hier nicht an neue Programme zu gewöhnen. Ein anderes Beispiel ist der pcmanfm, mein üblicher Dateimanager. Hier finde ich leicht einen pcmanfm-qt, von dem es heißt, dass er direkt Wayland kann und den ich auf Anhieb genauso benutzen kann, wie meinen alten pcmanfm.
Was da nun vielleicht schleppend genannt werden kann? Wenn mit die zusätzliche Option Xwayland zu benutzen den vollen Umstieg zu Wayland-Tauglichen Programmen nicht sofort nötig macht, ist das irgendwie auch eine Verschleppung des vollständigen Wechsels.


Es gibt nun hier schon eine Reihe von Beiträgen und als ich den Thread startete, geschah das nicht zuletzt, weil ich Angst vor der Umstellung hatte. Gemäß der Devise: never touch a running system, schien es mir unnötig riskant, etwas Neues zu versuchen.
Nun haben wir ungefähr zwei Wochen später und ich arbeite im Wayland.
Den Mut dazu habe ich aus den vorhergehenden Beiträgen entwickelt, für die ich nochmal ausdrücklich danke.
Ob ich so weiter machen werde, weiß ich noch nicht. Immerhin scheint es mir so, dass ich labwc mit Xwayland tatsächlich schon jetzt gut benutzen kann, aber auch noch einige offene Punkte habe.
Ich glaube nicht, dass ein labwc wirklich gut geeignet für einen Neueinsteiger ist. Ich sehe es eher als Alternative für einen bisherigen openbox Nutzer und das betrifft mich halt. Für mich ist es deshalb so, dass dann, wenn labwc bei mir funktioniert, ich sogar eher Abstriche an Vollkommenheit mache und es trotzdem einsetzen würde.

Im Verlauf dieses Threads gab es mehrere Hinweise, allen voran von @CommanderZed hier https://www.bsdforen.de/threads/my-way-to-wayland-and-inside.37380/post-342815, den ich dir in einem anderen Thread schon mal zitiert hatte, dass KDE rundum glücklich und zufriedenstellend funktioniert und Einsteiger-Gerecht daher kommt.
 
Besten Dank für dein Feedback.
Ich hab das nur kurz vertestet, also ob das über Tage stabil ist weiß ich nicht. Ich nutze KDE/Wayland seit letztem Sommer aber als absolut Stabil unter Debian- und Archlinux.

Es spricht nichts dagegen es auch mal zu vertesten wenn du möchtest, der einfachste weg für einen anfänger - erstmal die Pakete installieren:

pkg install kde plasma6-sddm-kcm sddm wayland seatd

(Es kann sein das du das ein oder andere schon installiert hast)

Dann mit einem editor deiner Wahl /etc/rc.conf editieren und dafür sorgen das dein Login-Manager nicht mehr gestartet wird und mit sddm_enable="yes" sddm automatisch starten.

Dann sollte nach einem neustart dich sddm begrüßen wo unten links oder oben links meine ich "wayland plasma" bereits vorausgewählt sein sollte.

Wenn du zurück willst, änderst du einfach wieder die Einträge /etc/rc.conf.

Wenn du ein "raute / hashtag" - also das zeichen # vor einem einetrag in rc.conf machst, kannst du es auch auskommentieren, d.H. beim abarbeiten der rc.conf wird das dann übersprungen. So kannst du leicht deinen vorherigen login-manager auskommentieren oder zu sddm wechseln. einfach nur in dem du an einer stelle das # löscht oder hinzufügst. Wichtig: Es sollte am anfang der Zeile stehen.
 
pkg install kde plasma6-sddm-kcm sddm wayland seatd
Ich sehe hier und auch sonst im Internet häufig, dass das Paket wayland manuell installiert wird. Das sollte eigentlich nicht notwendig sein, da das nur eine Bibliothek mit dem Protokollparser ist und es automatisch als Abhängigkeit nachgezogen wird. Das sieht man auch gut auf https://www.freshports.org/graphics/wayland/ Alles, was irgendwie mit Wayland zu tun hat, hat eine Abhängigkeit drauf... :)
 
Aber pkg install wayland muss man schon installieren wie im Handbuch?
das erfolgt dann automatisch, man muss es also nicht eigens installieren, es schadet aber auch nicht, denn dann ist die Abhängigkeit halt schon vorhanden.
Sagen wir, wenn ich jetzt von cage die Nase voll hatte, nehme ich den nächsten Compositor und wenn ich nicht explizit alles im Zusammenhang mit cage deinstalliere, ist dann auch wayland schon da, wird gefunden und muss nicht wieder installiert werden.
 
Gerade bin ich mit wayfire ziemlich happy, mit labwc noch nicht so ganz. Und mit den Tastenkombinationen überhaupt nicht.
Arbeiten damit geht aber einwandfrei. Bis dato: Unter FreeBSD bleib ich dabei.
Und ganz nebenbei hab ich noch einen netten Markdown-Editor kennen gelernt, den Marker.
 

Anhänge

  • 20250623_12h11m05s_grim.webp
    20250623_12h11m05s_grim.webp
    78,2 KB · Aufrufe: 18
Das Neue ist, dass ich es mal Versuchsweise ausschließlich mit labwc probieren will.
mit labwc noch nicht so ganz. Und mit den Tastenkombinationen überhaupt nicht.
ganz bewusst habe ich m ich dazu entschieden, erst mal eine "Entwicklungs-Pause" zu machen. Statt also ständig neue Konfigs zu probieren und laufend neu zu starten, nutze ich nun mal, was ich habe und akzeptiere, dass ich Dinge noch nicht fertig habe.
Meine Tasten zum Platzieren der Fenster hatte ich zuvor schon wieder erarbeitet. Das Konzept ist anders, als bei openbox, ich finde es sogar besser mit labwc. Allerdings stört mich die Automagie, wenn ich ein Fenster zum Rand des Bildschirms bewege und es mir plötzlich aufgezogen und vergrößert wird. Naja, es stören noch einige andere Kleinigkeiten und ich will mal anfangen, eine todo-List zu erstellen.
Aber seit meinem Beitrag von oben arbeite ich mit dem labwc und meiner Vorab-Konfiguration beinahe wie gewohnt und ohne Unterbrechung.

Ich sag mal, dass ich meine Angst vor Wayland inzwischen vollkommen verloren habe und wenn es denn bei labwc längerfristig bleiben sollte, werde ich dazu einen eigenen Thread eröffnen, wo mir ja vielleicht noch geholfen wird, die letzten Macken zu entfernen.
 
ck-launch-session dbus-run-session wayfire/labwc /etc.
ich will meine nun laufende labwc-Instanz nicht für neue Experimente unterbrechen und frage daher mal nach:
ck-launsch-session funktionierte bei mir nicht von der Konsole.
Ich vermute mal, dass es ein Aufruf ist, den man aus einem Display-Manager setzen sollte (sddm oder so)?

setenv LIBSEAT_BACKEND consolekit2 setzen
labwc bietet eine ~/.config/labwc/environment in welcher man ja auch Dinge setzen kann und ich dachte mir, mach mal alles, was nun extra wegen labwc kommt, lieber dort und nicht in die .cshrc. Dabei habe ich nun schon einige Male Schiffbruch erlitten, wenn ich Empfehlungen aus dem Netz folgen wollte. Der Start von labwc wurde mir einfach mit Fehlern verweigert.
Das durchblicke ich noch nicht.
Wo ist der Unterschied, was sollte ich lieber wo machen (ich rede jetzt gezielt von labwc, weil andere so ein environment-File ja wohl gar nicht haben).

dbus-run-session
auch hier die Frage. Man will dbus, aber wo aktiviert man ihn?
Bei dem Aufruf in der Kommandozeile habe ich als User labwc "damit" gestartet.
labwc hat auch ein ~/.config/labwc/autostart wo so etwas rein kommen könnte und dann hatten wir früher den dbus in der /etc/rc.conf gestartet.
 
Auch mal einen screenshot:
2025-06-23_15-06-1750686590-grim.webp
wie immer finde ich screenshots eher nicht so aussagekräftig. Da wird ein Bild gezeigt von einem virtuellen Desktop.... und mit viele Mühe zeigt sich auch noch der Hintergrund ein ganz klein wenig...

Viel wichtiger finde ich, dass man ein Augenmerk darauf hat, dass man nahezu direkt unterscheiden kann, welche Anwendungen in Wayland nativ laufen und welche in Xwayland.
Mein privates Thema heißt pit, ist für openbox gemacht und versagt da schon bei moderneren Qt und Gtk Versionen. Also kaum zu glauben, dass es überhaupt unter labwc unverändert recht gut verdaut wird.
Es wird eigentlich bisher nur dort verwendet, wo Programme unter Xwayland laufen.
Unter X habe ich ich auch meinen Mauszeiger manipuliert und er erscheint da größer, als unter Wayland. Das sieht man Mitte-Links im Bild, wo der Zeiger über einer kleinen X-App steht, die über Xwayland dargestellt wird.
Sobald ich die Maus über ein "Wayland-Fenster" bewege, wird sie klein und wieder groß, wenn ich auf ein X-Wayland Fenster wechsele.

Weil alles bei mir bisher klaglos funktioniert, was ich "direkt Xwayland übergebe", also einfach mal machen lasse, tendiere ich derzeit sogar dazu, vermehrt darauf zu setzen und nicht unbedingt nach Wayland kompatiblem Ersatz für alte Anwendungen zu suchen.
Xwayland geht bei mir bisher voll gut und muss nicht vermieden werden.
 
Wie sieht es denn mit render offloading auf NVIDIA GPUs aus? Ich habe die verkorkste Situation, dass der interne Schirm an der iGPU hängt und die externen Anschlüsse direkt am der NVIDIA GPU.
 
Wie sieht es denn mit render offloading auf NVIDIA GPUs aus?
Ich weiß nicht, was das bedeutet. Weil aber sonst keine Antwort bisher gekommen ist, mal die Auskunft, die ich beisteuern kann:
Meine nvidia und der zugehörige drm laufen.
Ab und zu flackern Seiten für einen kurzen Moment.
Bei einheitlichen Farben (etwa in einem terminal-Programm), habe ich den Eindruck, dass es einen Farbverlauf bei helleren Farben gibt von oben hell nach unten geringfügig dunkler. Das ist auf beiden Monitoren so, was aber nicht bedeutet, dass dis nicht trotzdem von den Monitoren kommen kann und mir bisher nicht aufgefallen ist. Die Monitore haben schon einige Stunden auf dem Buckel und ich versuche immer, die Helligkeit niedrig zu halten. Da kann es schon Schwächen hinsichtlich gleichmäßiger Ausleuchtung geben.
Filme werden sehr gut dargestellt und ich muss mir sehr viel Mühe geben, überhaupt mal irgendeinen Mangel zu sehen. Desto besser das Ausgangsmaterial, desto besser die Darstellung.
Zum Testen der HW-Beschleunigung wurde irgendwo mal ein Spiel Namens Xonotic empfohlen und die Aussage war, dass hier Bilder/sec dargestellt werden können, als mit dem begrenzten glxgears. Unter X zeigte Xonotic bei mir über 250 B/sec, unter Wayland bei besserem Eindruck nur einige wenige, nicht mal 10 B/sec. Mir sagt das nicht viel. Ebensowenig sagt mir die folgende Liste, die ich mal aus dem nvidia-Settings GUI genommen habe:
Code:
EGL_ANDROID_native_fence_sync
EGL_EXT_buffer_age
EGL_EXT_client_sync
EGL_EXT_create_context_robustness
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers
EGL_MESA_image_dma_buf_export
EGL_EXT_output_base
EGL_EXT_output_drm
EGL_EXT_protected_content
EGL_EXT_stream_consumer_egloutput
EGL_EXT_stream_acquire_mode
EGL_EXT_sync_reuse
EGL_IMG_context_priority
EGL_KHR_config_attribs
EGL_KHR_create_context_no_error
EGL_KHR_context_flush_control
EGL_KHR_create_context
EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses
EGL_KHR_partial_update
EGL_KHR_swap_buffers_with_damage
EGL_KHR_no_config_context
EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image
EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image
EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image
EGL_KHR_image_base
EGL_KHR_reusable_sync
EGL_KHR_stream
EGL_KHR_stream_attrib
EGL_KHR_stream_consumer_gltexture
EGL_KHR_stream_cross_process_fd
EGL_KHR_stream_fifo
EGL_KHR_stream_producer_eglsurface
EGL_KHR_surfaceless_context
EGL_KHR_wait_sync
EGL_NV_quadruple_buffer
EGL_NV_stream_consumer_eglimage
EGL_NV_stream_cross_display
EGL_NV_stream_cross_object
EGL_NV_stream_cross_process
EGL_NV_stream_cross_system
EGL_NV_stream_flush
EGL_NV_stream_metadata
EGL_NV_stream_remote
EGL_NV_stream_reset
EGL_NV_stream_socket
EGL_NV_stream_socket_inet
EGL_NV_stream_socket_unix
EGL_NV_stream_sync
EGL_NV_stream_fifo_next
EGL_NV_stream_fifo_synchronous
EGL_NV_stream_consumer_gltexture_yuv
EGL_NV_stream_attrib
EGL_NV_stream_origin
EGL_NV_system_time
EGL_NV_output_drm_flip_event
EGL_NV_triple_buffer
EGL_NV_robustness_video_memory_purge
EGL_WL_bind_wayland_display
EGL_WL_wayland_eglstream
EGL_EXT_present_opaque
 
Wie sieht es denn mit render offloading auf NVIDIA GPUs aus? Ich habe die verkorkste Situation, dass der interne Schirm an der iGPU hängt und die externen Anschlüsse direkt am der NVIDIA GPU.
Das Offloading an sich funktioniert zumindest mit Plasma 6 einwandfrei, aber ich kann nur den "normalen" Weg testen. Sprich rendern auf der dGPU, ausgeben über die iGPU. Den umgekehrten und für dich interessanten Weg mangels Hardware nicht.
 
Zurück
Oben