( Caro | 2021. 02. 24., sze – 19:12 )

Hát izé. Nem látok ugyan nagyon bele a wayland fejlesztésbe, de ez a mondat nagyon megütötte a szememet a wikipedián:

"The resulting buffer with the rendered window contents are stored in a wl_buffer object. The internal type of this object is implementation dependent. "

Előtte pedig azt ecseteli, hogy ebbe a bufferbe vagy ír a kliens direktben, vagy valamilyen library-n keresztül. Az mennyivel jobb, hogy a feladatot áttoltuk a rendering library-ba? A cairo, a gtk meg a qt eddig szabványos kimenetet állított elő az x szerver számára. Eztán majd ezeknek kell ismernie az alatta lévő hardvert? Az vidám lesz. Tényleg sokkal jobb az x-nél.

Van jó példa is, mint az SDL, amit még régebben magam is használtam, de itt erről szó nincsen.

Az X driver pedig tudtommal abból áll, hogy tud vonalat, kört, stb.-t rajzolni. Egyébként egyáltalán nem kell X drivert írni, elég kernel drivert írni, és akkor xfbdev-el már van is X. Ahhoz hogy legyen grafikus gyorsítás, én nem látom hogy lehetne megkerülni a hardverfüggő driver írását, akár X-ről, akár wayland-ről beszélünk. Az még windows esetén is kell :D

Hajbinak meg szerintem totál igaza van, hogy a desktop feladatok többségére bőven elég egy 2D gyorsított felület. A framebuffer driverek pedig eléggé stabilak, ugyanis egy lineáris memóriaterület kezelését elég nehéz elrontani. Ettől persze még lehet kukázni az X-et, de ha ennyire instabil, és rosszul definiált, akkor nem biztos, hogy a wayland irányába érdemes elmozdulni. Márpedig instabil, én is tapasztaltam, épp embedded vonalon.