my way to WAYLAND and inside

Moin !

Kleiner Tipp zu labwc ! Falls man haupsächlich nur
GTK3/4 - Anwendungen nutzt , ist es eine Angenehme
Sache " CSD " zu aktivieren !

In der rc.xml ganz oben , von server auf client setzen !

<core>
<gap>1</gap>
<decoration>client</decoration>
<windowSwitcher show="yes" preview="yes" outlines="no" />
</core>


Zitat : ... und was sollen bitte schön drehende Würfel und explodierende Fenster auf meinem Desktop ?

Kann man einfach durch entfernen eines Häkchens abschalten !

Lol

:rolleyes:


pkg install wcm

2025-06-14_16:29:50.webp
 
Ich möchte mal einen aktuellen Stand (... vermutlich für die meisten ein Schmunzler) nennen: Ich habe verstanden, dass ich nvdidia-drm benötige, damit wayland funktioniert. Und da bin ich "gerade" dran. Vielleicht ist auch meine Grafikkarte zu alt (gtx 1050 ti). :huth:
 
@Columbo0815
Moin !
Laut diesem thread sollte Wayland (sway & labwc) hiermit laufen !
Need : graphics/nvidia-drm-61-kmod

/boot/loader.conf : hw.nvidiadrm.modeset=1

/etc/rc.conf : kld_list="nvidia-modeset nvidia-drm linux linux64"

Gruss
 
Hallo!

Hattest du ein update gehabt?

Ich würde mal den Treiber aus den ports,
mit den richtigen sourcen neu bauen!

Gruss
 
Columbo0815 schrieb:
Genau nach diesem Thread war ich vorgegangen
Zum Vergrößern anklicken....
in dem wird aber ein wenig hin und her geschwommen und so genau sehe ich nicht, an welcher Stelle dort überhaupt jemand hängt.
Allerdings wunderte ich mich heute früh auch, dass ich eigentlich gar kein nvidia-drm.kmod laufen habe und zeige mal anschließend, was ich da gemacht habe. Wahrscheinlich versteht man das eh besser, als wenn ich versuche, es zu beschreiben:
Code: 
pit@Mifcom ~:- > labwc
[1] 2879
pit@Mifcom ~:- > 00:00:10.641 [backend/backend.c:253] Found 0 GPUs, cannot create backend
                                                                                         00:00:10.641 [backend/backend.c:428] Failed to open any DRM device
                                                                                                                                                           00:00:10.642 [.
./src/server.c:466] unable to create backend

Some friendly trouble-shooting help
===================================

If a seat could not be created, this may be caused by lack of permission to the
seat, input and video groups. If you are using a systemd setup, try installing
polkit (sometimes called policykit-1). For other setups, search your OS/Distro's
documentation on how to use seatd, elogind or similar. This is likely to involve
manually adding users to groups.

If the above does not work, try running with `WLR_RENDERER=pixman labwc` in
order to use the software rendering fallback

pit@Mifcom ~:- > dmesg | grep nvidia
nvidia0: <NVIDIA GeForce RTX 3060> on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  570.153.02  Tue May 13 16:02:47 UTC 2025
linker_load_file: /boot/modules/nvidia-drm.ko - unsupported file type

pit@Mifcom ~:- > pkg which /boot/modules/nvidia-drm.ko
/boot/modules/nvidia-drm.ko was installed by package nvidia-drm-61-kmod-570.153.02.1402000_1

pit@Mifcom ~:- > pkg info -D nvidia-drm-61-kmod
nvidia-drm-61-kmod-570.153.02.1402000_1:
On install:
Modesetting must be enabled to use nvidia-drm.ko for graphics. This can be done
by setting the modeset sysctl, the equivalent of the modeset kernel parameter
on Linux.

hw.nvidiadrm.modeset=1

This must be set before loading nvidia-drm.ko, most easily done by placing the
above in /boot/loader.conf

pit@Mifcom ~:- > grep nvidiadrm /boot/loader.conf
hw.nvidiadrm.modeset=1

pit@Mifcom /home/pit:-# kldload -v /boot/modules/nvidia-drm.ko
kldload: an error occurred while loading module /boot/modules/nvidia-drm.ko. Please check dmesg(8) for more details.

nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  570.153.02  Tue May 13 16:02:47 UTC 2025
linker_load_file: /boot/modules/nvidia-drm.ko - unsupported file type
linker_load_file: /boot/modules/nvidia-drm.ko - unsupported file type


pit@Mifcom /usr/ports/graphics/nvidia-drm-61-kmod:-# kldload -v /boot/modules/nvidia-drm.ko
Loaded /boot/modules/nvidia-drm.ko, id=48
pit@Mifcom /usr/ports/graphics/nvidia-drm-61-kmod:-# kldstat -v | grep nvidia
                 82 pci/ata_nvidia
                363 g_raid_md_nvidia
14    2 0xffffffff8338d000   1507d8 nvidia-modeset.ko (/boot/modules/nvidia-modeset.ko)
                516 nvidia-modeset
15    2 0xffffffff83600000  531fde8 nvidia.ko (/boot/modules/nvidia.ko)
                515 vgapci/nvidia
48    1 0xffffffff835a4000    139c0 nvidia-drm.ko (/boot/modules/nvidia-drm.ko)
                561 nvidia_drm
Kurz erklärt: labwc startete nicht und brachte Fehler, dass gar kein DRM läuft. Die Suche zeigte tatsächlich einen Fehler beim Laden des nvidia-drm. Das war heute früh und nun machte ich da weiter.
Genauer hingeschaut sah ich, dass die Versionen von nvidia-Treiber und nvidia-drm zusammen passten.
Ein pkg delete und wieder pkg install änderte nichts, gleicher Fehler. Ein pkg upgrade -r FreeBSD-kmods änderte nichts, alles bereits aktuell.
Der Hinweis, dass nvidia-drm die hw.nvidiadrm.modeset=1 gesetzt haben muss, wurde überprüft und korrigiert.
Laut dem oben verlinkten Beitrag ist das bei X unnötig, aber wichtig für Wayland. Ich hatte die Variable bei mir mal auskommentiert und das nun wieder rückgängig gemacht.
Sodann /usr/src und /usr/ports aktualisiert und in den Ports zum nvidia-drm-61 gewechselt, von Hand gebaut, reinstalliert, Modul erfolgreich gestartet, labwc aufgerufen und PC-Kollaps gehabt. Gleichzeitig lief aber auch ein X, stört so etwas? Es gab also einen massiven Fehler, der zum Neustart des PCs führte.
Nächster Versuch, seatd gestartet, labwc trotz laufenden XDM (also aktivem X) gestartet und Erfolg gehabt.
Weiter habe ich nicht gemacht, sollte nur mal ein Test sein.

Also, mit aktuellem nvidia-Treiber aus den Paketen und aktuellem nvidia-drm aus den Ports und den entsprechenden Voraussetzungen, scheint es doch grundsätzlich zu gehen, zumindest mal auf meiner HW.

