Server-1: PipeWire v: 1.0.5 status: active with: wireplumber status: active tools: pw-cat,pw-cli,wpctl
Server-2: PulseAudio v: 17.0 status: active with: pulseaudio-alsa type: plugin tools: pacat,pactl
Bei dir laufen sowohl pulseaudio vermutlich für den internen Lautsprecher als auch pipewire für den sound über hdmi für externe Geräte. Bei welcher Soundausgabe sind die gemachten Einstellungen nicht persistent?
Starte in der Kommandozeile
pavucontrolund schaue dir die auswählbaren Kategorien an, besonders 'Konfiguration' oben rechts.
Bei mir ist dort 'Analog Stereo Duplex' ausgewählt.
Zeige bitte die Ausgabe von
inxi -AaxxWelches Leap? Pulseaudio oder pipewire? Bei pavucontrol etwas verstellt?
Deine Diagnose zeigt, dass der neue rtw88 unter Tumbleweed deinen usb-wifi-stick noch nicht vollumfänglich steuern kann.
Daher musst du wieder zurück zu rtl88x2bu mit blacklist von rtw88_8822bu, was du ja selbst herausgefunden hattest.
Die ursprüngliche Idee war, alle rtl88-Pakete zu entfernen, damit nach einem Neustart endlich der rtw88 seinen Dienst tun kann. Allerdings war das bevor du blacklist und ähnliches vorgenommen hast.
... offensichtlich ist da irgendwo der Wurm drin, es kann ja nicht sein, das bei zwei Linux Distributionen, die fast identische Kernelversionen verwenden bei einer die Wlan-Treiber out of the Box problemlos funktionieren und bei der anderen herumgebastelt werden muss.
Das müsste bei Tumbleweed auch gehen, wenn nicht die falschen Pakete installiert sind. Daher die Frage
zypper se -si rtl88in post # 20. Warum hast du uns die Antwort nicht gezeigt?
Ich vermute ein tiefergehendes Problem. Hiermit sollten sich einmal die entsprechenden Entwickler befassen.
Das sehe ich inzwischen ebenso. Obwohl ich mich gelegentlich erfolgreich verbinden und den remote desktop bedienen konnte, gab es immer wieder Probleme mit “Multiple logins are not supported”, so dass ich über ssh auf den server gehen und mit loginctl kill-session <#> erst wieder aufräumen musste.
Inzwischen habe ich herausgefunden, dass dies ein bekanntes Problem ist: Trouble with VNC: don’t want session management
Daher habe ich den ebenfalls mit VNC-Protokoll laufenden KRFB/KRDC (Server/Client) ausprobiert, was leicht zu installieren war und funktionierte. Vielleicht ist das auch für dich eine Möglichkeit, um den Zugriff auf den Desktop eines anderen Rechners zu erlangen.
Threema hat auch bei mir gezickt, daher habe ich die ch.threema.threema-web-desktop flatpak-App gelöscht und dann die Beta-Version von Threema 2.0 für Desktop genommen
$ flatpak install --from https://releases.threema.ch/flatpak/threema-desktop/ch.threema.threema-desktop.flatpakrefdie lief problemlos.
Tatsächlich ist der sddm aktiv. Ich habe gdm installiert, aber konnte es bislang nicht aktivieren.
Hast du dir als root die installierten Displaymanager zeigen lassen
update-alternatives --list default-displaymanagerund dann mit
update-alternatives --config default-displaymanagerdie Umstellung durchgeführt?
Ich sehe gerade, es müsste auch unter Yast gehen mit
--> Verschiedenes --> Alternativen --> default-displaymanager