Wayland vs. X11

HUP cikkturkáló

Valaki vette a fáradságot, és összehasonlította a kettőt, konkrét mérési eredményeket produkálva.
Plasma 6.4 Wayland vs X11 desktop performance numbers
Plasma 6.4 Wayland vs X11, processor and power benchmarks

A számok önmagukért beszélnek. Kíváncsi lennék, van-e olyan lelkes HUPos fórumtárs, aki megismételné (vagy csak akár hasonló méréseket végezne) és megosztaná velünk az eredményt. Érdekes lenne látni, hogy korrelál-e.

  • 2799 megtekintés

( kikadff v | 2025. 07. 12., szo – 14:49 )

Nem lepődtem meg. Arra mondjuk nincs infó #FIXME, hogy az X11 alatt be van-e kapcsolva nála a compositing, azt hiszem Plasma alatt ez állítható. Ha nincs akkor az eredmény egyértelmű, de ez is egy plussz az X11 mellett, hogy képes erre. Ha viszont be van, akkor ledőlt egy mítosz.

Benne van, legalábbis szerepel egy ilyen mondat:

You also won't believe me, but the CPU also ticked lower in the X11 session than in the Wayland one. Imagine what happens when you turn compositing off in X11.

(ps: szerintem nem meglepő, én pont hogy arra számítanék, hogy compositor-ral kevesebb a CPU, lévén csak buffereket kell másolni a szerveren belül, ahelyett, hogy Expose eventre lefutna kliens oldalon egy csomó kód, protkollkonverzió, IPC, stb. aztán meg szerver oldalon egy csomó rendelelő eljárás. Ha meg be van kapcsolva a double buffering, akkor kb. ugyanott vagyunk sebesség ügyileg, mint compositor-nál.)

( asch v | 2025. 07. 12., szo – 15:13 )

Régebben Wayland párti voltam, de amióta a nagy cégek ki akarják golyózni az X11-nek a lehetőségét is, azóta X párti lettem brahiból.

( azbest | 2025. 07. 12., szo – 15:44 )

Hasznosnak tűnik.

Ha csak ilyen kicsi a különbség a modernebb megoldásnál, akkor nekem tetszik. Főleg, mert ha jól értem, sokkal nagyobb effort a gpu gyártóknak x11 drivert készíteni, mint wayland alatt működésre bírni őket. Ha nem tévedek, akkor x11-hez a zárt driver is x11 specifikus kell legyen, míg waylandhoz talán opengl driver elegendő, amit meg szoktak csinálni a gyártók. És az nvidia-amd-intel trió mellett az armos soc-okban gyakori gpu-kra gondolok főleg. 

Ha csak ilyen kicsi a különbség a modernebb megoldásnál,

Nem, ez csak az idle. Ha megküldöd, a különbség drasztikusan nőni fog az X11 javára, erre fel is hívja a figyelmet: And remember, the more load you induce on the system, the bigger and more meaningful the deltas are.

ha jól értem, sokkal nagyobb effort a gpu gyártóknak x11 drivert készíteni, mint wayland alatt működésre bírni őket

Rosszul érted, nincs különbség driver ügyileg, az más réteg, ugyanazt használják.

Mind az X11, mind a Wayland Mesa API-s (vagy újabban Vulkan) driverek tetején csücsülnek, kis kernel oldali DRM támogatással, azaz pontosan ugyanaz a driver mindkét esetben. (Régesrég elmúltak már azok az idők, amikor külön X11 driverre volt szükség.)

Akkor valami fejlődés volt ezek szerint. 

Viszont akkor nem értem, hogy miért nincs sokkal jobb hw gyorsított független x11 megoldás a gyártói zárt opengl-re támaszkodva.

Bár van ahol azt írják a 2d-hez még mindig kell custom kód, a 3d -hez van már függetlenebb. 2d-nél a GLAMOR egy próbálkozás, ahogy olvasom.

Amúgy valsz ez a legnagyobb baja a desktop linux terjedésének, hogy nincs egy közponi akarat, ami kiválaszt egyet, amit rendesen megcsinálnának, hanem sok kis csoport kakaskodik a saját szemétdombján és a végén mégis a zárt driveres megoldások nyernek. A nagy szabnadságban két szék közé ülés esete.

Persze lehet tévedek és már armos linuxokon sem szaggat a kép és 100% a cpu, ha böngészőben görgetnek.

>  Főleg, mert ha jól értem, sokkal nagyobb effort a gpu gyártóknak x11 drivert készíteni, mint wayland alatt működésre bírni őket.

Jaj, szegények, meg ne sajnáljam őket azért az árért, amiért a kártyákat árulják.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ja, ez a kijelentés, amit idéztél, egy az egyben nem igaz. Igen, nehéz volt a GPU gyártóknak az x11 drivert elkészíteni. Először. Azóta viszont minden kártyához ugyanazt a kódot használják, némi if then szerkezetes különbséget, meg plusz 1-1 feature-t hozzáadnak, de nem kell mindig minden kártyához elölről írni a drivert. Másrészt meg az x11 driver komplexitásban messze elmarad a mesa, vulkan, stb. driverekhez képest.

És mikor írom, hogy a gyártóknak az első alkalom nehéz volt, ott a múlt idő húzandó alá, és hozzá kell tenni, hogy ez már minden gyártónál kész. Mindenhez van már x11 driver, csak karban kéne tartani, és nem kéne lusta disznónak lenni, meg a Wayland javára mesterségesen elavultatni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az intel/amd/nvidia gpu-kra gondoltál csak, vagy a Mali/Immortalis, Adreno, PowerVr, Vivante és más gpu-ra is.

Korábban az volt a helyzet, hogy sokmindenhez volt androidra hw gyorsítás, így az opengl(es) driver megvolt egy adott kernelhez. De x11 alatt nem lehetett őket használni. Csak buta cpu-ból rajzolt 2d grafika volt, mégha mellette volt hardveresen gyorsított videó dekódolás vagy ablakon belüli 3d, de maga a 2d ui az nem volt gyorsított x11 alatt, mert nem volt hozzá driver (csak fbdev, fastfb?). 

Ráadásul a kernel változik és a kókány megoldásoknak régi kerenelen kell maradniuk, mert nincs újabb driver.
Az opengl(es) drivert úgy ahogy megírják, mert azzal lesz használható a set-top-boxokban és a telefonokban a soc-juk. DE x11-hez nem csinálnak drivert. Talán újabb malikat már az arm fejleszti hivatalos kernelbe is. Azon dolgoznak, amiért pénzt kapnak.

Azért egy videókártya drivernek a nagy része a hardverrel való kommunikáció. Ha OpenGL-re megírták, elég nagy tétekben fogadok, hogy nem lett volna nagy meló X11 alá is illeszteni, csak ahogy a nagymamám mondogatta annak idején, "nem akarásnak nyögés a vége".

> Az opengl(es) drivert úgy ahogy megírják, mert azzal lesz használható a set-top-boxokban és a telefonokban a soc-juk.

Én azt nem látom magam előtt, hogy ha az X11-nél leszarták a frissítést, mi a garancia arra, hogy az OpenGL-t nem fogják leszarni egy ponton. Maga az OGL szabvány is fejlődik az igények függvényében, simán lehet, hogy egy ponton úgy döntenek, hogy ők bizony nem hoznak újabb drivert, a set-top-boxok maradnak a régi Waylandon, mert ez a gyártónak kényelmesebb.

És ebben valójában semmi új nem lenne. Nem csak a videókártya driver írók lusta disznók. Simán voltak olyan eszközök/cuccok bőven a 2.6-os kernel éra végén, amik kizárólag 2.4-es kernelre jöttek ki, és valami ősi oprendszert kellett oktrojálnod, amin megszólalt a hardver.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Raynes v | 2025. 07. 12., szo – 20:27 )

Nem, nem ismétlem meg, mert egy kétes, szar mérésnek tartom a radeontopjával együtt. Én a tapasztalataim írnám meg: régi, gyengébb procis gépeken (2 mag, 4 szál, alacsony órajel, ótvar régi Intel iGPU), 60Hz-es kijelzőn, nálam a Wayland pattogósabbnak tűnt, de nem ez a KDE-s, meg Gnome-os basz, hanem SwayWM alatt néztem, ami jóval minimalistább. Persze csak akkor pattogósabb, ha agresszívan görgetek, meg rángatom az ablakokat, szóval nem életszerű felhasználás, de ott kicsit folyékonyabbnak tűnt, mint a kompozitor nélküli, xorg.conf tearfree beállításos i3wm, suckless dwm.

A mostani gépeimen, nem túl szar, de régebbi Radeon integrált és dedikált GPU (680M, RX570, de volt előtte egy Vega7 is), jobb Ryzen proci (6 mag 12 szál, 8 mag 8 szál, 8 mag 16 szál, 4-5 GHz közeli órajel) felállásban, 60-74-144Hz-es kijelzőkön viszont semmi különbséget nem érzek egy Sway vs. i3, vagy Sway vs. bpswm között. Görgethetek akármilyen vadul, rángathatom az ablakokat, kapcsolgathatok agresszíven a virtuális asztalok között, minden olyan sima és gyors, lagmentes, hogy nem érzékelhető semmi különbség. Játékok futásánál sem érezhető a különbség, videókba való agresszív beletekerésekkor, átpozicionáláskor se.

Memóriafoglalásban sem volt nagy különbség. Igen, a Sway többet fogyasztott, miután beleszámoltuk az XWayland-et is, de csak ilyen 20-30 mega különbség, ha volt, akkor sokat mondok, és még ennyi különbség se lett volna, ha i3wm-en bekapcsolok egy kompozitort is. Egy Hyperland már vaskosabb, egy Gnome/KDE meg sokkal bloatabb, bár az utolsó kettőnél meg az X-es számokat nem tudom.