Nachtrag:
Code: 
pit@Mifcom ~:- > freebsd-version -ukr
14.3-RELEASE
14.3-RELEASE
14.3-RELEASE
Alle Pakete nach Wechsel von 14.2 reinstalliert und auch die kmods (siehe oben) upgedatet.
 
Ich bin grad so was von ...

Vorhin hatte ich ja den nvidia-drm starten können und dann auch einen labwc, gleichzeitig zu laufendem X.

Ich will nicht meinen nvidia-PC nun schon auf Wayland haben, dazu muss ich noch viel zu viel lernen und testen.
Kennt ihr das Märchen von der Prinzessin auf der Erbse?
Ich glaube, mich drückt gerade die Wayland-Erbse ein wenig.
Also, parallel zu meiner laufenden X-Session lasse ich auf einer Konsole den labwc laufen, starte darin den Film, den ich nun sehen möchte und dann auch einen Browser und schreibe nun daraus.
Was soll ich sagen:
Ohne alle Einstellungen und nahezu ohne passende Konfiguration, mit viel Arbeit übrig und weit entfernt von einem Desktop-Erlebnis und außerdem auch noch mit Englischer Tastatur -
das Bild ist so viel besser, der Film sieht so viel besser aus...

Wenn die Voraussetzungen passen, ist es offenbar nicht so schwer, einfach mal einen kleinen Ausflug nach Wayland zu wagen. Ich bin davon total angetan und nicht nur auf dem kleinen und vernachlässigten Laptop, mit dem ich ja derzeit spiele und lerne.

Allerdings gelingt das Hin- und Herschalten zwischen den Welten nicht ganz so klaglos. Wayland, besser labwc crashte mir weg, weil Probleme mit Variablen, die in X offenbar anders besetzt sind oder so. Ich verstehe ja nur einen sehr kleinen Teil der Fehlermeldungen.
Es wäre aber vielleicht möglich, solche Probleme recht einfach zu lösen und etwa eine kleine Wayland-Lösung nur für bestimmte Anwendungen parallel zu X zu gehen, nur, um in den Genuss von Wayland zu kommen, ohne X und die gewohnte Umgebung gleich komplett aufgeben zu müssen.
 
Andy_m4 schrieb:
Sag doch mal, wie Dein Startaufruf war.
Zum Vergrößern anklicken....
labwc

ohne jede Schnörkel.

Genauer:
die zeitliche Abfolge hatte ich oben bereits beschrieben. Mein System war gebootet und hatte den XDM auf ttyv4 gestartet. Auf Grund der Nachfrage in diesem Thread, fand ich keinen laufenden nvidia-drm, was dann aber gelöst werden konnte, nachdem dieser aus den Ports neu gebaut worden war. Das fand auf ttyv1 bis ttyv3 statt, wobei der XDM aktiv blieb. Auf ttyv1 starte ich labwc, was zu einem Crash mit reboot führte.
Weil ich nichts daran verändert hatte, bootete das System wieder in den XDM auf ttyv4. Das Nachsehen auf ttyv0 und diverse grep als user auf ttyv1 bestätigten aber den geladenen nvidia-drm.
Also Test: XDM auf ttyv4 aktiv gelassen, auf ttyv1 als root den seatd gestartet, als User den labwc, wie oben beschrieben, einfach nur diesen Aufruf gemacht. Aus dem labwc-default-menu den labwc wieder beendet.
Auf ttyv4 mit dem laufenden XDM geschaltet und diesen erst mal neu gestartet (meine xorg.conf hat eine Tastenkombination genau dafür, den X zu beenden, der sich dann selbst wieder startet). Nun eingeloggt und meine X-Session wie üblich gestartet.
Gearbeitet, gelesen, keinen Bock mehr: Film ansehen. Tearing Probleme gesehen, desto grösser das Bild, desto schlimmer. Also nicht so sehr schlimm.
Zuvor hatte ich die xorg.conf entsprechend verschlankt (mache ich fast immer bei einem Update und schaue erst mal, wie es so aussieht), also alle vielleicht positiven Einstellungen erst mal aus kommentiert.
mmhm...
da war doch was?
Verzeichnis .config/labwc erstellt und meine Openbox rc.xml und menu.xml hierhin kopiert. Die taugen nicht für labwc!!! Aber wichtige Dinge funktionieren trotzdem: ich kann mittels Tastatur-Kombinationen wie gewohnt Anwendungen starten, etwa einen pcmanfm oder ein urxvt-Terminal.
Auf ttyv1 eingeloggt, root startet seatd, user startet labwc: geht. pcmanfm öffnet mit Tastenbefehl, ich kann einen Film ansehen, viel schöner, als unter X.
Zurück auf ttyv4, also X und Dinge gemacht, wie üblich.
Wieder zurück nach ttyv1 und labwc spinnt hier rum. Fehlermeldungen wegen nicht passender Variablen und Endlos-Schleife mit Fehlern, aber auch mit Sound zum zuvor angehaltenen Film. Von ttyv2 dann labwc gekillt, zurück auf X um dort weiter zu machen.
mmhemm..
Das ttyv1 ist irgendwie beschädigt worden, nimmt keine Tastatur mehr an.
Auf ttyv2 als User den labwc gestartet und seitdem laufen lassen, aber seither auch nicht zu X zurückgeschaltet. Ich bin da nämlich mitten in einer Serie und will die hier erst zu Ende schauen.

