Debian Firefox flatpak finestra nera

[nick.rpm]

Salve, come al solito ero su Ubuntu ma poi sono passato a Debian Stable, non riesco proprio a prendermi il concetto di Canonical ma il motivo che ero su Ubuntu era perché Debian Stable mi dava problemi di YouTube facendomeli vedere in bassa risoluzione e sfocati i video e ho deciso di ritornarci e risolvere questo piccolo problema. Alla fine ho capito che non ero un problema di Debian in se ma di Firefox-esr anche se l'ultima installazione di Debian non mi faceva vedere Firefox in bassa risoluzione e sfocati i video ma perdeva fps, quindi non erano fluidi i video. Ho scaricato Firefox normale dal sito ufficiale di Mozilla, l'ho estratto e messo su la cartella opt e creato l'icona manualmente come dice le istruzioni sulla pagina wiki di Debian su Firefox.
Dopo ho deciso di provare con il Firefox flatpak. L'ho installato e attivato flatpak e poi ho installato Firefox in flatpak, ma se lo apro mi da solo una schermata nera e dopo qualche click per chiudere mi da l'avviso se voglio attendere o una chiusura forzata. Per vedere gli errori ho aperto Firefox flatpak con il terminale e l'immagini sono con Firefox flatpak aperto e dopo averlo chiuso. Sarà perché flatpak è ancora immaturo su Debian Stable? Anche con Spotify fa lo stessa cosa. L'unico software che ho provato in flatpak e che si apre senza problemi e Chromium e io ho sempre usato Firefox

 

[Moffetta88]

Scommetto che sei su wayland

 

[nick.rpm]

Scommetto che sei su wayland

Effettivamenti SI ma non ci avevo nemmeno pensato. Appena avere letto il tuo commento sono andato a fare una prova e si apre con xorg. Come mai su Wayland non si apre? Tra l'altro, Wayland è sempre stato inventato della Red Hat. Comunque usavo Wayand perché alcune distro se usavo xorg mi facceva effetti tearing sui video mentre su Debian in xorg non mi fa questo effetto.

 

[Moffetta88]

Wayland = disastro
Wayland + nvidia = catastrofe

Wayland purtroppo non è ancora ben maturo; può esser inventato pure da Dio in persona, ma rimane sempre un server grafico non ancora pronto per i giorni d'oggi; o meglio, gli sviluppatori non hanno ancora imparato ad abbandonare xorg

 

[nick.rpm]

Wayland = disastro
Wayland + nvidia = catastrofe

Wayland purtroppo non è ancora ben maturo; può esser inventato pure da Dio in persona, ma rimane sempre un server grafico non ancora pronto per i giorni d'oggi; o meglio, gli sviluppatori non hanno ancora imparato ad abbandonare xorg

L'unica cosa che sapevo era di non usare i driver proprietari ma pure io stesso voglio usare i driver open-sources (nouveau) tanto che non li installarò lo stesso anche usando adesso xorg

 

[EmanueleC]

Se hai i driver closed devi fare un update di flatpak per aggiornare le estensioni nvidia su flatpak, se hai nouveau è quello il problema.

Post unito automaticamente: 2 Marzo 2023

Wayland = disastro
Wayland + nvidia = catastrofe

Wayland purtroppo non è ancora ben maturo; può esser inventato pure da Dio in persona, ma rimane sempre un server grafico non ancora pronto per i giorni d'oggi; o meglio, gli sviluppatori non hanno ancora imparato ad abbandonare xorg

No, Wayland è pronto e funziona quasi ovunque, l'unico problema è con i driver nvidia closed legacy, quindi se hai una GPU vecchia che ti costringe a usare quei driver devi per forza usare Xorg. Per il resto Wayland ad oggi ha raggiunto le funzionalità di Xog e più.
Ad esempio su xorg non puoi avere una scala frazionaria su schermi diversi, nessun hdr (in arrivo), meno efficiente e tearing a go go.

 

[BrutPitt]

No, Wayland è pronto e funziona quasi ovunque, l'unico problema è con i driver nvidia closed legacy, quindi se hai una GPU vecchia che ti costringe a usare quei driver devi per forza usare Xorg. Per il resto Wayland ad oggi ha raggiunto le funzionalità di Xog e più.

In realta' non e' proprio cosi': i problemi esistono anche con i recentissimi closed driver 530.30 di NVidia e sono "palesemente" conclamati e descritti:

Appendix L. Wayland Known Issues

download.nvidia.com