Összességében: szerintem is az X-nek kevesebb erőforrás kell, de olyan kicsi a különbség a javára, hogy szőrszálhasogatás vele foglalkozni, még egy olyan minimalistának is, mint én. Legfeljebb annak éri meg, akinek nagyon szar, muzeális gépe van, de ott is célszerű kísérletezni mindkettővel, Wayland-et is bepróbálni. Ami miatt én továbbra is X-et használok
1) több érdekes, és nagyon minimalista WM van rá
2) saját WM-et akarok írni, és az X-re könnyebb
3) hordozhatóan akarom tartani a konfigom, hogy működjön BSD-ken is.

Így én nem vagyok ellene a Waylandnek, ha valamelyik gépen jobban fut, akár még használnám is. Az se baj, ha ezt tolják a disztrók, meg a Red Hat, nekem az a bajom, hogy ezzel párhuzamosan az X.org-ot ne akarják még elavultatni. Túl korai még, meg az XWaylandet úgyis kell fejleszteniük, az meg lényegében egy lecsupaszított X.org, akkor már miért ne backportolják a fejlesztéseket a jövőben is X.org-ra. Ezt a mesterséges elavultatást nem akarom. Legyen szabad választás. Ez a Linux, Unix filozófiai lényege, modularitás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem pontosan emlékszem, olyan 140 MB körül mutatott akkoriban, míg az i3-nál a X.org 90 körül, az i3wm már nem is tudom mennyit, 10-15 MB körül, a többi körítés kb. azonos volt, panel, háttérképkezelő, lock, stb.. Az alap programjaim nekem is mentek Wayland natívban (Alacritty, imv, , de mindig volt pár kiegészítő alkalmazás, ami nem, pl. GIMP, Steam, játékok, stb., így azoknak kellett az XWayland, és nem lett volna realisztikus kihagyni az összehasonlításból. Másik oldalról, ha futtattam volna az i3wm-hez Picom-ot, az visszaegyenlítette volna egálba. Tisztában vagyok vele, hogy mostanság a Sway vaskosabb lett, talán már nem áll meg 200 mega alatt. De most már a X.org is hízott azóta, főleg a GPU driverek miatt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( hrgy84 | 2025. 07. 12., szo – 21:21 )

Én nem vagyok ellene a Waylandnek, csak hagyják meg nekem a kis X11-es környezetemet, ahol nyugodtan dolgozthatok, amíg ők tákolják az új hype csodát. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Pontosan, így, ahogy mondod. Engem még az se zavar, hogy a disztrók Wayland default-ot szállítanak, meg a Wayland kapja fejlesztésnél már a nagyobb prioritást, az gyorsabban kap meg új feature-öket, és az X-re kevesebb erőforrás marad, lassabban fejlődik, némileg hanyagolt. De akinek működik, és rajta van, annak ne üssék ki a kezéből, mert már nem menő.

Ráadásul az a veszélyes, hogy több oldalról is el akarják avultatni. Egyrészt a disztrók, akik egyre inkább dobják, az RHEL már odáig ment, hogy a tárolókban sincs benne az X. A másik elavultatási pont, hogy a Gtk5, Qt7 állítólag már csak Wayland only lesz.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

az én olvasatomban egy lelkes, de nem túl hasznos jóember teleszórta kódszépítő, gyakran hibás patchekkel a rewiew folyamat, hogy megsértődött, mert rászóltak, hogy hagyja már abba a commit farmolást. Majd a dei és anti dei divat hullámot megpróbálva meglovagolni, ő egyéniség lett.

És azért ő volt a legaktívabb, mert kevesen foglalkoznak már az X-szel.

És azért ő volt a legaktívabb, mert kevesen foglalkoznak már az X-szel.

Ez így ebben a formában nem igaz.

Szerintem az Xorg-ban alapvetően azért kevés a commit, mert hát jól és stabilan működik, és ami működik, azt minek megjavítani ugye. Hogy a srác kb. 3000 commitja ér-e valamit, az meg hamarosan elválik, ha kijön az XLibre és konkrét méréseket és összehasonlítást lehet majd végezni vele. Puding próbája az evés.

( bzt | 2025. 07. 13., v – 12:28 )

Szerkesztve: 2025. 07. 13., v – 12:47

Szerintem itt páran elfelejtitek, hogy az X11-et újraírták, és már nem az XFee86 implementációt használják, hanem az Xorg-ot. Ég és föld a kettő, amiket írtok, az csak az XFee86-ra volt igaz, az Xorg-ra nem.

Ezt a driveres problémát továbbra se értem. Kb. 20 éve volt, hogy utoljára külön X11 driverre volt szükség. Amióta a Compiz miatt általánosan elterjedt lett a GLX_EXT_texture_from_pixmap XFree86 extension, azóta egyáltalán nem kellett (ez egy olyan API, ami az X11-es pixelképet átadja a GPU-nak textúraként, és onnantól a szabványos 3D-s driver (Mesa vagy Vulkan) jeleníti meg az X11 session-t is.) Ez 2006-2007 óta megy, mint az ágybaszarás, az Xorg alatt meg már nem is extension, hanem alap, és csak simán a libmesa vagy libvulkan API-t használja. Amióta Xorg-ra váltottak a distrók, sosem kellett külön X11 drivert telepítenem. Egyetlen egyszer sem, sem nvidia, sem amd, sem semmi más esetén.

Túl sok arm-os alaplappal nem foglalkoztam, de azokhoz mind volt hardveres X11 gyorsítás, de ha esetleg nem lenne, akkor meg úgyis a durván SIMD optimalizált pixman-t használja az Xorg, ami rohadt gyors még egy lassú vason is a párhuzamosítás miatt. Itt max azt tudom elképzelni, hogy csak azokkal az ősrégi arm procikkal lehet gond, amikben még nincs NEON (ARMv8 előtti), mert a pixman sima SIMD optimalizált kódja nem az igazi, inkább az újabb NEON kódra feküdtek rá.

A görgetés lassúságának az égvilágon semmi köze az X11-hez vagy a compositor-hoz. Ha lassú a görgetés, akkor az alkalmazás nincs optimalizálva, ami tök független attól, mennyire gyors az ablakkompozíció. Gyk: lehet lassú a görgetés akkor is, ha hardveresen gyorsított a 2D és úgy pattog a session frissítés, mint plébános farkán a ministránsfiú.

Személyes tapasztalatom a Wayland-del, hogy egy bugos fos, gyakorlatilag képtelenség fejleszteni rá:
- a toolchainje agyrém és bugos (SDL alatt hol megy, hol nem),
- az API-ját meg kéthetente eltörik (próbáljátok csak meg lefordítani a hello world-öt, vagy akár a frissített XDG alapú változatot)
- alapvető funkciók hiányoznak belőle (pl. nem kezel font-okat, azaz MINDEN alkalmazásba külön le kell fejleszteni még a szövegkiírást is)
- nem tud másik gépre ablakot küldeni
- iszonyatos dependency igénye van, mind fordítás-, mind futásidejű
- dbus daemon nélkül gyakorlatilag meg se nyikkan már
- szinte kizárólag akkor használható csak, ha van egy plusz bloated réteg felette, pl. KDE vagy GNOME, egyébként esélyed sincs natívban használni a fentiek miatt
- ...stb.

Szóval itt ez a félkész bugos valami, ami az X11 funkcióinak tizedét sem tudja, de cserébe sokkal több erőforrást zabál és irdatlan dependency hell-je van még futás időben is. Ez ám a fejlődés!

Hát az remek, nem is értem mit bénáztak 12 évig a raspbery pikkel, hogy működjön teljes képernyős grafikus felületes ablakban a folyamatos videolejátszás mindenféle hekk és custom kód nélkül, simán egy böngészőből. 

A görgetésnél lehet nem szó szerint a sebességére gondolt, hanem arra, hogy kevés fps-sel frissül a tartalom és ezért darabos a mozgása. Az pedig erősen összefügg azzal, hogy működik-e hw gyorsítás a kirajzolásnál.

Ha develop branchről fordítgatsz magadnak játszóteret, akkor nem csoda, ha rendszeresen találkozol hibákkal.

A panaszaid meg valsz abból jönnek, hogy ez nem x11 és pont amiért nem akar x11 lenni, azt fájlalod. Hogy máshogy bontották szét a feladatokat, hogy jobb legyen. Te meg fájlalod, hogy ablakkezelő nélkül meg kell valósítani valamit, amit amúgy nem kell, mert ablakkezelő nélkül csak nagyon speciális esetben használják.

nem is értem mit bénáztak 12 évig a raspbery pikkel, hogy működjön teljes képernyős grafikus felületes ablakban a folyamatos videolejátszás

Látod, csupa hülyeségeket beszélsz. Sorolom, a teljesség igénye nélkül:
- "teljes képernyős": nincs is composition ez esetben! Sem X11, sem Wayland esetén!
- "grafikus felületes": minden videólejátszáshoz pixelbuffer kell, és a modern harverek nem is tudnak mást! Igen, az RPi-n nem is létezik nem "grafikus felület".
- "folyamatos videólejátszás": ez megint nem a felület kérdése, hanem elsősorban a dekóderé!

Magyarán amiket felsoroltál, azoknak SEMMI KÖZE a felhasználói felülethez, lett légyen Wayland vagy X11. Az meg, hogy "hekk és custom kód" kell RPi-n azért van, mert az ARM prociban nincs elég kraft a modern videók dekódolásához, ezért ezt proprietary chip végzi, amihez meg nyilván nem adtak ki FOSS drivert soha (de ennek sincs köze sem a Waylandhez, sem az X11hez, de még csak a VideoCore GPUkhoz sem).

A görgetésnél lehet nem szó szerint a sebességére gondolt, hanem arra, hogy kevés fps-sel frissül a tartalom és ezért darabos a mozgása.

Újfent hülyeségeket írsz, mert ha a videólejátszás megy (azaz megvan a kellő fps), attól még mindig lehet darabos a görgetés. Ha tényleg fps probléma lenne, akkor MINDEN akadozna, nemcsak a görgetés, és a raw videólejátszás sem működne.
Egyébként meg, "fps == szó szerinti sebesség" (ha nem tudnád, fps = frame per second, azaz kigenerált képkockák száma másodpercenként!)

Az pedig erősen összefügg azzal, hogy működik-e hw gyorsítás a kirajzolásnál.

Ez is hülyeség. Próbáld csak ki, futtass egy pixman példaproggit, ami megméri az fps-t a RPi-den. Lássuk, mennyi fps-t hoz ki hw gyorsítás nélkül, csupán csak NEON SIMD optimalizációval! (Én kipróbáltam anno még Rpi3-al, bőven meghaladta a 30 fps-t, tehát NEM emiatt darabos a görgetés, elárulom)

Ha develop branchről fordítgatsz magadnak játszóteret, akkor nem csoda, ha rendszeresen találkozol hibákkal.

Ha nem tudod, miről beszélsz, akkor nem csoda, hogy egyfolytában hülyeségeket irogatsz. (Csak a teljesség kedvéért, nem developer branchről van szó.)

A panaszaid meg valsz abból jönnek, hogy ez nem x11 és pont amiért nem akar x11 lenni, azt fájlalod.

:FACEPALM: Tanulj meg olvasni.

hogy ablakkezelő nélkül meg kell valósítani valamit, amit amúgy nem kell, mert ablakkezelő nélkül csak nagyon speciális esetben használják.

:FACEPALM: Hogy írhat ekkora baromságot valaki? A fontrenderelés nem is a Westonban (ablakkezelő) történik, hanem a Cairoban (GNOME függvénykönyvtár) Wayland alatt.

Csupa-csupa hülyeségeket írsz.

x11 alatt memóriába rakta ki a hw dekóder által előállított képkockát, de cpu erővel kellett kiraknia azt a megjelenítéshez. A cpu ereje valóban kevés volt ahhoz, hogy fullhd esetén valós időben képes legyen minden pixelt így kirakni 30-60 fps-sel. 
Viszont nem x11 használatával, hanem közvetlen opengl-es rendereléssel vidáman képes volt képkockavesztés nélkül lejátszani ugyanazokat a videókat (például kodi-val), mert az textúrába tölti a képkockát és képes gpu erőből hw gyorsítással kirajzolni a proci különösebb terhelése nélkül. 
Ehhez hasonló az is, amikor overlay-t használnak, egy helyettesítő színnel kitöltött téglalapot rajzoltatnak ki csak és a gpu-nak mondják meg, hogy a képkockát tegye ki a megadott koordinátákra. Ilyet használt például a korábbi verziókon az omxplayer. Ezeket tudta már a legelső rapsberry pi is, ami igencsak soványka cpu erővel rendelkezett. X11-et kihagyva képes volt fhd videó lejátszásra hw dekódolással, vicces módon a némelyik (hd) hang codec szoftveres dekódolása volt ami sok volt neki. Omxplayerrel képes volt 1 fullhd vagy akár 4 sd videó megjelenítésére is (utóübbi hang nélkül az 1 magos procival). X11 felett egyre sem.
https://www.youtube.com/watch?v=tLxiXDkzFo0

A hardveres video dekódolást már jóideje megoldották az aktuális raspbian rendszerükön anno, ami x11 alatt is működött hozzá módosított vlc és chromium böngégszőjükkel. De a teljes képernyőre kirakva még sokáig nem tudta gpu segítségével kirajzolni x11.-gyel. Persze volt olyan program, ami kikerülte az x11-et és közvetlenül opengl-es-sel rakott ki videót, úgy működött, de ahhoz nem sok közve volt a desktopnak.

Aztán ahogy a broadcommal együttműködve ők is csináltak wrapper drivert, ami a zárt blobokat elfedte olyan általános apival, amit már használhattak más opensource programok is, akkor jött az, hogy a fastfb helyett fake kms, majd full kms is lett az újabb piken.

Ja nem fastfb, hanem fbturbo a neve annak az fbdev változatnak, amit sokáig használtak. 
https://github.com/ssvb/xf86-video-fbturbo

Emlékeim szerint a fake kms már 3d gyorsításban segített, de 2d-ben még mindig gyötrelmes volt és külön broadcomhoz hekkelt megoldást használtak.
https://news.ycombinator.com/item?id=31146145

De már akkoriban elengedtem bármilyen desktop használatra a piket, mert mindig volt valami gond a grafikus felületes használattal, teljesítménnyel.
A legújabb pi5ökön waylanddel nem próbóbáltam, hogy sikerült-e használhatóvá tenni. Lehet ott már az x11 is jobb. Mivel ár-érték és kompatibilitás terén sajnos nem versenyképesek az armos megoldások, így intel/amd minipécékre váltottam, csak headless feladatokra használom az arm boardjaimat.

Én nem tudom, hogy mi a bánatod a fontokkal és azzal, hogy neked minden programban meg kell valósítanod a szöveg kiiratást. Valamit valsz rosszul csinálsz.

Lehet, hogy hülyeséget beszélek, mert mostanában nem foglalkoztam x11 -gyel. Viszont nekem nagyon úgy tűnik, hogy sok hülyeséget összehordasz te is.

Teljes hülyeségeket beszélsz.

mert az textúrába tölti a képkockát és képes gpu erőből hw gyorsítással kirajzolni a proci különösebb terhelése nélkül.

Aham, és ez miben működik másként, mint a texture from pixmap API? (Elárulom, semmiben, pontosan ugyanezt csinálja az Xorg, amióta "Aztán ahogy a broadcommal együttműködve ők is csináltak wrapper drivert". Azóta ugyanígy GPU textúraként rakja ki az X11 az ablakait.)

Ja nem fastfb, hanem fbturbo a neve annak az fbdev változatnak, amit sokáig használtak.

Öregem, ez egy XFree86-os driver, ami SOHA NEM IS volt támogatva RPi alatt, mivel Rasbian/RaspiOS az Xorg-os. Eleve hackelés Xorg alá begyógyítani. És ráadásul ez DDX DMA-s.

"xserver-xorg-video-fbturbo"
https://www.reddit.com/r/raspberry_pi/comments/1ubcwu/fbturbo_accelerat…
https://github.com/IonicaBizau/raspberry-pi/blob/master/scripts/lcd-hdm…

Zavarosak az elnevezések, de gyanítom a korábbi github link is ez, mert 
"Xorg DDX driver for ARM devices (Allwinner, RPi and others)"

És ez miért magyarázza meg azt, amit még le is írtál, hogy az általad felhozott dolgoknak "de ahhoz nem sok közve volt a desktopnak."
Úgy csinálsz, mintha értelmesen irogatnál, de valójában csak arra hozol fel érveket, hogy korábban hülyeségeket beszéltél.

Igen, ezeknek semmi köze a Wayland vs. X11 témához. PONT.

Azt nem érted továbbra sem, hogy raspberry pi alatt kurvára nem működött jól a 2d gyorsítás, mert nem lehetett teljes képernyőn képkockavesztés nélkül lejátszani böngészőben youtube videót, mert a cpu-t terhelte. Pedig a dekódolás hw-ból ment. Szóval bármennyire is hihetetlen, nem tudták megcsinálni x11 alatt, hogy ne legyen szar. (hacsak nem pi5 alatt már sikerült, vagy ott már akkora a proci erő, hogy nem tűnik fel,, nem szaggat csak esetleg a magas cpu használat)

Te megpróbálsz kitalálni dolgokat, hogy miért über alles az x11, én meg láttam, hogy a gyakorlatban szar volt hozzá a hardvertámogatás, ha nem állt be mögé nagy csapat vagy maga a gyártó. De még úgy sem csak annyi volt, hogy hipp hopp egyszer csak minden működött, mert végre 3d oldalról közelítve át tudta adni a feladatokat spéci hw programozás nélkül is a gpunak. Nekem úgy tűnik, hogy valamilyen szinten akkor is kell a gyártó segítsége, erre való zárt drivere és nem elég az, hogy opengl működik, mert ahhoz adott drivert a gyártó.

Aztán abban lehet naív voltam, hogy wayland alatt azt gondoltam elég az opengl megléte és arra támaszkodva, nem x11-es megoldásokkal esélyesebb és könnyebb megcsinálniuk egy használható desktop teljesítményt. Lehet ahhoz is kell olyan komponens, ami gyártófüggő.

Semmi köze a támához.

Te megpróbálsz kitalálni dolgokat, hogy miért über alles az x11

Nem találok én ki semmit se, azt mondom csak, hogy hw támogatás nélkül nemcsak az X11-en nem megy, hanem a Wayland is pont ugyanúgy összefossa magát.
Tehát NEM RELEVÁNS, amit mondasz.

Lehet ahhoz is kell olyan komponens, ami gyártófüggő.

Pontosan. Ráadásul pont ugyanaz a komponens kell mindkettőnek (ablakok textúrába való feltöltése). Igazából a VC drivernek hullára mindegy, hogy Wayland ablak vagy X11 ablak-e a pixelbuffer amiből textúrát csinál, és a GPU-nak is mindegy.

Én raw bare metal framebufferen (azaz se X11, se Linux DRM, se semmi csak VC MailBox framebuffer) teszteltem anno Rpi3 alatt a pixman-t, az simán hozta a 30 FPS-t 1920x1080 felbontáson non-pre-multiplied-alpha-blending metódussal (egész konkrétan PIXMAN_OP_OVER operátorral) hw gyorsítás nélkül is. Igaz, más dolga nem volt a CPU-nak, csak lapátolni a biteket a képernyőre. Ha sok egyéb dolga is akad a CPU-nak (ami egy többablakos, multitaszkos rendszernél jellemző), akkor nyilván sokat segít a GPU textúrás megoldás.

Igen, tudom, direkt írtam a referenciaimplementációt példának. De ha mást használna valaki, akkor sem az ablakkezelőben van implementálva a fontrenderelés, ez teljes hülyeség. (ps: a Cairo is csak egy példa volt, létezik más font raszterizáló lib is)

Technikailag igazad van, a legtöbb GPU-hoz nem kell a 2D gyorsításos DDX driver, a X.org hajtja DRI/DRM 3D-s driverrel, a nem ősi Intel GPU-knál a Glamour ilyen, azokon nem is ajánlott a DDX drivert használni, emiatt az Intel IGP-s laptopjaimra nem kellett xf86-video-intel csomag, sőt, ha fent volt, fagyásokat okozott, ilyenkor a dmesg-et is telefosta a rendszer mindenféle atomic refresh failure sorokkal. A másik út az a kompozitor használata, ami mesa-n, vagy vulkanon keresztül 3D-vel gyorsít. 

Én használok 2D DDX drivert az AMD GPU-jaim-hoz (xf86-video-amdgpu), mert így kisebb a hardverigény, mint egy 3D-s kompozitorral, vagy mesa-val. Aki effekteket akar úgyis, annak mindenképp kell kompozitor, mesa-n keresztül megold mindent az. Elméletileg DDX driver csak akkor kell, ha valami olyan régi GPU-ról van szó, aminek nincs 3D-s DRI/mesa támogatása, de ezek olyan ősiek, hogy rég teljesen elavultak a 90-es évekből, meg a 2000-es évek elejéről, ilyen 3dfx, SiS, Matrox, meg egyéb csodák, az X-nek előnye, hogy DDX driver szükséges ugyan, de hajtja őket, Waylanden max. CPU renderrel használhatók.

Ez, hogy mi kell, ez teszt kérdése. Kivéve NV hivatalos drivernél, mert az megold mindent saját hatáskörben, de a többi megoldásnál, nouveau, amdgpu, radeon, intel más drivert használó GPU-k, érdemes kísérletezni, főleg, ha tearing vagy grafikus/teljesítményproblémák vannak, hogy megpróbálni DDX driverrel, anélkül is, különböző kompozitorokkal. Még azt is csekkolni kell, hogy a szükséges firmware-ek fent vannak-e. Kompozitor nélkül a böngészők külön beállítást igényelhetnek, hogy ne legyen tearing (csíkozás a Vsync hiánya miatt), de már ez is kihalóban lévő probléma, mióta a legtöbb modern kijelző támogatja a Gsync-et, VRR-et.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( hory v | 2025. 07. 14., h – 15:25 )

Alapvetően nem a hobbista hupperek az átlag linuxos userek.

Az átlag linux user kap egy ubuntu LTS -t, és annyi.

Tehát azt fogja futtatni, amit az ubuntu / gnome "előír".

És nem érdekli, miért működik.

Csak működjön.

Pontosan erről van szó. Kezelje a több monitort (4K, végtelen HZ), kezelje ezek dinamikus fel/lecsatlakoztatását, normálisan nézzenek ki a fontok, legyen elfogadható sebességű, működjenek rajta az OpenGL-es dolgok, tudjak képernyőt rögzíteni, megosztani, menjen a videólejátszás (Netflix is), stb. Ezek az igények. Hogy ez technikailag hogyan van megoldva, senkit nem érdekel. Fejlesztőként sem.

normálisan nézzenek ki a fontok

A Wayland egyáltalán nem tud fontokat kezelni. Azt minden egyes alkalmazásba külön-külön le kell fejleszteni, ezért esélytelen, hogy egységesen normálisan nézzenek ki. KDE/GNOME alatt ugye ezt úgy kerülik meg, hogy minden proggi ugyanazt a libet húzza be, emiatt tűnik egységesnek, na de ez magával húzza a teljes Qt/Gtk miskulanciát függőségnek, ami meg számos egyéb problémát hoz magával.

És onnantól akkor az már nem is Wayland alkalmazás, hanem KDE/GNOME alkalmazás, ugye.

tudjak képernyőt rögzíteni

Wayland alatt ez sem lehetséges. Iszonyat hákolás kell hozzá, meg legalább két másik futó daemon, hogy a teljes Wayland protokollt és környezetet megkerülve, direktben lekérd a kompozítortól xdg-n meg dbus-on keresztül.

Ezek az igények. Hogy ez technikailag hogyan van megoldva, senkit nem érdekel.

Dehogynem. Rohadtul nem mindegy, hogy elég-e egyszer lefejlesztetni valamit, vagy pedig folyamatosan kell fizetni programozókat. FOSS projektek jellemzően nem engedhetik meg maguknak az utóbbit.

Fejlesztőként sem.

Majd fog, ha ez lesz a feladatod!

Akkor majd rájössz, mi a különbség aközött, hogy egyszer megírod X11-re és 20 év múlva is ugyanúgy működik, megha Waylandnél kéthavonta nulláról újra kell írnod az egészet, csak mert megint eltörték az API-t. Az a nagy baj a Waylanddel (fejlesztői szemszögből), hogy kurva sokat kell folyamatosan dolgoznod vele csupán csak azért, hogy ugyanolyan maradjon a programod, mint amilyen volt. Tulajdonosi szemszögből is írtó nagy baj, mert egyszeri helyett folyamatos költség, és ha egy projektre nincs elég lóvé, mert mondjuk FOSS, akkor azok a projektek állandóan el fognak romlani és működésképtelenné válnak, mindenféle különösebb ok nélkül.

<TINFOILHAT>
Ha úgy jobban tetszik, ez a FOSS tervezett elévülésére tett szándékos kísérlet, ami NAGYON GÁZ, ha jobban belegondolunk.
</TINFOILHAT>

2025-ben nem irok már desktop appot, és ha igen, akkor az web alapú lesz.

Majd hamarosan fogsz! Nem kell már sokat várni rá. A felhőnek már lecsengett, túl van a csúcsán.

Lehet, most még webes cuccokat írsz, de rengeteg más fejlesztő meg nem. Ráadásul érezhetően elkezdődött a desktop alkalmazások reneszánsza, elsősorban azért, mert gyakran befuccsol a felhő:
- ChatGPT kiesés
- Office265 kiesés
- Google kiesés (felhő, nem a keresőé)
- AWS kiesés
- ...stb.

Gyakorlatilag minden szolgáltatással előfordultak pitty-puttyok az elmúlt időben, és az ezekből származó bevételkiesés annyira jelentős, hogy már a Forbes is erről ír:
Forbes: A Wake-Up Call For Cloud Dependency

Márpedig ha a Forbesban írnak egy technológia veszélyeiről, arra oda szoktak figyelni a piaci szereplők. És oda is figyeltek, a techradar és a businessinsider szerint is.

De ne menjünk messzire: a NER szolgáltatások kiesése miatt idehaza is szabadkoznak, hogy minnél hamarabb webmentesítik a DAP-ot: "az alkalmazás legfontosabb funkcióinak offline elérhetőségén dolgoznak a kollégáink".

Ha pedig alkalmazást fejleszt valaki, akkor gondolom kapásból QT vagy GTK-ra épít

És ismét most még, de már nem sokáig.

A GIMP3 élőben demonstrálta, mennyire tévút ez. A többi projekt is hasonló gondokkal küzd, nem véletlen, hogy egyre több az alternatív megoldás és library (nézd csak meg a github-on a trendeket). Nagyon sok helyen egyszerűen nincs is elég erőforrás a QT és GNOME bloatra, és a supply chain attack is egyre dominánsabb, ami hatványozottan érinti ezeket a hulladékokat (mivel kezelhetetlen mennyiségű, még futás idejű daemon függőségeik is vannak.)

Továbbá egyre jellemzőbb, hogy WASM-ra fordított, böngészőben is futó alkalmazások váltják ki a mostaniakat, és sem a KDE, sem a GNOME nem támogatja ezt az új hype-ot, és komplixitásuk miatt soha nem is lesznek képesek rá. (Ráadásul a WASM-al böngészőre fordítható appok csont nélkül fordíthatók natív desktop appá is.)

itt a cloud vs on-premise témáról beszélünk, nem a desktop vs web

Öööö nem. Pont hogy desktop vs. web. Azaz a GUI kirajzolás metodikájáról írok. A DAP off-line példám sem on-premise, még véletlenül sem.

Simán lehet házon belül webes alkalmazásokat futtatni

Tudom, az elmúlt 20 évben számtalan intranetet fejlesztettem, de mégegyszer, itt most nem erről van szó. (Az intranet tényleg tök jó és hasznos, de teljesen másra való.)

Én értem hogy arról írsz de továbbra se értem hogy mondjuk mint alkalmazás fejlesztőként ez engem hol érdekel? Ott van akár a GTK akár a QT ha desktop alkalmazást akarok fejleszteni, és azt pedig simán lehet hogy nem is C++-ban csinálnám hanem valami magasabb szintű nyelven, pl. python-ban.

Gaphor-ba csináltam valamennyi open source kontribuciót, ott pl. minden python-ban van írva egy GTK wrapper felett, és az alkalmazás elérhető windows, macos, és linux alatt is (flatpak illetve arch csomagként). Van egy normális build pipeline, szóval pontosan semmit nem kell csinálni, a csomagok automatikusan létrejönnek.

https://gaphor.org/hu/download/

Fejlesztőként igy nem kellett azzal foglalkozni hogy most X11 vagy Wayland vagy mi van alatta, teljesen el van rejtve, és ez így a jó. Ha egyébként java-ban csinálok valamit, akkor ott is pontosan ugyanez a helyzet. 

alkalmazás fejlesztőként ez engem hol érdekel?

Ott érdekel, hogy amit te csinálsz (glue kódot irogatsz egy middleware köré), azt bármelyik ChatGPT / Copilot LLM is képes már megcsinálni, így elveszted a munkád. Maholnap utcára kerülsz, mert könnyen kiváltható a "tudásod".

Veled szemben én meg röhögök a markomba, mert amit én tudok, arra az LLM nem képes, ezért az én munkám óradíja egyre inkább csak felértékelődik :P

+1, inkább azt mondanám, hogy jelentősen átalakítja a programozás menetét, sokat könnyít rajta és a favágós feladatok ideje lecsökken, így az emberi agy arra fókuszálhat, amire az LLM nem képes: a kreatív aspektusokra. Egy fejlesztés ugyanis elsősorban kreatív folyamat, másodsorban a kód megírása, és ez akkor is így van, ha a kód megírása jelentősen több időt vesz el. Az LLM ez utóbbiból képes jelentősen lefaragni, de ebben semmi új nincs a nap alatt. C++ vonalon ott volt a SWIG, ami ilyen időcsökkentő volt, Java oldalon ott volt a Lombok, PHP/Ruby oldalon a mindenféle ActiveRecord meg proxy megoldások... és ezeknek biztos volt mindenütt másutt is párjuk, csak most kv melett ezek jutottak eszembe.

Ugyanakkor az LLM munkáját most még biztos, hogy szintaktikai szempontokból is felügyelni kell, de hiába is fejlődik ez később: szemantikailag továbbra is embernek kell átnézni a kódot. Ez egy nagyon egyszerű HTML generálásnál is így van, ahogy elnézem, olyan hibákat vét, mint minden emberi fejlesztő, de pont emiatt KELL is, hogy review-zva legyen.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A Web alapú még komplexebb. Persze, nem neked kell írni mindent, mert egy rakat libet szállít alád a webframework, de cserében egy alkalmazás is bloat lesz. 100-1000 KB helyett enni fog 0,1-1 gigát, kicsit ágyúval verébre, főleg egy egyszerű alkalmazásnál, ébresztő, basic text editor, stb..

A másik, hogy ezek alatt a webes appok alatt állandóan frissítened kell az Eletront, meg a NodeJS-es szarokat, ami azt jelenti, hogy régebbi rendszereken nem lesz elérhető.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

De basic text editort akarsz írni, vagy mondjuk videóvágó programot? De ha basic text editort is irsz, akkor se X11 szinten fogsz programozni, hanem behúzol vagy egy GTK-t, vagy egy QT-t, vagy valami más keretrendszert és azt fogod használni. 

A Electron alkalmazás pedig önhordó, ott van benne minden ami a futtatáshoz kell. Használhatsz Tauri-t is, a különbség 3 mega vs 85 mega, igazából a 85 mega se észvesztően sok. 

https://www.levminer.com/blog/tauri-vs-electron 

De ha basic text editort is irsz, akkor se X11 szinten fogsz programozni, hanem behúzol vagy egy GTK-t, vagy egy QT-t

Mindegy mit írsz, ez a "behúzod a bloated middleware-t" hozzáállás az alapvető probléma!

A Electron alkalmazás pedig önhordó, ott van benne minden ami a futtatáshoz kell.

Nincs! Csak egy böngésző (!) van benne, a libek és daemonok nem, ahogy a UI környezet se, és nem is 3 vagy 85 mega, hanem inkább többszáz MEGA!!! Belegondoltál már, mennyi biztonsági rés lehet ennyi plusz kódban?

Konkrét számok egy konkrét projektemmel kapcsolatban:
- Electronban megírva: csak a telepítője 200 MEGA (balena etcher, ezt váltottam le a saját kódommal)
- GTK-ban ugyanaz: függőségekkel együtt ugyancsak 200 MEGA
- míg X11-ben függőség nélkül: mindössze 800 KILObájt

Igen jól olvastad, egy teljes nagyságrenddel kisebb az X11-es, és annak nem kell semmi, csak libX11.so, semmi más (még a font is bele van ágyazva, még csak az sem kell).

Ellenben a GTK-snak kell egy rakat telepített fájl (konfigok, fontok, miegymás), egy csomó függvénykönyvtár (pkg-config, cairo, harfbuzz, png / tiff (akkor is, ha nem használja), fontconfig, freetype, xcb, xt, glib, udisk, stb.), a hagyományos UNIX jogosultságkezelés nem is működik vele (ez komoly, nem vicc), szükséges egy valag háttérben futó deamon (dbus, udisk2, stb.), ami egy bughalmaz (jelen sorok írásakor is 54 nyitott, kijavítatlan hibajegye van). Sokat elárul a kód minőségéről, hogy a "udiskd crashed with a SIGSEGV" hiba besorolása "medium" a fejlesztői szerint...

Az Electronossal mindez a baj ugyanúgy megvan (mivel függ a GTK-tól), csak még plusz többszáz megányi új hibalehetőség.

Persze, könnyű azt mondani, hogy "behúzol vagy egy GTK-t, vagy egy QT-t", ha bele sem gondolsz, mit is jelent ez és milyen üzemeltetési költségekkel és biztonsági rizikóval jár. És nemcsak a szokásos bugok és biztonsági rések, hanem még a supply chain attack is hatványozottan érinti.

És pont ez a baj a mai "programozókkal": nem értenek hozzá, nem is tudják, mi mivel jár, csak berántanak egy baszom nagy middleware-t, oszt azt hiszik "jó az úgy"!

nem fog futni se windows alatt, se macos alatt

De fog! A Macos alatt mindig is volt X. Mint ahogy az összes többi POSIX rendszer alatt is, sőt, még Windows-ra is van xserver (natív alkalmazáshoz). Ráadásul újabban már alapból tudja a WSL is (Linux emuláció esetén).

míg egy GTK, QT, Electron, Java, stb. alkalmazás hibátlanul fut mindegyik operációs rendszer alatt

Csak papíron, a gyakorlatban nem. Aki írt már portolható kódot, az pontosan tudja, miről beszélek.

nem véletlenül hogy az összes cross-platform rendszert valami hasonló módon írnak.

Tényszerűen HAMIS ÁLLÍTÁS. Ellenpéldaként ott az említett projektem: fut Windows-on (GDI backend), Linux-on (GTK és X11 backend), Mac-en (AppKit Framework backend), valamint bármilyen POSIX rendszeren (videó terminál backend, ncurses nélkül és az X11 backend). Csak egy minimális UI rész van külön-külön megírva, a kód túlnyomó többsége ugyanaz minden rendszeren. NEM IGAZ, hogy "az összes cross-platform rendszer" middleware-t használna!

Mégegyszer, nem érted a különbséget, te csak azt tudod elképzelni, hogy behúzol egy middleware-t és fogalmad sincs, mivel jár, mit használ; nem is ismered azt a réteget, amire épül a bloated cuccod.

De továbbra is miért is kellene azzal a réteggel foglalkozni ami alatta van, amikor pont az a lényege a GTK/QT-nek hogy ne kelljen foglalkoznom azzal hogy mi van alatta, hanem egyszerűen használok egy könyvtárrendszert ami ad ezer féle különböző GUI komponenst (van táblád? van menüd? van nemzetközisítés? stb.), amit nem nekem kell lefejleszteni, igy viszont az üzleti logikára tudunk fókuszálni ami valódi értéket jelent a felhasználó számára. 

Ugyanúgy, amikor van egy nagy rendszer, nem mindegy hogy csak a a magas szintű dolgokat kell karbantartani, vagy pedig az alacsony szintű GUI-s dolgokat IS. Igen, volt szerencsém GDI-s C-ben írt alkalmazáshoz, ahol a környezet kb. 3x annyi kódot tartalmazott mint az az üzleti logika ami értéket jelentett, cserébe bármilyen funkció belefejlesztése egy kínszenvedés volt, amit mondjuk egy sima C#-pal kb. 10 perc lett volna megcsinálni. Amig a fejlesztők pedig azzal foglalkoztak hogy a környezetet reszelgessék hogy mondjuk egy OpenID auth-ot bele lehessen a szoftverbe integrálni, addig egy magasabb szintű nyelven már réges régen szállíthattuk volna az ügyfeleinknek a terméket.

Btw, amit te egyébként csináltál az pont egy middleware lett, maximum egy nagyon vékony middleware, de attól még az. 

Valójában részben mindkettőtöknek igaza van, még ha úgy is tűnik, hogy két malomban őrőltök.

Egyrészt, ha optimális(an futó) kódot akarsz írni - és bzt-nek elsősorban úgy látom, ez a fontos - akkor bizony törődni kell azzal, hogy milyen kód fut a programod alatt: felelősen kell keretrendszert választani, felelősen kell kódolni, és tisztában kell lenni mindig és mindenkor a választott rendszer korlátaival. Sem a Gtk, sem a Qt, sem a WinForms nem a szeplőtelen szentség maga, Qt-ban is lehet platformfüggő kódot írni, még úgy is, ha közben semmilyen platformspecifikus dolgot nem húzol be. Ennek egész egyszerűen az az oka, hogy van amit a Qt, Gtk, egyebek nem, vagy nem pont ugyanúgy támogatnak mindent minden platformon - minden platformnak megvannak a maga sajátosságai. Ez egy adottság, de ahhoz, hogy értsd, hogy mi miért nem működik a kódodban, ahhoz értened kell, mi megy a motorháztető alatt.

Másrészről teljesen érthető sz332 igénye is, hogy azért az alacsonyszintű dolgok 95%-ával ne kelljen mán foglalkozni napi szinten, ha nem akar. És igen, ha valamit egy alacsony szintű, alacsony komplexitású lib/keretrendszer fölé (GDI/X11) írsz meg, ott kellemetlenül sok időt vihet el az, hogy a platform sajátosságokkal küzdesz mindennapi szinten. Ennek egy jó részét el tudja vinni egy jól megválasztott keretrendszer, főleg, ha betartod annak a konvencióit, és igyekszel nem merészkedni a határterületekre.

Ami itt nincs kimondva, az az, hogy kinek mennyi ideje van valójában a fejlesztésre. Manapság, egy felhasználók számára (tehát: parasztvakításra) készülő alkalmazásnál a fejlesztésre jelentősen kevesebb idő van adva, és ez az idő a legjobb esetben is monoton csökken, sajnos. Egyszerűen a desktop/webes alkalmazások fejlesztőinek nincs elegendő idő adva arra, hogy teljesen optimális kódot szállítsanak, rettentesen szűk határidőkkel dolgoznak, és ami bug/probléma a platformok közötti különbségekből adódik, a legjobb esetben is csak körbe van tákolva, mert entül több idő nincs a feladatra allokálva. És nem is mindig lehet eleget allokálni. A dolgok, amiket használunk, elkezdtek komplexek lenni, nagyon messze van az a számítógép ami alattunk van attól, ami mondjuk egy 486-os volt a Windows 3.11-gyel: az alapjai ugyanazok, de mégsem. Hogy ebből mennyi köszönhető az organikus evoluciónak és mennyi a különböző gyártók agymenéseinek, arról persze viták szólhatnak.

A másik faktor, amiről nem esik szó, az pedig a művészi megközelítés. Mondok egy egyszerű példát: van olyan festőművész, aki magának kevergeti ki a színeket hamuból, téglaporból, virágporból, tealevelekből, mittudomén, meg van olyan is, aki lemegy a művészközértbe és kér két tubus pirosat, egy sárgát meg négy kéket, aztán a kész festékekkel alkot. És nem lehet azt mondani, hogy az egyik vagy a másik jobban csinálja. Egyszerűen az egyiknek erre van ráállva az agya inkább, a másiknak meg arra. Alapvetően pl én is inkább leveszek egy keretrendszert a polcról, és használom, mert nekem sokat segít, ha a dolognak arra a részére fókuszálhatok, ami engem jobban vonz: az üzleti igény implementációjára. Nekem az bont ki ágakat a fejemben.

Ami a különbség köztem és mondjuk sz332 között, hogy én üzemeltető is vagyok, engem érdekel, hogy mi van a motorháztető alatt, akkor is, ha valójában a legtöbb esetben - szerencsére - nem kell megküzdenem vele, mert a keretrendszer "megoldja" - hát, úgy-ahogy. Éspedig pontosan azért érdekel, mert ha viszont valami elbaszódik, vagy simán csak nem úgy működik, ahogy elvárom, legalább elvi síkon akarom érteni, hogy mi történt itt, mi változott, mi romlott meg alattam. Volt már, hogy ennek keretrendszer váltás volt a vége, mert az addig használt rendszer egyszerűen nem kezelt le olyan eseteket, amik nagyon fontosak lettek volna, de túl későn derült volna ki, hogy ezeket nem tudja az alkalmazás. Persze, én könnyen csinálok ilyeneket, az én kódjaimban ha van negyven osztály, az már egy komplex cucc.

És egyébként azt gondolom, hogy az igazság valahol félúton van. Nem bűn keretrendszereket használni, addig, amíg tudjuk, hogy mire építkezünk. És itt a "tudjuk" alatt nem a vibe-ot értem ("a Windows egy fos, ezt mindig is tudtuk", "a Qt egy bloated szar", "a C#/WinForms az isten", stb.), hanem a tényleges utánajárást és tudást. És igen, ez sokszor nehezen illeszthető be a napi munkába. És igen, nagyon komplex kezd már lenni a világ, kezdve a mindenféle kontíneres rendszertől a mindenféle hálózatos-proxy-tökömtudja rendszeren át a biztonsági keresztbeállásokig (helló, UAC, helló macOS/PolicyKit security cuccok), nehéz mindent lekövetni. De szerintem valamennyire fontos képben maradni, mert magunknak spórolunk időt hibakeresésnél, hogy nem megyünk végig teljesen haszontalan leágazásokon.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Az, hogy valami valamit tud, és valami valamin fut, az nem jelenti azt, hogy a "valamit tudást" a futtató rendszeren valósítja meg. Lehet írni Electronban futó alkalmazást ami a háttérben soros porton beszélget, de ez nem jelenti azt, hogy a WebKit tényleg képes a soros port machinálására. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nem egészen.

A Wayland protokoll ezt nem szabályozza, rábízza ezt már meglévő protokollra, egész pontosan az xdg-desktop-portal protokollra. Ha a Wayland composer implementálja ezt, akkor ezen keresztül, biztonságosan és gyorsan (pl. pipewire segítségével) lehet a képernyő mentést/felvételt megcsinálni. Ha nem implementálja vagy nem engedélyezett a mentés egy külső alkalmazásnak, akkor pedig nem adja át az adott képernyő adatot.

Tehát a Wayland composert nem lehet megkerülni, de mégse definiálja a Wayland protokoll, mert erre van már jobb és egységes megoldás.

Szerk.: Nem is az egészet kell implementálni hozzá, hanem csak a "Screen cast portal" és/vagy a "Screenshot portal" interfészt.

Itt 3D-s játék közbeni képernyőrögzítésről beszélünk ? az nem lehetséges wayland-on ?

Nemcsak az, hanem semmilyen képernyőmentés sem lehetséges.

A jelenlegi megoldások a Waylandet teljesen megkerülve, attól független, másik protokollt (általában dbus alapú shm) használnak erre a célra, azaz a kompozítornak nem elég Waylandül beszélnie, hanem más háttérben futó daemon-okkal is kapcsolatot kell tudnia tartania. Ez nyilván magával húzza más deamonoktól való futásidejű függést, és hogy bármiféle Wayland "security" beállítást lehúzhatsz a wécén, hisz az adatért alányúlnak.

Röviden: agyrém.

Konkrét demonstráció: frameshot. Már önmagában az elég beszédes, hogy egyetlen Waylandes fejlécet sem húz be (és ha jobban belenézel, azt is láthatod, ez is OrgFreedesktopPortalRequestInterface-t használ QDBusConnection felett). A GIMP ugyancsak erre a workaround-ra kényszerül, merthogy a Wayland protokoll tényleg annyira szar, hogy még ez az alapfunkció is hiányzik belőle.

Konkrét demonstráció: frameshot. Már önmagában az elég beszédes, hogy egyetlen Waylandes fejlécet sem húz be (és ha jobban belenézel, azt is láthatod, ez is OrgFreedesktopPortalRequestInterface-t használ QDBusConnection felett). A GIMP ugyancsak erre a workaround-ra kényszerül, merthogy a Wayland protokoll tényleg annyira szar, hogy még ez az alapfunkció is hiányzik belőle.

 

Úgy nézem, a 'grim' a fő csapásirány waylanddal screenshotot csinálni. Hogy ez most a kompozitorhoz beszél, vagy a jóistenhez, azt nem tudom.

Szerk.: mintha a wlrootban lenne egy wlr-screencopy extension, azt használja.


 

Mondjuk én semmi kivetnivalót nem látok abban, hogy a display szervert egy szoftver végezze, míg a desktop-műveleteket egy másik szoftver.

A grafikus megjelenítés mint olyan, nem feltétlenül kell, hogy desktop funkcionalitást jelentsen. Nem baj az, hogy van egy freedesktop szabvány a desktop funkcionalitásokra. Alapból privacy szempontból problémás dolog, ha egy alkalmazás bármikor screenshotot csinálhat egy másikról. Szóval ez nem workaround, hanem tök jól átgondolt modellje a desktop működésnek.

Xorg alatt is jobb lenne, ha a kifejezetten desktop dolgokat elválasztanák a display szerver működéstől.

Az Xorg legyen az, ami: display szerver. Feleljen a megjelenítésért. Más eszközök meg majd felelnek más dolgokért, szépen UNIX filozófia szerint. Az baromira nem UNIX, hogy az Xorgba mindent belepakolunk, aminek egy kicsit is köze van a GUI módhoz, és a GUI-val rendelkező alkalmazásokhoz.

Erre rá tudok kapcsolódni, a legelső Ubuntus Waylandra váltás körül nagyon nagy szopások voltak nálunk a képernyőmegosztás terén, gyakorlatilag egy rémálom volt minden Linuxos kollegának, ha képernyőt kellett megosztani, hatféle jóváhagyás mellett is 3x kellett nekifutni, mire egyszer sikeredett - ha egyáltalán és egyébként addig nem ért véget a meetingre szánt idő amúgy is.

És gyakorlatilag semmi egyéb megoldás nem állt rendelkezésre, mint átterelni őket Ubuntu (Xorg) session-re, ahol ezek a hibák mágikusan eltűntek.

Részben ezért is félek a Waylandra váltástól, mert az egyszerű felhasználó számára nincs még kész. Egy hobbista azzal szop, amivel akar a szabadidejében, I don't give you a flying fuck darling, de van aki eléggé el nem ítélhető módon dolgozna a grafikus rendszerrel való napi küzdelem helyett. Elképesztően unortodox gondolat ez, tudom... 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Időről-időre azért érdemes Waylanddel próbálkozni, mert ezeket a képernyőmegosztásos, meg Electron appos, stb. bugokat azóta több menetben javították. Gyors léptékben fejlődik, ha pár hónapja még nem is ment valami, érdemes most is megpróbálkozni vele rendszeresen.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nem azt mondom, hogy nem fogok ránézni időnként, de lesznek szívesek nem kihúzni alólam a munkakörnyezetemet. Mert egy dolog, hogy valaki valamivel otthon kísérletezik - ki Waylanddel, ki LFS-sel, ki robbanószerekkel ugye - és egy teljesen másik dolog a napi szintű munka, ami nekem nem feltétlenül az, hogy a Wayland adta korlátokkal akarok szopni.

És bármennyire is szeretném - egyre kevesebb időm és főleg: türelmem van ezekhez a kísérletezgetésekhez. Mondhatjuk azt, hogy megöregedtem. Kísérletezgessenek a fiatalok meg a nyugdíjasok, akiknek végtelen idejük van - nekem most épp hiánycikk az idő. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Maga a desktop GUI műfaja komplex, OS-től függetlenül nagy mennyiségű OOP kód, sok mindent kell támogatni, hogy menjen mindenféle köztes réteggel, protokollal, mindenféle GPU driverrel, grafikus API-val és toolkittel, konténerizált, sandboxos, portálos fétissel. Eleve szinte végtelen a kombinációk száma, lehetetlen mindent tesztelni rendesen. Ráadásul a felhasználók igényei növekednek, akarnak ma már minden extrát, változó refreshrate-et, HDR-t, VR-t, mindenféle grafikus API-t, színhelyességet, képernyőmegosztást, változó méretű, több monitor kezelését. Régen ugye 1 gépen volt 1 monitor, az se a legnagyobb felbontású, azt hajtani fele ennyi malőr se volt.

Emiatt elég összetett még beállítani, telepíteni is. Persze, segít, ha az ember felhasználóbarát disztrón van, ahol mindent beállítottak helyette ÉS megy. HA megy, mert ha nem megy, ott is vért fog hugyozni, mire visszafejti, hogy mi hajtja, mi kell hozzá, hogy menjen.

Elvileg a Wayland egy inkább low level protokoll, ki próbál hagyni köztes rétegeket (2D driver, szerver-kleinsoldal, hálózati rész), hogy közvetlenebbül kezelje a hardvert, meg nem kell neki legacy kompatiblititást tartani. Cserébe viszont behozott más bonyolításokat, Wayland alatt ugye az alkalmazások nem férnek hozzá biztonsági okból a képernyőhöz, billentyűzethez, ezeket portálokkal kellett pótolni, ami iszonyat gány hack, és visszahoz komplexitást.

A másik, hogy az X hiába több réteges, több évtized alatt, természetes fejlődéssel bővülgetett, így volt idő kitesztelni, kiforrt a kód. A Wayland meg az első 10 évében sehová nem haladt, főleg az NVidia makacssága miatt, utolsó 5 évben feküdtek neki, most rohamtempóban kalapálják, meg ultra erőszakkal tolják rá mindenkire, de ennek a sietségnek ára van, összecsapottabb, kiforratlanabb még.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

... és egyébként most üt vissza az, hogy "nem kell neki legacy kompatiblititást tartani". Ha tartaná, akkor nem lenne szopás azzal, hogy a Waylandot és az azt használó alkalmazásokat is át kell fejleszteni, hogy működjenek, vagy legalábbis valahol valamilyen köztes libben ezt meg kell oldani, máskülönben egyszerűen az egész működésképtelen.

Nagyon azt érzem, hogy a Wayland egy lelkes, de átgondolatlan koncepció mentén van fejlesztve, és már késő felvetni, hogy újra kéne dolgokat gondolni, mert még ha technológiailag lehetséges is lenne, akkor is már "csakazértis" alapon nem változna semmi.

És ugyanez a véleményem az összes "modern" FOSS rendszerről, ami le akart váltani valami 30 éven keresztül jól működőt. Ott volt a SystemD, ott volt a PulseAudio, most itt a Wayland, ez a hülye történelem nem bírja abbahagyni, hogy ismételje önmagát. És mindezt miért? Mert akiknek ilyen fasza visionjeik vannak, nem szántak rá kettő és fél percnél többet, hogy megismerjék azt a cuccot, amit leváltani akarnak. Aztán jött a hype vonat, felült rá 1-2 nagy cég, és most már muszáj ezzel menni, mindegy hány ember munkáját basszák széjjel, és hány embernek okoznak komoly fejtörést. 

És az a 10 éves állás nem számított semmit. A PulseAudiot 21 éve fejlesztik, tudtommal különösebb megállások nélkül, és még mindig ott tartunk, hogy a BT headsetek csak HDP-ben képesek a mikrofont is használni, A2DP-vel csak füles van. És ebben semmi nem változik.

De mondhatnám a SystemD-t is, 2010 óta fejlesztik, azóta próbál a fél oprendszer ő maga lenni, és minden kicsit is komplexebb komponensének van valamilyen komolyabb hiányossága, vagy vaéami komolyabb bugja. Ráadásul DBus nélkül már az se szólal meg.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

És ugyanez a véleményem az összes "modern" FOSS rendszerről, ami le akart váltani valami 30 éven keresztül jól működőt.

A régi FOSS rendszerek is hasonló módon készültek, az újak éppen azért indultak, mert a régiek nem voltak jól átgondolva. Persze vannak olyan újak is, ahol most sem sikerült jobban átgondolni, vannak olyanok, hogy jól sikerült, de a megvalósítás hibádzik, illetve olyan is, ahol már elsőre egész jól funkcionál. Utóbbiba én pl. a PipeWire-t betenném. Szerintem bizonyos csomagkezelők is egészen jól funkcionálnak, pl. flatpack, nix. Említhetném még a CVS utáni verziókezelőket is, szinte mind előrébb lépett az előzőekhez képest (SVN, Git, Mercurial, Jujutsu). Bizonyosan lehetne még folytatni a sort.

A régi FOSS rendszerek is hasonló módon készültek, az újak éppen azért indultak, mert a régiek nem voltak jól átgondolva.

Ez nem igaz. Bármelyik tetszőleges régi rendszer MILLIÓSZOR JOBBAN át volt gondolva, mint bármelyik mostani. Már csak azért is, mert régen nem volt elég erőforrás, muszáj volt odafigyelni, és azokat még komoly, hozzáértő szakemberek alkották, nem middleware vérpistikék, mint a mostaniakat.

Hogy konkrét ellenpéldával cáfoljalak: hiába régi az X protokoll, mégsem okozott gondot belerakni a kompozítort meg a 3D-s gyorsítást. Miért? Mert jól volt átgondolva, eleve bővíthetőre volt tervezve.

Nekem olyan érzésem van, hogy szándékosan b*sszák szét a FOSS-t, kb. pont az történik, mint a Linux kernel esetén: fizetett céges szarcsimbókok pakolják tele szar kóddal, hogy lerontsák a konkurenciájukat. Időről-időre néha persze lebuknak, hogy szándékosan rongálják, de akkor is Linust küldik angermanagementre, holott tök jogos a felháborodása. Én mondom, szándékos szabotázs ez, amit a cégek pénzelnek, hogy nehogy valós alternatíva lehessen a FOSSból.

Utóbbiba én pl. a PipeWire-t betenném.

Én meg semmiképp. Úgy el van az baszva már tervezésügyileg, hogy sosem lesz képes alacsony latency-t elérni, ami egy stúdióban elfogadhatatlan.

Úgy el van az baszva már tervezésügyileg, hogy sosem lesz képes alacsony latency-t elérni, ami egy stúdióban elfogadhatatlan.

PipeWire generally offers lower latency than JACK when properly configured. While JACK was specifically designed for low-latency audio, PipeWire, with its recent improvements, can now achieve comparable or even better performance for many use cases. PipeWire also offers the benefit of seamlessly handling both PulseAudio and JACK applications.

🧩 1. ALSA (Advanced Linux Sound Architecture)

  • Szint: Alacsony szintű hangrendszer (közvetlenül a kernel alatt).

  • Késleltetés:

    • Közepes, de nem ideális valós idejű (real-time) alkalmazásokhoz.

    • Nem rendelkezik beépített "low latency" mechanizmussal, de hangolható.

  • Használat: Közvetlen hardverelérésre, például médialejátszóknál.

  • Előny: Stabil, egyszerű.

  • Hátrány: Nehéz nagyon alacsony késleltetést elérni vele.

🎛️ 2. JACK (JACK Audio Connection Kit)

  • Szint: Valós idejű, professzionális hangrendszer.

  • Késleltetés:

    • Nagyon alacsony késleltetésre optimalizált.

    • Tipikus értékek: 2–10 ms, néha kevesebb is (buffer mérettől, mintavételi frekvenciától, rendszer RT kernelétől függ).

  • Használat: Zeneszerkesztés, DAW-ok (pl. Ardour, Qtractor), élő hangfeldolgozás.

  • Előny: Precíz szinkron, professzionális audio routing.

  • Hátrány: Bonyolultabb konfiguráció, több rendszerkompatibilitási kihívás.

🔀 3. PipeWire

  • Szint: Modern, egységes hang- és videórendszer (PulseAudio + JACK utódja).

  • Késleltetés:

    • Alacsony késleltetésre képes, különösen ha JACK módot használ.

    • Cél: JACK szintű késleltetés, de PulseAudio-kompatibilitással.

    • Valós tesztekben ~3–10 ms is elérhető megfelelő beállítással.

  • Használat: Általános desktop hangrendszer, de támogat professzionális felhasználást is.

  • Előny: Kompatibilitás ALSA, JACK és PulseAudio alkalmazásokkal; egyszerűbb beállítás.

  • Hátrány: Még fejlődő technológia, egyes niche esetekben instabilabb lehet.

 

Összegzés (latency szempontjából)

Rendszer Átlagos latency Valós idejű alkalmazásra alkalmas? Megjegyzés
ALSA ~10–30 ms Részben Nehéz alacsony latency-re hangolni
JACK ~1–10 ms ✅ Igen Legjobb valós idejű feldolgozáshoz
PipeWire ~3–10 ms ✅ Igen JACK-szintű teljesítmény, többfunkciós

Az AI megkérdezése nem kutatás. Amit fenn írsz, annak egész pontosan nulla relevanciája van, mivel fogalmad sincs, mennyi az igazságtartalma. Ha lenne, akkor azt írtad volna le, és nem az AI-t kérdezed meg.

Most légyszives ballagj el, és olvass utána a tényleges adatoknak. Aztán, olvass utána, hogy mi az elvárás egy stúdióban. Utána gyere vissza, mondd el a véleményedet, és támaszd alá forrásokkal. Mert ez eddig olyan, mintha fingottál volna, azt pedig jól tudjuk, hogy társaságban nem illik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Már az első általam írt idézetben is le van írva, hogy a Jack eleve úgy lett tervezve, hogy minimális legyen a latency. Tehát már ez önmagában cáfolja azt, amit bzt ír.

JACK Audio Connection Kit (or JACK) is a professional sound server API and pair of daemon implementations to provide real-time, low-latency connections for both audio and MIDI data between applications.

Kíváncsian várom a fenti adatok cáfolatát, mert amit Te írtál annak nincs semmi relevanciája, mert semmi információ nincs benne. Semmit nem cáfolsz vagy erősítesz meg.

Egy youtube lejátszás közben:

pipewire   3230                                           865 /dev/snd/pcmC1D0p
pipewire   3230                                 530 /dev/snd/seq
pipewire   3230                                 530 /dev/snd/seq
pipewire   3230                                 879 /dev/snd/controlC1
pipewire   3230                                 865 /dev/snd/pcmC1D0p
pipewire   3230  3239 module-rt                           865 /dev/snd/pcmC1D0p
pipewire   3230  3239 module-rt                 530 /dev/snd/seq
pipewire   3230  3239 module-rt                 530 /dev/snd/seq
pipewire   3230  3239 module-rt                 879 /dev/snd/controlC1
pipewire   3230  3239 module-rt                 865 /dev/snd/pcmC1D0p
pipewire   3230  3242 data-loop                           865 /dev/snd/pcmC1D0p
pipewire   3230  3242 data-loop                 530 /dev/snd/seq
pipewire   3230  3242 data-loop                 530 /dev/snd/seq
pipewire   3230  3242 data-loop                 879 /dev/snd/controlC1
pipewire   3230  3242 data-loop                 865 /dev/snd/pcmC1D0p

 

A /dev/snd-t mi adja, ha nem az ALSA?

Az igaz, hogy bluetooth lejátszásnál a bluezon keresztül nem kell neki ALSA, csak bluetooth kapcsolatot nem nevezném low-latencynek.

Mint az ALSA? És a hang min fog megszólalni? Vagy mit akarsz mondani? Szerintem magad se érted...

 

Szerk.: arról, hogy mennyire megbízató ez az "AI":

google keresés: 'pipewire list of sinks'

AI-alapú áttekintés:

.

.

kód: 

pw-cli info 'object.media.class=Audio/Sink'

 

$ pw-cli info 'object.media.class=Audio/Sink'
Error: "info: unknown global 'object.media.class=Audio/Sink'"
 

Tehát a hangot, amit hallok, nem az ALSA driveren keresztül küldi a hangchipbe. Hát persze.

Akkor ez mi?

.

       id: 50
       permissions: rwxm-
       type: PipeWire:Interface:Device/3
*       properties:
*               api.acp.auto-port = "false"
*               api.acp.auto-profile = "false"
*               api.alsa.card = "2"
*               api.alsa.card.longname = "HD-Audio Generic at 0xfc400000 irq 69"
*               api.alsa.card.name = "HD-Audio Generic"
*               api.alsa.path = "hw:2"
*               api.alsa.split-enable = "true"
*               api.alsa.use-acp = "true"
*               api.dbus.ReserveDevice1 = "Audio2"
*               api.dbus.ReserveDevice1.Priority = "-20"
*               device.api = "alsa"
*               device.bus = "pci"
*               device.bus-path = "pci-0000:09:00.4"
*               device.description = "Starship/Matisse HD Audio Controller"

 

Én ezt értem, fent meg is kérdeztem, hogy vajon a libasoundál jobb a pipewire, vagy már a kernel drivereknél is (amit muszáj használnia, ha hangot is akar kiadni magából), amire válasz csak a hablaty volt.

Csavar a dologban, hogy libasoundon át el lehet érni a pipewire-t is, mint virtuális hangeszközt, kihasználva esetleg annak hálózati képességeit. ALSA lib-pipewire-ALSA hangkártya viszont már nagyon perverz lehet. Na ennek mi lehet a latencyje?

Nem biztos, hogy megértetted ;)