Sehr wenig professionell, gell.
Anbei mal die laufenden Dingers:
Code: 
pit@Mifcom ~:- > pstree
-+= 00001 root /sbin/init
 |--= 00914 root adjkerntz -i
 |--= 02439 root /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid
 |--= 02599 root /sbin/devd
 |--= 02835 root /usr/sbin/rpcbind
 |--= 02845 root /usr/local/sbin/apcupsd --kill-on-powerfail
 |--= 02849 root /usr/sbin/rpc.statd
 |--= 02856 root /usr/sbin/rpc.lockd
 |--= 02894 ntpd /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift
 |--= 02936 root /usr/local/sbin/cupsd -C /usr/local/etc/cups/cupsd.conf -s /usr/local/etc/cups/cups-files.conf
 |--= 02959 root sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd)
 |--= 02969 root /usr/sbin/cron -s
 |--= 02972 root /usr/local/libexec/dsbmd
 |-+- 03032 root /usr/local/bin/xdm -nodaemon ttyv4
 | |--= 03034 root /usr/local/libexec/Xorg :0 -auth /var/db/xdm/authdir/authfiles/A:0-7bm23B
 | \-+= 03037 root xdm: :0 (xdm)
 |   \-+= 03070 pit /usr/local/bin/openbox --startup /usr/local/libexec/openbox-autostart OPENBOX
 |     |-+- 03074 pit /bin/sh /usr/local/libexec/openbox-autostart OPENBOX
 |     | \-+- 03079 pit sh /home/pit/.config/openbox/autostart.sh
 |     |   |-+- 03085 pit /usr/local/bin/xscreensaver -no-splash
 |     |   | \--= 05563 pit xscreensaver-gfx --init
 |     |   |--- 03086 pit /usr/local/bin/tclock -border red -bg green -scale 0.5 -borderWidth 2
 |     |   |-+- 03089 pit pcmanfm -n /usr/home/pit
 |     |   | \--- 04098 pit mpv --player-operation-mode=pseudo-gui -- file:///mnt/files/raid1/Exports/E-Filme/Fernseh-Serien/UNGESEHEN/HarryWild/19_240825_2215_sendung_hwi_a
 |     |   |--- 03091 pit pcmanfm -n /usr/home/pit/.config/autostart
 |     |   |--- 03155 pit /usr/local/bin/gkrellm
 |     |   \--- 03159 pit /usr/local/bin/fbpanel
 |     |-+- 03546 pit /usr/local/bin/urxvt -fg Yellow -bg Magenta -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 |     | |--- 03547 root /usr/local/bin/urxvt -fg Yellow -bg Magenta -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 |     | \--= 03548 pit tcsh
 |     \-+- 03974 pit /usr/local/bin/urxvt -fg Yellow -bg Magenta -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 |       |--- 03975 root /usr/local/bin/urxvt -fg Yellow -bg Magenta -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 |       \-+= 03976 pit tcsh
 |         \--= 03978 pit top
 |-+= 03057 root daemon: /usr/local/bin/seatd[3058] (daemon)
 | \--- 03058 root /usr/local/bin/seatd -g video
 |--= 03115 pit /usr/local/bin/picom -b --config /usr/home/pit/.config/openbox/picom/picom.conf
 |--- 03158 pit /usr/local/bin/claws-mail
 |--- 03227 pit thunderbird
 |--- 03235 pit dbus-launch --autolaunch=a2ea38348a62e6c3d61500199982dbfa --binary-syntax --close-stderr
 |--= 03236 pit /usr/local/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
 |-+- 03241 pit /usr/local/libexec/at-spi-bus-launcher
 | \--- 03271 pit /usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/var/run/xdg/
 |--- 03250 pit /usr/local/libexec/gconfd-2
 |--- 03251 pit dsbmc -i
 |--- 03257 pit dsbmixer -i
 |-+- 03265 pit geany
 | \--= 03275 pit /bin/tcsh
 |--- 03274 pit /usr/local/libexec/at-spi2-registryd --use-gnome-session
 |--- 03280 pit orage
 |-+- 03288 pit firefox %U firefox -new-window firefox -private-window
 | |--- 03297 pit /usr/local/lib/firefox/firefox -contentproc -appDir /usr/local/lib/firefox/browser 1 socket
 | |--- 03299 pit /usr/local/lib/firefox/firefox -contentproc -appDir /usr/local/lib/firefox/browser 3 rdd
 | |--- 03300 pit /usr/local/lib/firefox/firefox -contentproc 4 tab
 | |--- 03303 pit /usr/local/lib/firefox/firefox -contentproc 7 tab
 | |--- 03304 pit /usr/local/lib/firefox/firefox -contentproc -appDir /usr/local/lib/firefox/browser 8 utility
 | |--- 03306 pit /usr/local/lib/firefox/firefox -contentproc 10 tab
 | |--- 03307 pit /usr/local/lib/firefox/firefox -contentproc 11 tab
 | |--- 03316 pit /usr/local/lib/firefox/firefox -contentproc 12 tab
 | |--- 03317 pit /usr/local/lib/firefox/firefox -contentproc 13 tab
 | |--- 03318 pit /usr/local/lib/firefox/firefox -contentproc 14 tab
 | |--- 03330 pit /usr/local/lib/firefox/firefox -contentproc 16 tab
 | |--- 03477 pit /usr/local/lib/firefox/firefox -contentproc 26 tab
 | |--- 03820 pit /usr/local/lib/firefox/firefox -contentproc 29 tab
 | |--- 15720 pit /usr/local/lib/firefox/firefox -contentproc 73 tab
 | |--- 16012 pit /usr/local/lib/firefox/firefox -contentproc 74 tab
 | \--- 16257 pit /usr/local/lib/firefox/firefox -contentproc 75 tab
 |--- 03340 pit /usr/local/bin/pulseaudio --start --log-target=syslog
 |--- 04187 pit /usr/local/bin/pcmanfm
 |-+- 04201 pit /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | |--- 04202 root /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | \-+= 04203 pit tcsh
 |   \--= 04401 pit top
 |--= 04349 pit /usr/local/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
 |-+- 04352 pit /usr/local/libexec/at-spi-bus-launcher
 | \--- 04353 pit /usr/local/bin/dbus-daemon --config-file=/usr/local/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/var/run/xdg/
 |--- 04357 pit /usr/local/libexec/at-spi2-registryd --use-gnome-session
 |-+- 04384 pit /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | |--- 04385 root /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | \-+= 04386 pit tcsh
 |   \-+= 16387 pit pstree
 |     \--- 16388 pit ps -axwwo user,pid,ppid,pgid,command
 |-+- 04476 pit /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | |--- 04477 root /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | \-+= 04478 pit tcsh
 |   |-+= 04517 pit chrome:  (chrome)
 |   | |--- 04520 pit chrome: --type=utility --utility-sub-type=network.mojom.NetworkService --lang=de --service-sandbox-type=network --enable-crash-reporter=, --shared-file
 |   | |--- 04521 pit chrome: --type=utility --utility-sub-type=storage.mojom.StorageService --lang=de --service-sandbox-type=utility --enable-crash-reporter=, --shared-file
 |   | |--- 04524 pit chrome: --type=renderer --enable-crash-reporter=, --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=7 --time-
 |   | |--- 04559 pit chrome: --type=gpu-process --enable-crash-reporter=, --gpu-preferences=UAAAAAAAAAAgAAAEAAAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 |   | |--- 04560 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 04561 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 04562 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 13850 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 13851 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 13852 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 13853 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | |--- 15570 pit chrome: --type=renderer --enable-crash-reporter=, --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-before-activation --re
 |   | \--- 16384 pit chrome: --type=renderer --enable-crash-reporter=, --extension-process --disable-gpu-compositing --lang=de --num-raster-threads=4 --enable-main-frame-be
 |   \-+= 05308 root su
 |     \--= 05311 root _su (csh)
 |-+- 04696 pit /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | |--- 04697 root /usr/local/bin/urxvt -fg Yellow -bg Black -fade 30 -sh 45 -tr +vb -sb -sr -st -fn xft:Courier New:pixelsize=20
 | \-+= 04698 pit tcsh
 |   \--= 05323 pit xeyes
 |--= 03013 root /usr/libexec/getty Pc ttyv0
 |--= 04108 root /usr/libexec/getty Pc ttyv1
 |-+= 03015 root login [pam] (login)
 | \-+= 04043 pit -tcsh (tcsh)
 |   \--= 04183 pit labwc
 |--- 04189 pit Xwayland :1 -rootless -core -terminate 10 -listenfd 48 -listenfd 49 -displayfd 78 -wm 75
 |-+= 03016 root login [pam] (login)
 | \--= 04141 pit -tcsh (tcsh)
 \--- 04348 pit dbus-launch --autolaunch=a2ea38348a62e6c3d61500199982dbfa --binary-syntax --close-stderr
 
