Il Wayland di noialtri (non gnome o plasma)

[frapox]

Al contrario invece nel gaming mi pare di aver visto svariati benchmark che non danno nessun vantaggio di Wayland su Xorg, sopratutto quelli che richiedono Wine.

Perché il 99% dei giochi gira su Xwayland, ma sta arrivando il supporto Wayland su WINE.
https://www.phoronix.com/news/Wine-8.12-Released

Sì avevo visto questa news. Bene, vedremo i benchmark a inizio '24 con Wine 9 Wayland-nativo.

PS. questa è una killer feature che farà davvero felici gli utenti Plasma/Wayland, quando sarà implementata.

Anche questa lo sarà, poter cambiare al volo il compositor: https://youtu.be/JYfzAuRmBjo

Questa sinceramente non la vedo come una killer feature ma una interessante demo delle potenzialità di (QT)Wayland.

[emanuc]

Questa sinceramente non la vedo come una killer feature ma una interessante demo delle potenzialità di (QT)Wayland.

Lo sarà, pensa a questo caso d'uso: utilizzo del desktop e quindi compositor che faccia un pò tutto e compositor ottimizzato per il gaming come gamescope, quando dovrai giocare cambi al volo su gamescope ed avrai un compositor ottimizzato per il gaming, quando avrai finito passi di nuovo al compositor per l'utilizzo desktop.

[frapox]

Questa sinceramente non la vedo come una killer feature ma una interessante demo delle potenzialità di (QT)Wayland.

Lo sarà, pensa a questo caso d'uso: utilizzo del desktop e quindi compositor che faccia un pò tutto e compositor ottimizzato per il gaming come gamescope, quando dovrai giocare cambi al volo su gamescope ed avrai un compositor ottimizzato per il gaming, quando avrai finito passi di nuovo al compositor per l'utilizzo desktop.

Mi sembra una complicazione inutile avere due compositor. Sarebbe meglio avere UN compositor con la "GameMode" che consenta al gioco a tutto schermo di "bypassare" il compositor (o che questo agisca solo come passthrough tra app e scheda video). Non ricordo se Plasma aveva già implementato una cosa del genere.

[emanuc]

A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. Well, it’s not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland

https://pointieststick.com/2023/09/17/s ... and-thing/

[frapox]

A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. Well, it’s not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland

https://pointieststick.com/2023/09/17/s ... and-thing/

Interessante, grazie della segnalazione.
Me lo sono letto tutto e sono d'accordo quello che dice Graham, pur con alcune precisazioni.

Uno dei motivi del ritardo nell'adozione di Wayland da parte degli sviluppatori è che all'inizio il "core" del protocollo mancava di molte funzioni che invece X11 aveva. Così con Wayland i vari progetti desktop dovevano crearsi il loro compositor e incorporare tali funzioni, che non erano ancora standardizzate. Chiaramente mettere insieme tot teste da tot progetti anche molto diversi tra loro per produrre standard comuni è un processo lungo e per nulla semplice. Però -- aggiungo io -- non c'era altra via: solo coinvolgendo tutti i soggetti interessati (aziende e comunità) sarebbe stato possibile produrre qualcosa accettabile per tutti. Quindi, al contrario di quel che dice Nate, secondo me aver prodotto inizialmente un "core" funzionante con le funzioni essenziali e solo dopo le varie estensioni che andassero a coprire tutte le funzioni di X11 mancanti, non è stato un errore, è stato l'inevitabile processo (democratico) per affrancarsi da X11.

C'è un altro aspetto storico che forse non viene preso in considerazione cioè il fatto che fino al 2018 (10 anni dopo la prima presentazione di Wl) non c'era ancora la certezza su quale dovesse essere il successore di X11. C'era anche Mir in campo e Mir inizialmente non era un Wayland compositor, era una roba a sé stante. E poi aggiungiamo la reticenza di nVidia ad voler imporre API non comuni (EGLStreams anziché GBM) che sicuramente ha ulteriormente frenato...

[steff]