Az ALSA HAL (Hardware Abstraction Layer) maga a kernel driver, minden ezt használja, a libasound (ez az ALSA userspace része), a PipeWire és a PulseAudio is. Nincs másik kernel driver, csak ez.

Nekem nagyon úgy tűnik, hogy emiatt amikor valaki sound API-ra hivatkozik, akkor a kernel driver-t nem értik ide ;)

Mind a PulseAudio, mind a PipeWire tudják azt csinálni, hogy a libasound számára nyújtanak olyan eszközt, amit saját magukon keresztül route-olnak, azaz ha pl. egy Ubuntu 24.04-est felraksz, akkor a libasound-ot használó alkalmazások a PipeWire-en keresztül fognak a kernel driverrel beszélni, azaz ALSA(userspace)->PipeWire->ALSA(HAL)->hardver lesz az út. Így oldják meg a visszafelé kompatibilitást, és így lehetséges az, hogy pl egy RSTP-n keresztül küldje ét a hangot egy másik gépre egy libasound-ot használó alkalmazás, aminek amúgy fogalma sincs a hálózati streaming protokollokról. Másrészt nem hiszem, hogy ennek lenne extra latency a natív API-hoz képest, fogadni mernék rá, hogy a libasound "emuláció" nem igényel extra buffer-copy-t.