bluescreen schrieb:
Hallo!

Hattest du ein update gehabt?

Ich würde mal den Treiber aus den ports,
mit den richtigen sourcen neu bauen!

Gruss
Zum Vergrößern anklicken....
Ich glaube das geht in die richtige Richtung. In den quarterly Packages (die ich seit 14.3 ungewollt nutzte) waren nur drm- und nvidia-Packages für 14.2. Jetzt bin ich umgestiegen auf die Latest Packages. Dort gibt es drm-Pakete für 14.3, aber aktuell keine nvidia-Treiber (also gar keine). Da ich auf dem Host keine Ports nutzen möchte (ja, ich bin und bleibe hier Monk!), warte ich einfach noch ein wenig. :)
 
Moin, hatte bisher keine Probleme mit x.org und eigtl. grad keinen Böck das umzustellen.

Aber mal eine generelle Frage, nutze schon ewig "WindowMaker" als Window Manager,
den gibt es ja nicht als wayland Native soweit ich das sehe.

Läuft das denn dann automatisch trotzdem? Oder muss der Window Manager zwingend
Wayland unterstützen?

Wayland Programme linken standardmäßig dann einfach gegen Wayland Libs oder
sind da nach wie vor noch irgendwelche xlibs mit dabei?

H
 
hugly schrieb:
Läuft das denn dann automatisch trotzdem? Oder muss der Window Manager zwingend
Wayland unterstützen?
Zum Vergrößern anklicken....
derzeit keine eindeutige Antwort von meiner Seite aus.

Wie ich es verstehe, unterstützt Wayland Wayland-Gedöns.
Um Grafik auf den Bildschirm zu bringen, braucht es einen (Wayland) Compositor.
In solch einem Compositor kann Xwayland laufen.
Xwayland ist Wayland-Gedöns, das einen einfachen X-Server innerhalb des Compositors realisiert. Anwendungen, die nicht Wayland können und X brauchen, werden dann zu Xwayland geführt und innerhalb des Compositors so ungefähr wie innerhalb X dargestellt.

Damit kommt man unweigerlich auf die Idee (weiter oben kann man lesen, dass es nicht meine eigene Idee gewesen ist), einen einfachen Compositor zu benutzen, um darin Xwayland einen X-Server vortäuschen zu lassen und ansonsten alles beim Alten zu belassen. Also in meinem Fall wollte ich einfach die Openbox-Session aufrufen, bei dir dann den Windowmaker.
Mir ist dieses nicht gelungen, aber ich kenne mich auch sehr wenig aus.
Grundsätzlich könnte das aber tatsächlich funktionieren. Ich glaube, @Andy_m4 will so etwas demnächst auch mal probieren.

hugly schrieb:
nutze schon ewig "WindowMaker" als Window Manager
Zum Vergrößern anklicken....
wie ich eben Openbox und ich sehe die Zeichen der Zeit und werde mich umstellen müssen. Die vergangene Ewigkeit geht langsam zu Ende und es wird einfach Zeit, eine neue zu beginnen. Bei mir geht so etwas naturgemäß eher zäh, denn ich bin ja derzeit sehr zufrieden und habe keinen Leidensdruck, der mich zwing, etwas neues zu lernen.
Gerade deshalb fange ich aber nun bereits damit an. Dann gehen die Dinge irgendwie spielerisch und fließend und ohne Zwang.

https://wiki.archlinux.org/title/Wayland
ist ein guter Ansatz und ich weiß zwar nicht viel über Windowmaker, aber vielleicht spricht da etwas dich an, das du dann mal probieren möchtest und uns allen berichten kannst.
 
Nach lesen dieser Threads glaube ich, dass es Missverständnisse gibt, was Wayland eigentlich ist und wie es sich von X11 unterscheidet. Daher versuche ich es mal:

Generell sind sowohl X11, als auch Wayland Display-Protokolle. Sie erlauben es Anwendungen Daten mit einem Display-Server auszutauschen. Der Displayserver rendert das, was die Anwendung über das Protokoll kommuniziert, auf den Bildschirm und stellt umgekehrt den Anwendungen Dinge wie durch den Nutzer gemachte Eingaben zur Verfügung. Weil es nur Protokolle sind, die öffentlich dokumentiert sind, kann sie in der Theorie jeder implementieren.

Das Problem von X11 ist, dass das Protokoll steinalt ist. Die erste Version X1 ist von 1984 und die heute genutzte Version X11 von 1987. Sprich aus der Frühzeit der graphischen User Interfaces. Das führt im Wesentlichen zu drei Problemen:

1. X11 denkt in sogenannten Render Primitives. Das bedeutet, dass die Anwendung sozusagen ein Rezept gibt, was gerendert werden soll. Bildlich gesprochen "rendere ein Rechteck mit Attributen A,B,C an Position X,Y". Das war Ende der 80er recht clever, weil über das Protokoll nur wenige Daten ausgetauscht werden müssen und man die komplexe Renderlogik nur einmal im Display-Server implementieren muss. Der Nachteil ist aber, dass Anwendungen alles in diese Renderer Primitives runterbrechen müssen. Außerdem kann Hardwarebeschleunigung nur schlecht integriert werden. Daher ging die Welt in den frühen 2000er Jahren dazu über, statt Render Primitives die jeweilige Anwendung per Hardwarebeschleunigung ihren Anteil des Bild selbst fertig rendern zu lassen und diese fertig gerenderten Teile im Display-Server nur noch zusammenzufügen. Vorreiter war Apple mit Quartz Extreme, Microsoft kam etwas später mit Aero aka Windows Presentation Foundation hinterher. X11-Anwendungen gingen ebenfalls dazu über, indem sie ein einziges Rechteck über das Fenster legen, also nur ein einziges Renderer Primitive nutzen und da eine selbst gerenderte Bitmap mit der eigentlichen Ausgabe reinkleben.
2. X11 unterstützt viele längst selbstverständlich gewordene Dinge nicht. Ein prominentes Beispiel sind mehrere Monitore. Um diese Dinge dennoch nutzen zu können, braucht es sogenannter Protokollerweiterungen. Das sind eigene Display-Protokolle, die das eigentliche X11-Protokoll ergänzen. Über die Jahrzehnte haben sich eine Myriade dieser Protokolle angesammelt, teils in stark schwankender Qualität. Weil man alte Anwendungen, die eventuell alte Protokollerweiterungen benötigen, weiter unterstützen will, muss man all diese Erweiterungen unterstützen.
3. X11 kommt aus einer Zeit, in der Sicherheit keine Rolle spielte, da es noch keine Sicherheitsprobleme gab. X11 hat einen globalen Message Bus. Jede Anwendung kann das ganze Display-Protokoll mitlesen. Das macht es extrem einfach z.B. Keylogger zu schreiben oder gleich den ganzen Desktop als Videostream auszuleiten