Nel senso che esistono incompatibilita' in alcune metodologie, da entrambe le parti... e quei programmi che anche "inconsapevolmente" le utilizzano (magari appoggiandosi ad API con "livello di astrazione") possono incorrere in problematiche.
Uno dei maggiori problemi, descritti in quel documento, e' la mancanza di un meccanismo per sincronizzare il rendering con quello di "presentazione" dei driver.
La "presentazione" avviene quando devo "presentare in area visibile" (visualizzare) il contenuto di un buffer utilizzato per la composizione del rendering.

P.S.
Personalmente, con la RTX 3080, per me l'utilizzo di KDE Plasma, via Wayland, su Fedora 37 e' praticamente impossibile: il desktop freeza dopo circa 30/40 secondi dal login... ed anche questo e' un problema diffuso.
Diversa cosa con Gnome: Wayland funziona ... ma alcune applicazioni, che usano API grafiche, hanno dei comportamenti anomali.
Parliamo ovviamente sempre di drivers NVidia.

 

[bigendian]

Io sono su wayland da parecchio senza alcun tipo di problema. Funziona tutto perfettamente, ma naturalmente, sono su radeon. :) La domanda e', perche' insistere con quelle maledette schede nvidia, sporcare il sistema con driver proprietari ?

 

[BrutPitt]

Io sono su wayland da parecchio senza alcun tipo di problema. Funziona tutto perfettamente, ma naturalmente, sono su radeon. :)

Se sviluppi applicazioni che fanno uso di API grafiche o GPU Computing, sei "obbligato" ad avere entrambe le architetture: cosi' ho 2 computer identici, con la differenziazione della sola GPU (AMD/NVidia)... e non ho problemi ad usare Wayland con l'RX 6700.

La domanda e', perche' insistere con quelle maledette schede nvidia, sporcare il sistema con driver proprietari ?

Mio malgrado, pero', gli strumenti di debug NVidia per API grafiche e GPU Computing (e.g. nsight) sono una spanna sopra quelli AMD... e funzionano SOLO con i drivers proprietari (anzi solo con "determinate versioni" dei drivers prorietari: e.g. nsight v.2023.1 solo con i 530.30 and above)... senza contare che molte librerie in questo campo, anche opensource e portabili, sono sviluppate e mantenute sempre da NVidia... come altre cose su cui non mi dilungo... quindi e' giocoforza sviluppare su NVidia e poi verificare la trasversalita' su AMD.

Ma questo discorso vale/varrebbe anche con Windows.

L'ho scritto piu' volte su queste pagine: purtroppo AMD ha compreso tardi che avrebbe dovuto investire molto "anche" su ricerca e sviluppo software... e sebbene negli ultimi 5/6 anni abbia fatto tanto lato sviluppatori, prima di allora c'era praticamente il deserto.
Di contro sono iscritto all'NVidia Developer Program sin dal 2007... che esisteva gia' da qualche anno.
In definitiva cio' che mettono oggi a disposizione degli sviluppatori, le due aziende, e' comunque ancora molto squilibrato... molto, ma molto, ma molto piu' squilibrato del divario che oggi c'e' tra le due architetture hardware (4090 vs 7900xtx... RTX compreso).

Poi se volessimo fare polemica sulle motivazioni per cui NVidia mantiene "closed" i propri drivers... potremmo anche farla, ma sappi che sono assolutamente a favore dell'open-source: I drivers AMD ne hanno guadagnato!
Pero' fintanto che i driver NVidia rimarranno closed dovro' per forza di cose utilizzarli... e rimarranno anche piu' performanti rispetto ai nouveau (almeno sulle GPU di ultima/e generazione/i).

 

[bigendian]

Mio malgrado, pero', gli strumenti di debug NVidia per API grafiche e GPU Computing (e.g. nsight) sono una spanna sopra quelli AMD... e funzionano SOLO con i drivers proprietari (anzi solo con "determinate versioni" dei drivers prorietari: e.g. nsight v.2023.1 solo con i 530.30 and above)... senza contare che molte librerie in questo campo, anche opensource e portabili, sono sviluppate e mantenute sempre da NVidia... come altre cose su cui non mi dilungo... quindi e' giocoforza sviluppare su NVidia e poi verificare la trasversalita' su AMD.

Le tecnologia Nvidia certo e' apprezzabile, piu che rispettabile, ma non il suo contributo all'opensource.

Anche Microsoft aveva un grosso regno culturale, didattico e di sviluppo negli anni 2000, licenze, corsi,.NET e ActiveX e boiate varie. Il tempo non le ha dato ragione, direi.

In realta', a parte te e pochi altri che ne beneficiano per scopi di sviluppo grafico, ed hanno le conoscenze per farlo, sappiamo bene che molti altri le vogliono per giocare. O magari peche le montava un PC a buon prezzo, e il giorno dopo frignano perche su linux non funziona bene con i driver originali, e devono obbligatoriamente sporcare il sistema con i driver closed.