Az ALSA (libasound) latency-je pedig azért rosszabb, mint a másik kettőé mert az API-ja sokkal butább/egyszerűbb: nem lehet részlegesen feltöltött buffert használni, azaz ha már inicializáltad, akkor akkora lesz a latency, amekkora a buffer méret és kész. A másik kettő API-val (sőt, vegyük ide harmadikként a JACK-et is, ami szintén az ALSA kernel drivereket használja) lehet részleges buffert swappelni, így akármikor lehet a következő hangmintát játszani. Persze libasound-al is lehet kisebb latency-t csinálni kidebb bufferrel, de egyrészt macera, másrészt minimum méret korlátok is vannak a hardveres driver miatt, ráadásul ha kisebbre veszed a buffert, akkor sokkal több CPU időd megy a bufferkezelésre folyamatosan.

Mi a baj a PipeWire-el? Nem néztem rá, hogyan épül föl, milyen az architektúrája.

A PulseAudio-hoz képes sokkal jobbnak tűnik. Mondom ezt úgy, hogy azzal sem volt sok gondom, pedig hülyéskedtem vele sokat (BT headset, surround hangkártyából 2 külön hangkártya, hálózati lejátzás, stb), de valahogy mégis mindig félkésznek éreztem, kicsit lag-osnak, a pöttering csávó hozzáállása a fórumokon pedig bicskanyitogató volt.

