Cyberstern@netzwerkgoettin oh das hatte ich auch schon, bei mir war’s ein treiber-crash (device wedged) im amd gpu treiber, spammt ziemlich im dmesg rum. Gnome’s compositor verträgt das leider nicht, KDE scheint es eher zu überleben, aber dabei crashen dann diverse programme nur die session selbst bleibt offen. Warum Ghostty den auslöst konnte ich aber leider auch nicht ergründen. Ich bin zähneknirschend zu alacritty zurück. Hast du auch was im dmesg log oder is das bei dir wieder was anderes?
Patrick Cernko@dunkelstern @netzwerkgoettin ich arbeite jetzt seit kurzen erst mit #Wayland, davor 30 Jahre #X11. Ich habe inzwischen an einigen Stellen das gute alte Gefühl, dass da was noch nicht so ganz ausgereift ist. Hatte auch schon einige Session-Restarts und nervige Bugs. Arbeite allerdings unter #KDE mit #Konsole. Am nervigsten find ich die Zwischenablage: Sync von PRIMARY und Clipboard funktioniert nicht richtig und #xclip via #SSH geht scheinbar gar nicht mehr, doof bei Zertifikaten.
Hm ich denk das xclip problem wird daran liegen wie der paste buffer unter wayland funktioniert: die app die was in den buffer wirft registriert beim compositor “hey ich hab da was” aber nicht den inhalt. Wenn du einfügst nimmt der compositor sich die aktuellste app die da was registriert hat und fragt die in dem moment nach den daten. Wenn die app zu dem zeitpunkt schon beendet ist geht das natürlich nicht mehr, daher funktioniert auch xclip nicht (das is ja dann schon weg). Für den workflow müsste man die daten dem terminal emulator übergeben der ja weiterhin offen ist. Ob und wie das geht kann ich dir nicht sagen, aber das ist zumindest das problem dahinter. “wlclip” existiert, geht aber nur lokal (das forkt sich in den hintergrund und läuft weiter, is halt ein workaround).
Wenn du KDE laufen hast: hast du den clipboard manager (klipper) laufen? Damit müssten sich die sync probleme lösen lassen und in der theorie kann der auch dinge übernehmen die wlclip mit dem fork workaround erledigt weil das ding ja weiterläuft. Buffer von remote kopieren mit xclip könnte gehen sofern der das supported, ist aber halt dann via XWayland.
Seasion restarts hab ich mittlerweile wegen grafiktreiber bugs unter X11 mehr als unter wayland. Vor 2 jahren war das noch andersrum. Nen realen crash hatte ich jetzt nur wegen “wedged amdgpu” treibern in spielen und ghostty (keine ahnung was die machen). Meine rechner sind aber mittlerweile AMD only, keine ahnung wie das in intel oder nvidia-land aussieht gerade.
@dunkelstern Das mit dem workflow mit wayland war mir noch nicht bekannt. Ja, dann wird das wohl nix. Ist halt schade, weil ich das unter X11 immer gerne zum Datentransfer genutzt habe, ging ja auch transparent via SSH. wlclip hab ich gesehen, aber wegen local-only als Alternative verworfen.
klipper nutz ich seit es den gibt. Da hab ich ja auch eingestellt, dass synchronisiert werden sollen. Mit Wayland funktioniert das aber nicht mehr richtig, z.B. in FF markieren, dann "Shift-Ins" in Konsole.
klipper nutz ich seit es den gibt. Da hab ich ja auch eingestellt, dass synchronisiert werden sollen. Mit Wayland funktioniert das aber nicht mehr richtig, z.B. in FF markieren, dann "Shift-Ins" in Konsole.
@errror es gibt ein escape kommando (OSC-52) das genau das tut: es sagt dem terminal emu dass er das clipboard überschreiben soll. Konsole kann das seit juli 2024, evtl. musst du dir nur nen wrapper script um base64 und dieses kommando basteln um die funktionalität wieder zu kriegen die dir mit xclip verloren gegangen ist.
@dunkelstern Du bist mein Held. Hab diese Seite gefunden, die mir geholfen hat, zu verstehen, wie ich das machen muss: https://sunaku.github.io/tmux-yank-osc52.html
In meiner bashrc hab ich jetzt eine stark vereinfachte Funktion:
```
function yank() {
echo -ne "\033Ptmux;\033""\033]52;c;$( cat "$@" | base64 | tr -d '\r\n' )\a""\033\\"
}
```
In meiner bashrc hab ich jetzt eine stark vereinfachte Funktion:
```
function yank() {
echo -ne "\033Ptmux;\033""\033]52;c;$( cat "$@" | base64 | tr -d '\r\n' )\a""\033\\"
}
```