Per la cronaca: sto usando labwc con quasi tutto il DE di LXQt da mesi ormai, le limitazioni sono per la posizione del pannello, la barra delle applicazioni e il pager desktop in assenza di un protocollo.
Stabilissimo e un sviluppo serio e constante che integra pezzo per volta funzioni ancora mancanti, per wayfire bisogna aspettare il rodaggio per la 0.8 e il port del plugin LXQt-dsktop-shell.
LXQt sta aspettando la stable release di KDE Frameworks 6 che dovrebbe arrivare di febbraio - gli strumenti di qt5 non sono molto adatti per wayland, l'unico accettabile è nel demone di notifiche.
https://github.com/orgs/lxqt/projects/4 ... lterQuery=

[emanuc]

Si aggiunge anche Fedora Workstation (GNOME): https://pagure.io/fedora-workstation/issue/395

[emanuc]

Già c'è il primo software che richiede Wayland e non funzionante su Xorg:

The Studio One 6.5 Linux beta explicitly supports Ubuntu 23.04 with Wayland only

https://www.omgubuntu.co.uk/2023/10/pro ... orts-linux

[frapox]

Già c'è il primo software che richiede Wayland e non funzionante su Xorg:

The Studio One 6.5 Linux beta explicitly supports Ubuntu 23.04 with Wayland only

https://www.omgubuntu.co.uk/2023/10/pro ... orts-linux

Notizia interessante, per questi motivi:
1) un programma professionale, ovvero supportato da un'azienda commerciale, viene reso disponibile per Linux -- uno dei pochi.
2) questo programma non supporta da subito Xorg (e quindi taglia fuori una fetta di utenza con PC obsoleti)
3) hanno deciso di supportare solo la ultima semestrale
4) hanno deciso di pacchettizzare nel tradizionale deb anziché snap

I punti 3 e 4 mi sembrano scelte piuttosto discutibili dato che molti utenti che usano programmi Pro stanno su una LTS, solitamente. E inoltre Snap avrebbe dato la possibilità di includere tutte le dipendenze necessarie nel pacchetto facilitandone la distribuzione e l'aggiornamento.

C'è anche da aggiungere che, come specificato nella pagina ufficiale, questa beta ha limitazioni piuttosto rilevanti che lo rendono (almeno in parte) meno allettante, in particolare:

• 3rd-party plug-in GUIs
• Linux-specific plug-in formats (lv2, dssi, vamp)