Persze én az ALSA-val is elvoltam, a dmix pluginje (megfelelő hangkártya esetén hardveres mixeléssel) megoldotta a normál desktop használati eseteimet, BT fülesem meg akkor még nem volt :), az ALSA tudása most már kevés

A PulseAudio-hoz képest a PipeWire sokkal jobban átgondoltnak, és mindenképpen sokkal jobb minőségben megírtnak tűnik, eleve a GStreamer fejlesztők csinálták, akik már tudtak ezt-azt audio (és video) streamingről, míg a pöttersegg azt hiszi, mindenhez is ért. Persze ettől még lehet szar, de én nem ezt érzem.

Low latency audio pedig külön állatfaj, arra való a JACK, kíváncsi vagyok a PipeWire tudja-e, amit ígért, és kiváltja-e. Mindenesetre ez az a felhasználási szint, amire nekem nincs szükségem, tekintve hogy nem foglalkozom real-time audio feldolgozással és zenekészítéssel, ha jól sejtem, ezen a fórumon sincsenek sokan ilyenek.

Persze, nincs is baj, ha újítanak, meg újragondolnak dolgokat. Itt azzal van baj, hogy általában erőltetett ütemben nyomják, ráfelé mindenkire agresszíven, a régi jól bevált rendszer mielőbbi, erőszakos elavultatásával.