Non sono un giocatore, sono fuori dal mondo dei giochi, non so se i giochi o il mining siano il traino della moda nvidia, lo suppongo, ma immagino che su Linux ci si possa accontentare di tanti bellissimi giochi anche con radeon. Da vent'anni non metto piu mano a roba Microsoft, ne per lavoro ne per passione, proprio per scelta etica, e stando in Linux sto bene attento a comprare sempre radeon.

Si insomma, scusate, sara' che come contributor al kernel linux, l'idea di sporcare il sitema con roba closed mi disturba. Per chi sviluppa, come me, ad esempio maggiormente in C e C++, su driver e accessi basso livello, o su qualsiasi task non grafico, una amd va comunque benone, e ad ogni installazione funziona tutto out of the box, anche in wayland. Per chi non sviluppa software, e si limita a giocare con email fb e navigare, una radeon va lo stesso bene.

 

[nick.rpm]

Ho fatto una prova per capire se il problema fosse il mio computer, qualche pacchetto installato o se era Debian stessa il problema. Io ho installato Debian Stable su una macchina virtuale (ovviamente VirtualBox) ho solo installato le guest additions e poi ho installato e attivato i flatpak e poi installato prima Spotify flatpak e funziona, poi Firefox flatpak e senza comandi di troppo funziona pure su Wayland!

 

[EmanueleC]

Personalmente, con la RTX 3080, per me l'utilizzo di KDE Plasma, via Wayland, su Fedora 37 e' praticamente impossibile: il desktop freeza dopo circa 30/40 secondi dal login... ed anche questo e' un problema diffuso.
Diversa cosa con Gnome: Wayland funziona ... ma alcune applicazioni, che usano API grafiche, hanno dei comportamenti anomali.

Se funziona meglio su GNOME shell è perché su GNOME hanno iniziato prima con il supporto a Wayland, si sa che sono leggermente più avanti con mutter, il resto dei bugfix di plasma su wayland saranno su kde plasma 6 (qt6): https://community.kde.org/Plasma/Wayland_Showstoppers
Ed è anche vero che molte APP non hanno il supporto a Wayland, ma qui non c'entra la maturità di Wayland.
Ed è anche vero che con NVIDIA closed ci sono problemi, credo che qui non c'entra con la maturità di Wayland ma il problema è NVIDIA.
Ad esempio Valve ha in commercio lo steamdeck e il suo compositore si basa su Wayland in modalità non desktop, con chiari vantaggi sul loro precedente compositore basato su Xorg.

emersion_fr
·2 anni fa

I initially expected it'd be running like that because it makes sense in a device intended primarily for gaming, but was a bit confused as the ability to be nested is one of the features gained over steamcompmgr.
Running under Xorg doesn't allow steamcompmgr to take advantage of the hardware features. So yeah, there are multiple upsides to switching to gamescope. ;)
Now I'm wondering if using dual Wayland compositors will become common for gamers on other Linux distributions.
Hopefully regular Wayland compositors will be improved and become as good as gamescope to run games. Having a gaming session is good for something like Steam Deck or a dedicated gaming box, but for regular desktop use-cases switching between compositors before starting a game a a bit of a hassle.

 

[nick.rpm]

Ho fatto una prova per capire più approfondamente. Ho aggiornato Debian Stable alla testing e infatti sulla testing su Wayland si apre tutte le applicazioni flatpak, quindi sarà che qualcosa come i driver open-sources (nouveau) o dei pacchetti sono poco maturi. Io dopo sono ritornato sulla Stable perché mi piace ogni lato di Debian ma ho scelto Debian anche per la sua stabilità che come già spiegato ne avrò bisogno tra poco. Tanto è iniziata la prima fase dei freeze dei pacchetti quindi tra non molti mesi uscirà Debian 12 Bookworm Stable, basta avere un pò di pazienza!

 

[Mario Niola]

Sembra che le GTK abbiano sovrascritto alcune risposte di mesa-gl.
Bisogna capire se questo problema è solo su Wayland o anche su Xorg.
Se lo fa anche su Xorg è un problema del programma (ma non credo).
Se lo fa solo su Wayland, allora c'è qualcosa che non va nell'implementazione di gtl_wayland_egl.cpp e quella roba lì, insomma... (quindi è sempre un problema di implementazione del programma su Wayland).

Il messaggio GRAVISSIMO è quello relativo al fail glxtest: no supported VAAPI profile found.
In pratica non avrai accellerazione hardware per i video Youtube (formato vp9, mp4, ecc...)

Pare che qui abbiano risolto.

Se i test glx non sono ottimali, avrai sempre problemi grafici è il sistema grafico non sarà mai completamente stabile.