libGL funguje uz davno, pre Nvidiu je extension s ich proprietarnym driverom, mesu obsahuje rovno runtime, aktualne 18.0, co je novsia verzia ako maju niektore distribucie.
Problem bugu #1 flatpaku je, ze je v nespravnom repozitari, takze ho nikto nezatvoril.
Na flathube je flatpak pre Steam. Hry zo Steamu pod tym bezia ;)
Flatpak runtime pouziva vlastne verzie driverov, tie co su instalovane v systeme ani nevidi, kedze ma sandboxovany /.
Pri Nvidii je dolezite, aby kernel driver nebol novsi ako ten, co je vo flatpaku, co sa moze stat, ked user updatne jeden, ale nie druhy (nvidia driver pre flatpak je extension, ktora vychadza zhruba rovnako ako nvidia vydava svoje binarky). Pri AMD a Inteli som este nezaznamenal konflikt medzi kernel a userspace driverom.
Takze z pohledu *uzivatele* ... z niceho nic prestanou fungovat nektere aplikace. Pozdeji zjisti, ze ty instalovane pres flatpak, ktere pouzivaji libGL. Pak stravi pul dne debugovanim, aby zistil, ze se to stalo, protoze se mu zupdatovali drivery ke grafice v distru a doinstaluje si prislusnou verzi do flatpaku.
Jinymy slovy, ne, stale flatpak nefunguje s libGL.
Nedej boze kdyz nekdo vymeni treba amd grafiku za nvidii.
Je to dost skoda, protoze to neni tak davno co linux desktop fungoval celkem dobre.
Z pohladu pouzivatela to bude fungovat, bez toho, aby sa musel zaoberat nejakymi drivermi.
Aplikacia zabalena vo flatpaku je otestovana voci driverom, ktore si nesie runtime, nie voci nahodnej verzii, ktoru bude mat pouzivatel v systeme. Pre developerov je to dar z nebies, lebo vedia, voci comu maju testovat.
Ale kludne si opakujte co len chcete, akurat na rozdiel od vas su tu ludia, co maju s flatpakom prakticke skusenosti.
Co ty mas za problem, Flatpak ti prebral frajerku alebo co?
Pokial si pouzivatel nainstaluje hocico, co pouziva OpenGL a ma nvidiu, dotiahnu sa mu aj drivery k jeho karte. Ako budu pribudat verzie, budu sa mu dotahovat aj jednotlive verzie extensions. Svojho casu som Nvidiu mal a nebol najmensi problem.
Nehovoriac o tom, ze tento "problem" je len s Nvidiou. Majitelia AMD a Intelu su uplne vysmiati.
> Pre developerov je to dar z nebies, lebo vedia, voci comu maju testovat.
Tohle chapu. Taky-developer otestuje proti jedne verze runtime(s) a je z obliga. Ze to i pres to nebude fungovat je mu bud u zadku a nebo nema dostatecnou mozkovou kapacitu aby vubec dokazal pochopit jak to funguje.
Mimochodem, s dynamicky linkovanym libGL by to prave chodilo protoze budes ti bude sedet verze knihovny s verzi driveru v jadre.
> Ze to i pres to nebude fungovat je mu bud u zadku a nebo nema dostatecnou mozkovou kapacitu aby vubec dokazal pochopit jak to funguje.
> Mimochodem, s dynamicky linkovanym libGL by to prave chodilo protoze budes ti bude sedet verze knihovny s verzi driveru v jadre.
Toto moze napisat iba clovek, co nikdy neriesil obskurne bugy v implementacii OpenGL nahodneho vendora.
Tady má ale kolega anon2 pravdu. Fakt nevím, jaký důvod autoři flathub runtimů měli pro tento způsob integrace libGL. Používat systémovou libGL je IMHO bezpečnější než bundlovat devadesát verzí mesy či nvidia-utils a doufat, že to nebude s tím, co je náhodou nainstalováno v systému kolidovat. Protože ovladače hardwaru jsou v jádře, nikde není zaručeno, že nějaká aplikace s danou verzí mesy bude skutečně fungovat všude stejně, v případě nVidie bych to čekal ještě horší.
Flatpak je sandbox. On zo systemu nevidi nic, /usr namontovane do flatpaku je samostatna distribucia, napr. Freedesktop 1.6 je defacto Yocto.
Tym padom, ze zo systemu nevidi nic, nevie pouzit systemovu libGL.so, ktora by mohla byt linkovana s dalsimi systemovymi kniznicami, az by nakoniec zo sandboxu neostalo nic. Samotny ovladac pre OpenGL je v libGL, resp. v moduloch, co si libGL dolinkuje a s jadrom (nie, tam nie je ovladac, tam je iba cast, ktora alokuje pamat, robi presuny bufferov, a scheduluje command buffery) komunikuje cez /dev/dri resp. /dev/nvidia. Ano, pri nvidiach treba davat pozor na zhodu medzi jadrom a userlandom, a presne to riesia nvidiove extensions. Pri mese to problem nie je, pretoze jadro, mesa a libdrm maju samostatne release schedule a jedna cast nikdy nevie, s akou verziou druhej casti budu komunikovat v danej distribucii, preto maju komunikaciu medzi rozdielnymi verziami osetrenu.
V pripade, ze je naozaj treba specificka verzia mesy, tak sa to samozrejme da osetrit presne tym istym mechanizmom, ktory pouziva nvidia, ale zatial to nebolo potrebne pre software urceny koncovym pouzivatelom. Je to akurat fajn pre vyvojarov, aby skusili ine verzie, nez tie, ktore su v runtime.
pacon/gnome-software updatuje vsetky zdroje sw naraz, teda aj dnf/apt a flatpak. Pokial pouzivatel pojde do command line a updatne jedno a druhe nie, tak ano, urobi si problem kym ich neupdatne obe. Bezny BFU vsak toto robit nebude.
Pri zmene hw treba doinstalovat extension nvidie, a ano, je to vnimane ako user-unfriendly a predmet na zlepsenie.
Za tych par mesiacov, co som pouzival nvidiu, som nikdy nemal problem, ze by nvidia driver nebol zabaleny pre flatpak. Zvycajne byval o par hodin skor, ako rpm balik.
Sam moc dobre vis, ze updatovanim flatpaku a dnf/apt zaroveni nezaruci ze bude jak systemovym driver i runtime flatpaku ve stejne verzi.
To ze dokazes tvrdit, ze kdyz si nekdo sam pusti apt rucne, tak si za to, ze mu prestanou fungovat aplikace ve flatpaku, muze sam ... tim bych tu diskusi asi ukoncil.
Ale jste teda doudam, ze duvod proc si tech par mesicu nemel problem je jasny - ten driveru se proste neupdatoval. Vzdyt jsou toho plne "github issues" flatpaku jak s tim lidem zapasi.
Pretoze bezny user rucne apt nepusta. User, ktory vie rucne spustit apt, si vie dat pozor na rozlicne verzie.
Beznemu userovi raz za tyzden vybehne notifikacia, ze su k dispozicii nove verzie, casom na nu klikne (v pripade userov ktorych poznam, to trva dalsi tyzden), spusti sa mu Gnome Software alebo KDE Discovery a ma 99,999% sancu, ze verzie budu sediet.
A zase opakujem, ze je to zalezitost iba Nvidie, nie ostatnych, a to len preto, ze ich driver stack je pod takou licenciou akou je.
A samozrejme, ze som updatoval. Pretoze ked viem spustit v mojom pripade dnf, tak si viem pozriet, ake verzie kde mam. Nanestastie (alebo nastastie?) medzi rpm a flatpak nie su zavislosti, takze update jedneho nevie vynutit/zablokovat update druheho.