Amit nem ért meg a sok Red Hat-es gyökér, hogy nem csak a Linux létezik, és hogy a lényege az lenne, hogy egy unixlike rendszer, és nem lehet csak úgy eldobni jól bevált, és szervesen kifejlődött dolgokat, mint az X, meg a sztenderd shell, sysvinit, és hogy számít a hordozhatóság is. Az a baj, hogy csak nagyon a Red Hat-ben meg a Linuxban gondolkodnak, és próbálnak minden lebutítani, meg mac-esíteni, windowsosítani, akkor is, ha semmi szükség nincs rá.

A Canonical is ezt csinálja, pl. a Snap-pal. Senki nem kérte, de oké, létezzen, aki valami programot nem tud natív csomagból feltenni, az tudja így is használni. De ők kizárólagosan akarják nyomni, a létező natív csomag helyett, na, az gáz. Meg hogy kihekkeled a rendszerből, erre következő update-re visszamászik. Aztán csodálkoznak, hogy mindenki szidja őket, pont most volt a közösségi médiában is két videó, hogy két emberke fellázadt, hogy mindenki a Zubuntutot bántja, milyen igazságtalan, nem muszáj használni, váltsanak Arch-ra. Persze, ezt a legkönnyebb mondani, hogy mindenki váltson, meg ne legyen véleménye, a Canonical meg hadd találhassa fel a kereket.