X11 hat drei beteiligte Komponenten:

1. Kern des Ganzen ist der XServer, der Display-Server. Inzwischen gibt es nur noch eine nennenswerte Implementierung, das ist der xorg-server.
2. Der XServer implementiert keine Fensterverwaltung. Um mehrere Fenster haben zu und diese Fenster (also verschieben, ihre Größe ändern, etc.) manipulieren zu können, braucht es einen Window Manager. Über die Jahrzehnte sind hunderte Window Manager geschrieben worden.
3. Mindestens eine Anwendung.

Nun geht der xorg-server auf X1 von 1984 zurück. Und muss, damit auch die X11-Anwendung von 1987 noch funktioniert, das komplette X11-Protokoll mit allen seitdem entwickelten Protokollerweiterungen unterstützen. Der xorg-server ist daher ein historisch gewachsener Moloch, den auch sehr masochistische Entwickler nicht mal mehr mit der Kneifzange anfassen möchten. Daher sind viele xorg-Entwickler auch gleichzeitig Wayland-Entwickler. Sie treiben Wayland voran, um xorg loszuwerden. Das hat in den letzten Jahren dazu geführt, dass xorg kaum noch weiterentwickelt wird. Es ist in einer Maintainance Mode, wo es allenfalls noch kleinere Bugfixes gibt.

Wayland ist ein neuer Ansatz, der sich viel näher an MacOS und Windows als am alten X11 orientiert. Wayland fasst konzeptionell den Display-Server und den Windows Manager zu einem Compositor (von 'to composite', auf Deutsch 'zusammensetzen', dazu unten noch etwas mehr) zusammen. Daher gibt es kein Äquivalent zu dem xorg-server und auch "Wayland", was man einfach installieren kann. Anwendungen werden unter Wayland als Clients bezeichnet. Es gibt keinen Message Bus mehr, stattdessen sehen Compositor und Clients nur jeweils die Informationen, die sind direkt brauchen. Client und Compositor tauschen keine Renderer Primitives aus, stattdessen nur fertig gerenderte Buffer.

Der Vorteil ist, dass Wayland wesentlich einfach und sicherer als X11 zu implementieren ist. Der Nachteil, dass es deutlich weniger Flexivilität gibt. In der X11-Welt war ein Windows Manager recht einfach zu implementieren, da der xorg-server die sozusagen Drecksarbeit abnahm. In der Wayland-Welt muss der Autor des Compositors alles von Rendering bis Input Handling selbst implementieren. Es gibt Bibliotheken, die das machen, aber der Aufwand ist dennoch größer.

Ein Wayland-Compsitor wie der hier genannte Wayfire ist also das, was früher xorg-server + Window Manager waren.

Nun müssen die Buffer von der Anwendung zum Compositor kommen. Das funktioniert grob so, dass die Anwendung per OpenGL oder Vulkan in einen Buffer rendert. Ist sie fertig, überträgt sie diesen Buffer an den Compositor. Der Compositor fügt alle Buffer zusammen (daher 'zusammenkleben') und rendert das Ergebnis auf den Bildschirm. Da die Anwendung direkt selbst rendert und der Compositor nur zusammenfügt, kann die Anwendung zum Beispiel auf Subpixel genau rendern. Das führt zu deutlich besserer Schriftqualität ggü. X11, wo am Ende immer der xorg-server renderte. Wodurch die Anwendung nicht auf Subpixel genau rendern konnte. Die Anwendung schickt immer fertige Buffer an den Compositor, der kann die Ausgabe in exakt der Geschwindigkeit rendern, wie der Monitor sie darstellt. Damit sind Tearing und andere Formen von Gewabbel einfach und eleganz ausgeschlossen.

Zum Übertragen der Buffer gibt es kein standardisiertes Verfahren, allerdings müssen alle beteiligten Clients, der Compositor und idealerweise auch der Grafiktreiber darunter die gleiche Sprache sprechen. In der Praxis hat man sich auf GBM geeinigt, was unten drunter DMA-BUF nutzt. Dabei allokiert der Grafiktreiber über den Kernel den Buffer. Die Anwendung rendert in ihn, der Compsitor liest aus ihm. Die Daten fließen ohne umkopiert werden zu müssen. Alle freie Grafiktreiber unterstützen unter Linux GBM, solange es Wayland gibt. Unter FreeBSD tun sie es auch schon seit Jahren. Allerdings weigerte sich Nvidia viele Jahre GBM zu unterstützen, weshalb Nvidia und Wayland sich ausschlossen. Inzwischen tun sie es und das auch ganz brauchbar, aber darin liegt der Grund, dass man zwingend die Nvidia-DRM-Schnittstelle braucht.

Last but not least konnte xorg-server wunderbar in Software rendern. Die meisten Wayland-Compsitoren und Clients können zwar durch llvmpipe und lavapipe als Software-Implementierungen in Software rendern, aber Spaß macht das nicht. Eine einigermaßen brauchbare GPU - und da reicht wirklich schon eine 15 Jahre iGPU von Intel aus - mit OpenGL 3.2 Unterstützung sollte es schon sein.
 
derzeit hänge ich mit labwc ab.
Auf meinem Laptop läuft es quasi dauernd und mit einer falschen Openbox rc.xml und menu-xml auf FreeBSD 14.2 und ab und zu schließe ich den Laptop und lasse ihn mal ruhen. Der Laptop benutzt i915kms.

Auf meinem PC mit nvidia Karte und FreeBSD 14.3 nutze ich labwc derzeit gleichzeitig zu X. Hier habe ich einige Konfigurationen vorgenommen, um fehlerhafte Syntax aus den Openbox-Dateien zu entfernen und es war ja klar, dass hier der Teufel im Detail steckt. Heute habe ich mehrere Stunden mit Suche nach Fehlern verbracht, die ich mir selbst in die rc.xml geschrieben hatte. Leider meldet sich labwc nicht mit so schönen Fehlern, wie ich das aus Openbox kenne und man sieht ja bekanntlich den Wald vor lauter Bäumen ganz oft nicht und so habe ich ein falsches ">" sehr lange übersehen und musste danach sehr aufwändig suchen.
Nun funktionieren immerhin schon fast zwei drittel meiner Wünsche.
Es ist mühsam, sich durch die Beschreibungen zu arbeiten und diese auch noch richtig zu verstehen. labwc sieht einige Dinge anders, als bei Openbox, geringfügig anders, aber genau da liegt ja der Hase im Pfeffer.
Was bei mir häufiger auf diesem PC passiert (nicht auf dem Laptop), sind merkwürdige Hänger im Chrome (den ich hier deshalb nutze, weil ich die gleichzeitig aktive FireFox-Sitzung unter X nicht stören will). Plötzlich funktionieren Tabs nicht mehr, zeigen nur noch ihr Bild, aber ansonsten keine Funktion oder es gehen nur noch ein oder zwei Links auf den Seiten. Außerdem verabschiedet sich schon mal das xfce4-panel, indem es unsichtbar wird. ps zeigt es noch als aktiv an, aber es ist nicht mehr zu sehen.
Dazu will ich nichts fragen. Viele Empfehlungen aus dem Netz sind mir unerklärlich und oft auch veraltet. Deshalb arbeite ich zunächst ohne diese Dinger und sehe, wie weit ich ansonsten komme.