Comunque è sicuramente significativo che Presonus abbia scelto di puntare su questa nicchia di utenza potenziale (non sono certo in molti a usare Linux per l'audio), staremo a vedere le future evoluzioni.

[alderix]

Ciao,
io ho cercato di installare Presonus Studio One 6 su ubuntu 22.04 senza wayland, ma non funziona perche' mancano delle dipendenze.
Se sono riuscito ad allegare lo screen shot le potete vedere.

[emanuc]

Ciao,
io ho cercato di installare Presonus Studio One 6 su ubuntu 22.04 senza wayland, ma non funziona perche' mancano delle dipendenze.
Se sono riuscito ad allegare lo screen shot le potete vedere.

Ti basta leggere sopra del perché non funziona e non riesci a installarlo sulla 22.04 LTS senza Wayland.

The Studio One 6.5 Linux beta explicitly supports Ubuntu 23.04 with Wayland only

[alderix]

Ti basta leggere sopra del perché non funziona e non riesci a installarlo sulla 22.04 LTS senza Wayland.

The Studio One 6.5 Linux beta explicitly supports Ubuntu 23.04 with Wayland only
[/quote]

Lo so, ho solo riportato la mia esperienza!
Aspettero' la 24 per vedere se funziona!

[Ferocious]

Sembra ancora immaturo.

https://www.debugpoint.com/gnome-drops-x-org/

Un commento a caso preso dal Gitlab di GNOME

No matter how much you wish for it, Wayland is simply not ready to replace Xorg for a lot of people. Not now, not anytime in the near future And by near I mean in the next 5 years. If you use AMD graphics and you live inside a terminal and use a web brrowser occasionally, then maybe you could get away with Wayland. But if you use Nvidia graphics or use creative apps, then Wayland is simply unsuitable and probably never will be unless something drastic changes.

[frapox]

Sembra ancora immaturo.

https://www.debugpoint.com/gnome-drops-x-org/

Un commento a caso preso dal Gitlab di GNOME

No matter how much you wish for it, Wayland is simply not ready to replace Xorg for a lot of people. Not now, not anytime in the near future And by near I mean in the next 5 years. If you use AMD graphics and you live inside a terminal and use a web brrowser occasionally, then maybe you could get away with Wayland. But if you use Nvidia graphics or use creative apps, then Wayland is simply unsuitable and probably never will be unless something drastic changes.

Wayland non è immaturo. Su Gnome è maturissimo, è il default dal 2016 mi pare.
Alcune implementazioni e alcuni driver non sono ancora maturi al 100% per Wayland, come i succitati nVidia, ma comunque i bug vengono eliminati di release in release, quindi è probabile che per quando Gnome deprecherà Xorg, i problemi saranno stati superati.

Poi ci sono hardware molto vecchi, che non hanno driver che supportano (bene) DRM/KMS, e anche questi danno problemi con Wayland. Ma anche qui non è un problema di Wayland in sé. Purtroppo (o per fortuna) Linux gira su un numero sterminato di sistemi e combinazioni hardware per cui riuscire a includere tutti col supporto non è facile. Diciamo comunque che qualsiasi GPU Intel/AMD uscita negli ultimi 10 anni supporta Wayland. Poi ci sarebbe tutto il capitolo embedded ma si va per le lunghe.

In ogni caso non c'è alternativa: Xorg è praticamente morto. Lo tengono in vita pochissimi sviluppatori solo con i fix. Ormai tutta l'attenzione è rivolta a Wayland e ai compositor che stanno implementando questo protocollo. Chi segue gli sviluppi da anni queste cose le sa e i commenti "a caso" lasciano il tempo che trovano.

[steff]

Cmq cerchiamo di stare in-topic che sarebbe non wayland in generale ma wayland fuori dal mondo gnome e plasma: labwc, hyprland, wayfire, sway o river o altro ancora.

[frapox]

Cmq cerchiamo di stare in-topic che sarebbe non wayland in generale ma wayland fuori dal mondo gnome e plasma: labwc, hyprland, wayfire, sway o river o altro ancora.

Putroppo dal titolo si equivoca facilmente l'intento del thread (anche se poi nel primo post è scritto, ma non tutti magari ci fanno caso).

Magari potresti cambiare il titolo mettendone uno che faccia capire il "problema".

[emanuc]

Notizia fresca fresca (finalmente): https://www.phoronix.com/news/Linux-Min ... d-Progress
Non ho letto quale compositor utilizeranno, forse: mutter > muffin?

[steff]

Sembra muffin ("rebased last year") https://trello.com/b/HHs01Pab/cinnamon-wayland

[frapox]

Sembra muffin ("rebased last year") https://trello.com/b/HHs01Pab/cinnamon-wayland

cioè, questi ogni tot anni "rifondano" la loro codebase forkando quella di Mutter e poi riscrivono le patch per renderla aderente ai loro scopi?

Ci credo che sono indietro anni luce, è uno spreco di energia e risorse allucinante, sopratutto per team di sviluppo piccolini.

Sembra facile "copiare" dagli altri, invece mi sa che se partivano da zero, o da un fork e poi rimanevano su quello, a quest'ora avevano già l'implementazione pronta.

Comunque Lefevre era quello che fino a un anno fa dichiarava che per Mate e Cinnamon non erano interessati a Wayland... chissà come mai recentemente deve avere cambiato idea.

[steff]

A proposito di sviluppo: sto usando labwc ormai da molto tempo e quello che invece salta agli occhi è il modo di sviluppo costante (da GH ~30 notifiche/gg) e direi anche molto professionale, con obiettivi chiari: https://github.com/labwc/labwc-scope
Capita spesso che un bug scoperto viene sistemato in un giorno, poi è clamoroso il tempo della sua compilazione, forse 15 secondi.