Ugyanez volt a systemd-vel is. Azt is behozták, ráerőszakolták mindenkire. Persze, fel lehet tenni másik initrendszert, működik is, én használtam OpenRC-t, runitot is helyette, Gentoo-n, Artixon, Void-on, szépen működnek, de az ember azon veszi észre magát, hogy hiába használ másik initrendszert, ha megnyitja a folyamatlistát, épp úgy ott figyel a udev, elogind, többi szutyok, és csak hülyíti magát, hogy ő kikerülte a systemd-t, mikor részimplementációi épp úgy futnak a rendszeren függőségek miatt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( szkaresz v | 2025. 07. 18., p – 08:34 )

Nem kétlem biztos sok munka és erőfeszítés van a wayland-ben, de a használatban amit látok, azzal úgy vagyok, mint az öreg székely a zsiráffal. Szép, szép, de otthonra nem kéne. :(

Karesz

Letölthető háttérképek  |  Portréfotók

( Smokey2k | 2025. 07. 18., p – 13:34 )

3 monitoron x11 alatt sem nvidia sem intel alatt nem tudtam megoldani hogy a 3 különböző monitor 3 különböző frekin fusson és legyen lag és tear mentes display oob......wayland (plasma) alatt evvel nem is kellet foglalkoznom. amd gpuval nem próbáltam de az meg kell a halálnak mert max játékra jó ..v-ray kb le se szarja az amd-t és így van még egy rakás más proggival .......de kb. ehhez hasonló dolgok vezettek oda hogy tavaly eluntam ezt az egész szarakodást a linux desktop-al és váltottam windowsra ....linux jó lesz házi szervernek meg hasonló dolgokra de a linuxdesktopéva nálam nem eljött hanem elment..... 20 év elég volt hozzá hogy ez végleg bebizonyosodjon.

nem tudtam megoldani hogy a 3 különböző monitor 3 különböző frekin fusson

Hát ez azért nem épp egy jellemző konfiguráció, nem hiszem, hogy a felhasználók 99,99999999999% valaha is találkozna ilyennel...

Egyébként meg a Xinerama csont nélkül tudja (ezt is!). Csak XFree86 alatt kellett kézzel konfolni, Xorg alatt már automatikus. Szóval a gond az volt, hogy nem értesz hozzá.

bzt-t Linuxpistázni azért minimum merész... egy keveset fogj már vissza az arcodból, Füsti. Ott kezdődik, hogy te nem tudod, hogy ő mit írt. És ez a 2. pontodnál ki is bukik. Menj már a fenébe, kérlek szépen.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-