Zeit für einen Film unter Wayland.
Wollte nur mal wieder was melden, bevor jemand glaubt, ich mache da gar nicht weiter.
 
Interessanter Bericht! Und er ist meinen Erlebnissen recht ähnlich. Meine openbox-labwc-Umstellung ist ganz gut gelungen, die Menüs und Startdatein stehen und passen. Aaaber: Es gibt ein paar "unsichtbare" Anwendungen, und gefühlt werden es immer mehr. Also Programm wir aufgerufen und man sieht --- nichts. In der Taskleiste jedoch taucht es auf. Hab ich zu oft darauf geklickt, laufen beispielsweise 5 unsichtbare geeqies, natürlich mit der entsprechenden Systemlast. Ganz schlecht.

Das ist mir bisher mit wayfire noch nicht passiert und so scheint mir das der robustere compositor zu sein. Dabei tendiere ich ja eigentlich zu labwc, kein Wunder als jahrelanger open/fluxbox-Anwender.

Hab jetzt 2 Rechner so laufen: Ein Thinkpad mit i915 und ein Asus-Board mit amd GPU, wobei der Grafiktreiber auf dem Thinkpad spürbar flüssiger läuft.

Trotz aller Widrigkeiten sehe ich den totalen Umstieg auf Wayland so ganz langsam kommen, jedenfalls bei mir. Ich fände es aber sehr hilfreich, wenn die Wayland-Leute ihre Apps weniger kryptisch gestalten und die Dokumentation starrk verbessern würden. Sind teilweise sehr miese man-pages.

Ganz übel empfinde ich es, wenn Anwendungen ohne Basis-Konfiguration kommen und dich mit einem schwarzen Bildschirm empfangen, der auf keinen Tastendruck reagiert. Ist ein Gefühl, als hätte ich ein neues Auto gekauft, bei dem die Steuerzeiten und die Zündung völlig verstellt sind. Es springt vielleicht gerade so an, aber unter Last stirbts ab.

LG
Berni
 
berni51 schrieb:
Interessanter Bericht! Und er ist meinen Erlebnissen recht ähnlich. Meine openbox-labwc-Umstellung ist ganz gut gelungen, die Menüs und Startdatein stehen und passen. Aaaber: Es gibt ein paar "unsichtbare" Anwendungen, und gefühlt werden es immer mehr. Also Programm wir aufgerufen und man sieht --- nichts. In der Taskleiste jedoch taucht es auf. Hab ich zu oft darauf geklickt, laufen beispielsweise 5 unsichtbare geeqies, natürlich mit der entsprechenden Systemlast. Ganz schlecht.

Das ist mir bisher mit wayfire noch nicht passiert und so scheint mir das der robustere compositor zu sein. Dabei tendiere ich ja eigentlich zu labwc, kein Wunder als jahrelanger open/fluxbox-Anwender.

Hab jetzt 2 Rechner so laufen: Ein Thinkpad mit i915 und ein Asus-Board mit amd GPU, wobei der Grafiktreiber auf dem Thinkpad spürbar flüssiger läuft.

Trotz aller Widrigkeiten sehe ich den totalen Umstieg auf Wayland so ganz langsam kommen, jedenfalls bei mir. Ich fände es aber sehr hilfreich, wenn die Wayland-Leute ihre Apps weniger kryptisch gestalten und die Dokumentation starrk verbessern würden. Sind teilweise sehr miese man-pages.

Ganz übel empfinde ich es, wenn Anwendungen ohne Basis-Konfiguration kommen und dich mit einem schwarzen Bildschirm empfangen, der auf keinen Tastendruck reagiert. Ist ein Gefühl, als hätte ich ein neues Auto gekauft, bei dem die Steuerzeiten und die Zündung völlig verstellt sind. Es springt vielleicht gerade so an, aber unter Last stirbts ab.

LG
Berni
Zum Vergrößern anklicken....

Ich will jetzt nicht das es so rüberkommt als wäre ich KDE/GNOME "fan" im engeren sinne, ich hab eigentlich über 20 Jahre, genausolange eigentlich wie sylpheed xfce4 genutzt und würde mich freuen wenn die irgendwann full-wayland-support schaffen z.B.

Aber zumindest unter Linux hatte ich nicht ein einziges der beschrieben Probleme unter KDE oder GNOME - villeicht hängen die mit ihrer schmalen Manpower bei labwc & co da einfach etwas hinterher will ich damit sagen.

Ich hab mich auch sehr bewusst dagegen entschieden xfce4 mit z.B. Labwc und Wayfire wie es seit kurzem experimentell dort unterstützt wird zu verwenden. Ich hab wenig Zeit groß an sowas unkonstruktiv rumzubasteln, der erkentnissgewinn ist für mich persönlich meist die Zeit nicht Wert.
 
Ich hab auch schon überlegt ob ich was schreibe, ich will euch eure Wayland Experimente nicht madig machen, und solange ihr Spass daran habt, spielt damit rum.

Aber ansonsten bin ich da bei @CommanderZed, ich denke für die meisten wäre ein KDE, in das man 1-2h Konfiguration steckt um es an seine Wünsche anzupassen, der einfachere und auch zukunftssichere Weg für Wayland.
 
Ich war bis zum Lesen dieses Threads der Meinung bzw. auf dem Stand, dass KDE mit Wayland gar nicht unter FreeBSD läuft.... :rolleyes:
Jetzt habe ich auf 14.3 aktualisiert und gleichzeitig auf Wayland umgestellt. Das läuft dann auch ohne Probleme.
Danke für den Thread hier.
 
medV2 schrieb:
Ich hab auch schon überlegt ob ich was schreibe, ich will euch eure Wayland Experimente nicht madig machen, und solange ihr Spass daran habt, spielt damit rum.

Aber ansonsten bin ich da bei @CommanderZed, ich denke für die meisten wäre ein KDE, in das man 1-2h Konfiguration steckt um es an seine Wünsche anzupassen, der einfachere und auch zukunftssichere Weg für Wayland.
Zum Vergrößern anklicken....

Mein Idee ist halt auch, bevor man mit Wayland erstmal super viele negativ-erfahrungen macht weil man noch nicht ganz ausgereifte Software verwendet, erstmal eine der beiden Optionen für erste Schritte zu testen die deutlich ausgereifter sind.

Das ist eigentlich generell mein Ansatz wenn ich mich mit neuer komplexerer Software (öä) beschäftige: Ich besorge mir einen Überblick und überlege dann wie ich mir ein gutes Testszenario baue um mir das Thema erstmal möglichst "einfach" anzuschauen.

Dabei ist es mir besonders wichtig zu schauen das alles "drumherum" möglichst kein Störfaktor ist. Das ist dann natürlich immer auch eine Kombination aus dem was gut vertestet ist, was schnell und einfach villeicht zu installieren ist aber auch meinen eigenen "Skills" - wenn das Standard-System aus der Anleitung eine Red-Hat-Linux-Distrie ist von der ich wenig Ahnung hab, ist das villeicht auch nicht Optimal.

Villeicht zwei beispiele:
Wenn ich mir eine komplexe php-anwendung anschauen möchte ist villeicht ein standard LAMP Stack mit einer distrie die ich gut kenne besser als die "komplexität" von OpenBSD, OpenBSDs httpd, RelayD, Chroot etc eventuell der falsche Ansatz für erste Schritte, sonder das was die meisten Anwender und Entwickler der App verwenden, wo die meisten bugs oder einstiegsprobleme leicht googlebar sind.
Vermutlich installier ich es ja eh nochmal fürs "produktiv" System neu und kann dann meine erfahrung auf OHMP übertragen.

Ich habe eine komplexe Desktop-App die ziemlich "Bleeding Edge" mit ständigen wichtigen neuen Updates ist.
Für die *BSDs gibts nur veraltete Packages, für Debian Stable und Ubuntu auch, es gibt keinerlei RPM Pakete und die Windows-Builds haben nen riesigen roten Rahmen "Sehr experimentell" wenn man sie Downloaden will. Archlinux baut die aber immer recht aktuell, die Entwickler schreiben auch oft das sie arch nutzen und ich bin auch bei Archlinux gut orientiert.
Natürlich könnte ich jetzt erstmal die veralteten Packages verwenden, dann feststellen das die mir zu alt sind für das was ich herausfinden möchte, versuchen die selbst zu bauen. Oder ich nutze einfach Archlinux.

Mein Punkt ist dabei im Kern vor allem "Ich möchte wenn ich etwas neues Ausprobiere mich auf die Anwendung konzentrieren und dafür eine möglichst passende Umgebung schaffen die dieses Ziel im Fokus hat, und nicht zu viel links/rechts schauen und basteln müssen."
Wenn etwas für mich neu ist, ist ja auch das Problem das ich oft garnicht bewerten kann ob etwas villeicht "normal" bei einer Anwendung ist, ein "bekannter Bug, es mit vorherigen Versionen mal besser war" oder ob das villeicht ganz komisch ist aber an meinen Setup drumherum liegt.

Mich anschließend noch damit zu beschäftigen wie das ganze auf meinen Lieblings-Setup dann läuft kann ich ja immer noch.
 
CommanderZed schrieb:
der erkentnissgewinn ist für mich persönlich meist die Zeit nicht Wert.
Zum Vergrößern anklicken....
für mich auch nicht, ganz ehrlich. Was ich an Erkenntnissen heute gewinne, habe ich morgen bereits wieder vergessen und wenn n icht, ist es spätestens übermorgen schon wieder veraltet. Ich arbeite ja nicht produktiv und nicht professionell an solchen Themen sondern nur als kleiner, dummer Endanwender.

Mir geht es um Bequemlichkeit.
Gewiss auch eine Portion Sturheit.
Lassen wir mal das Thema Wayland weg, denn das spielt für mich dabei eine eher untergeordnete Rolle.
KDE könnte ich auch auf X benutzen, oder irgend ein anderes DE. Die Vorteile eines solchen kompletten DE liegen ja auf der Hand und gelten nicht bloß für Wayland. Tatsächlich hatte ich über viele Jahre hinweg immer nur KDE benutzt, schon bevor das eine Versionsnummer mit 1.x hatte. Mit KDE4 fing es an, mich extrem zu nerven und ich versuchte da erst mal zögerlich, einen anderen Weg zu gehen und landete eher aus Zufall bei Openbox. Von KDE zu Openbox war für mich ein großer Aufwand und viele nette Dinge konnte ich nicht so realisieren, wie ich die aus KDE kannte. Es braucht also in der Richtung keine Überzeugungsarbeit bei mir, ich erkenne durchaus die Vorteile eines kompletten DE.
Nun sagen wir mal, Openbox gibt es nicht mehr (ist ja beinahe auch so) und ich müsste hierfür einen ersatz suchen. Dann würde ich versuchen etwas zu finden, das möglichst ähnlich ist und wo ich die Konfigurationen und Anwendungen möglichst ebenso benutzen kann, denn das ist für mich der bequemste Weg. Oder sagen wir, der Weg der geringsten Änderungen. Und dann würde ich, was immer ich probiere, bis zum Erbrechen versuchen so einzusetzen, dass es für meine Gewohnheiten passt, oder eben für meinen Sturkopf, bevor ich mich entschließen würde, aufzugeben und einfach KDE zu nehmen.
Das mag blöd erscheinen, regelrecht dumm, aber ich eben auch nicht besonders klug.

Aber gewissermaßen raffiniert, mit einer natürlichen Bauernschläue folgere ich: wenn es doch so einfach ist, Wayland mit KDE zu betreiben, dann bleibt dieser Weg doch immer noch als Fallback, wenn die X-Geschichte mir all zu schnell wegbricht. Ich brauche mich nun noch nicht daran zu gewöhnen, habe ja noch Zeit und muss nicht ab demnächst schon total auf Wayland umstellen.
Wer weiß, ob ich nicht in der Zeit schaffe, vollkommen mit einer Openbox - Ersatzlösung a la labwc zurecht zu kommen? Mir ist es das Wert, einige Zeit dahin zu investieren. Man kann das vielleicht ja auch Spielerei am PC bezeichnen und ich kann mir das so einrichten, dass ich Zeit dafür habe.
 
@CommanderZ und @medV2: Sachlich und logisch betrachtet kann ich euch nur recht geben. Ein quasi fertiges Wayland-System mit KDE oder Gnome gibts ja von der Stange. Hab sogar eins unter Debian hier laufen: Robust, rock-solid, funktional, nett anzusehen, sofort einsatzbereit.
Nur mach ich so gut wie nichts auf diesem schönen System - es entspricht einfach in keiner Weise meiner Art, am PC zuarbeiten. Alles, wirklich alles. bekomme ich mit meinen "Lieblingssystemen", also einem BSD mit mwm, openbox oder ctwm, schneller und einfacher hin.

Oder kurz gesagt: Diese fertigenSystem sind nicht mein Ding, ich find sie unproduktiv und dazu langweilig. So ein Unix möchte ich nicht. KISS forever.

LG
Berni
 
berni51 schrieb:
@CommanderZ und @medV2: Sachlich und logisch betrachtet kann ich euch nur recht geben. Ein quasi fertiges Wayland-System mit KDE oder Gnome gibts ja von der Stange. Hab sogar eins unter Debian hier laufen: Robust, rock-solid, funktional, nett anzusehen, sofort einsatzbereit.
Nur mach ich so gut wie nichts auf diesem schönen System - es entspricht einfach in keiner Weise meiner Art, am PC zuarbeiten. Alles, wirklich alles. bekomme ich mit meinen "Lieblingssystemen", also einem BSD mit mwm, openbox oder ctwm, schneller und einfacher hin.

Oder kurz gesagt: Diese fertigenSystem sind nicht mein Ding, ich find sie unproduktiv und dazu langweilig. So ein Unix möchte ich nicht. KISS forever.

LG
Berni
Zum Vergrößern anklicken....

Ich muss ehrlich sagen - meine Kern-Erwartung an einen Desktop ist:

Ich klick irgendwo drauf, dann öffnet sich ein Programm, das ding zaubert da ne Fensterleiste oben und ich hab nen paar Knöppies um zwischen den Anwendungen zu wechseln, sie zu minimieren, maximieren, größer-kleiner zu schieben etc. - evtl. sind virtuelle Desktops nett insb. wenn man mal nur mit Notebook-Bildschirm arbeitet. Dazu villeicht noch ein Menü mit 2,3 sachen die man gelegentlich mal einstellt. Außerdom sollte technisch (su) alles unterstützt werden.

Das erfüllt so grob KDE, genauso wie openbox, mein geliebtes XFCE4, MS Windows, vermutlich auch MacOS. Nen paar prinziepchen dürfen für mich gerne ähnlich sein, weshalb ich das aktuelle Gnome da für mich ausgeschlossen hab. (Dabei ist son bisschen eine gewisse ähnlichkeit zu Windows für mich nicht ganz unwichtig weil ich halt viel mit beiden Arbeite, son paar sachen sind da einfach inzwischen sehr unbewusst. xfce4 und kde erfüllen das zB. gleichermaßen) Der rest sind nuancen die mich nicht intensiv interessieren.

Was ich an KDE tatsächlich mochte waren einfache Einstellmöglichkeiten für Multi-Monitor und Scaling bei unterschiedlichen auflösungen, das hat auf anhieb funktionier und ist bei mir relativ wichtig. Das lässt sich anderswo sicher Händisch auch machen, ich find ein GUI dafür aber nützlich

Wenn ich noch nen nettes Hintergrundbild einrichten kann ist mein bedarf an Eye-Candy erfüllt. Der rest ist mir etwas egal. Ob ich in irgend nen Menü wie bei KDE die Energieeinstellungen finder oder irgend ne Config datei dafür bearbeiten muss ist für mich gehupft wie gesprungen. Hauptsache es funktioniert und das im idealfall Stabil und so schnell das ich nichts groß davon bemerke.

Gerade das Thema "gleichgroße externe Displays mit unterschiedlichen Auflösungen" und wechsel zwischen diesem Modi und "Notebook allein" ließ sich mit xorg + xfce4 bei mir nicht mehr sinnvoll realisieren. Ansteuern? Ja! Aber unterschiedliches Scaling war absolut nicht möglich da sich viele alte X Anwendungen nicht direkt dann gehalten haben und teilweise nicht einheitlich genug agiert haben.

Der Wechsel auf Wayland + KDE hat das dann komplett gelöst. Meines wissens nach lässt sich das mit etwas reinfuchsen auch mit anderen Wayland Compositor teilautomatisiert lösen. Da bin ich aber zu bequem für und ich misse nichts zwischen xfce4 und kde wenn ich ehrlich bin.

Sollte xfce4 es irgendwann schaffen eine vollwertige Wayland-Version anzubieten werde ich das mit Sicherheit ausprobieren und vermutlich auch wechseln.

Es ist natürlich völlig okay wenn du ganz andere Anforderungen als ich an einen Desktop hast und andere Arbeitsweisen.

Mein Punkt war auch eher nicht das madig zu machen, sondern eher bei den "ersten Schritten" mit einem unbekannten Thema, und wenn einige hier ja (dich meine ich nicht) auch generell sich mit dem komplexen Thema merklich schwer tun, es villeicht ne gute Idee ist erste Schritte mal in einem "fertigen" System zu gehen und wenn da alles läuft und man eine "gute technische Erfahrung" gemacht hat villeicht dann erst sich die komplexen Themen anzuschauen.

Kleine technische Info für @berni51 ich nutze auch auf einem Gerät Debian und auf dem anderen Archlinux und unter Arch scheint KDE + Wayland noch ne Idee schnittiger zu laufen ohne das jetzt irgendwo konkret festmachen zu können.
 
damit man das nicht falsch versteht: ich will niemanden von labwc oder auch nicht von openbox überzeugen und begreife durchaus, dass für die meisten Anwender andere Sachen wichtig sind und es gibt auch keinen ernsthaften Grund, nicht ein ausgereiftes DE zu nutzen. Es ist ja noch nicht ausgemacht, dass ich überhaupt bei labwc bleibe. Es ist halt mein zweiter Versuch, nach cage.

Und trotzdem muss ich eine Lanze für labwc brechen, wenn auch vielleicht nur eine kleine.
Mein Weg war ja falsch. Statt weiter zu lesen, nahm ich einfach meine openbox rc.xml und warf sie ins labwc-Verzeichnis. Das tat ich, obwohl ich wusste, dass labwc nicht openbox ist, einfach der puren Neugierde halber. Überraschend funktionierte aber schon ein Teil meiner Konfiguration auf Anhieb unter labwc und so machte ich an dem Punkt weiter und korrigierte die Einstellungen, die nicht funktionierten. Dabei las ich dann immer mehr in der Dokumentation und, wo ich nun vielleicht 80% meiner gewünschten Funktionen wieder habe, sehe ich dies:
labwc.github.io

labwc

An Openbox inspired wlroots-based stacking Wayland compositor.
labwc.github.io labwc.github.io
Code: 
mkdir -p ~/.config/labwc
wget https://raw.githubusercontent.com/labwc/labwc/master/docs/environment -O ~/.config/labwc/environment
wget https://raw.githubusercontent.com/labwc/labwc/master/docs/autostart -O ~/.config/labwc/autostart
wget https://raw.githubusercontent.com/labwc/labwc/master/docs/menu.xml -O ~/.config/labwc/menu.xml
wget https://raw.githubusercontent.com/labwc/labwc/master/docs/rc.xml -O ~/.config/labwc/rc.xml
und dies https://github.com/labwc/labwc/blob/master/docs/rc.xml.all
Diese Beispiel oder Demo Konfigurationen dürften für die meisten Nutzer bereits befriedigend sein und nur geringe Anpassungen brauchen. Damit ist man sicher sehr viel schneller auf einer nutzbaren Oberfläche, als ich das nun fabriziert habe.
 
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)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben