Lära mig Wayland

[Marta]

Skippa mitt dravel i början av tråden....

Det är nog dags att portera min lilla editor till Wayland. Jag har läst en del och testat lite med en installation i VB, men betrakta det som att jag vet i princip noll om Wayland.

I xlib använder jag XPutImage för att få ut raderna på skärmen. En XImage skapas vid programstart och till denna en pekare till dess pixelbuffer. Denna ligger kvar tills programmet avslutas.
Proceduren med XLib är att rendera en rad, sedan visa den med XPutImage.

Som jag hittills har uppfattat det med Wayland måste det allokeras en buffer med shm, rendera raden, skicka buffern till compositorn. Sedan ge ett commit-kommando och buffern läggs ut för att därefter deallokeras av en callback. Eller bearbeta alla de aktuella raderna med vars en buffer och en commit för dem alla. Antar det senare är det korrekta.

Är detta rätt uppfattat, eller har jag fått något om bakfoten från början? För mig känns detta som en tung overhead och excellent källa till minnesläckor och segfaults.

Antar att shm används för att compositor skall kunna vara en separat user != root och att callback dealloc är för att commit inte blockerar tills den är färdig.
Är shm alloc/dealloc blixtsnabba? Allt krafs med fildescriptors och allt vad därtill hör känns, utan att veta, som något med avsevärd tyngd. Kanske bättre att ha tillräckligt med shm-block allokerade hela tiden och med en flagga för när de är upptagna?

Skulle det vara möjligt att skippa hela detta härke och som nu rendera till en lokal buffer som alltid ligger kvar och istället för XPutImage direkt skyffla ut den till framebuffer utan någon overhead? Det förutsätter group video för att kunna öppna /dev/fb0, men det bör knappast vara något problem. Lite udda, men för ett udda program så...

[agehall]

Jag skulle aldrig rekommendera någon form av frekvent allokering/avallokering om man absolut inte måste. Det är ingen större skillnad på tiden det tar om det är applikationslokalt minne eller inte, men det skapar fragmentering som inte är bra.

Jag är ingen expert på Wayland, men jag är ganska säker på att det fungerar att ha två buffrar permanent allokerade. Sedan skickar du en buffer till compositor:n och ritar i den andra. När du får callbacken så byter du så att du ritar i den buffer du fick tillbaka och den andra skickas till Wayland. Dvs, klassisk dubbelbuffring.

[Marta]

Tack för svar.

Det blev nog lite virrigt i mitt första inlägg, där är mycket info att ta in och materialet jag hittat på nätet är inte bra. Författaren försöker få med mer än vad som behövs på en gång.

Har nu läst igenom lite stillsammare och det verkar finnas en färdig lösning. Det ingår hantering av en memory pool som först allokeras från systemet och sedan allokeras buffrar lokalt från denna. Växelvis buffring kanske ändå är bättre, men det verkar som det hela sker på ett stökigt sätt. Först allokerar den två gånger, likadana, utan att släppa den första. Sedan släpper den båda i följd. Är nog bäst att göra som det står.

Ett nytt bekymmer är att allokering görs från angiven rityta. Min fontrendering kräver lite extra i början/slutet av raden för att hantera propfonts där del av en glyph skall visas i kanterna. Det hanterade XPutImage perfekt. Blir väl en extra skyffling.

Blir allt mer konfunderad över Wayland. Den kan tydligen inte ens visa den grafiska cursorpilen själv. Framgår inte hellre klart av det material jag har hur det går till att få upp ett fönster med ram och allt. Det hela känns som ett besvärligare och ofullständigare sätt att göra saker än med xlib.

Behöver en verkligt bra bok, om det finns. Även om den kostar. Vill ha tydliga, kommenterade kodexempel och enkla tydligt förklarade beskrivningar utan att blanda in irrelevant krafs för att få med precis alla obskyra möjligheter.

[Marta]

Har läst en del nu och är mer redo. Master Reset och omstart...

Letar efter en vettig, up-to-date och komplett beskrivning för att komma igång med att sätta upp och initiera en Wayland-client utan att använda GTK e.dyl. Text på nätet eller tryckt bok för upp till 1000kr är OK om den är riktigt bra.

Vettig betyder exempel där det rad för rad beskrivs vad som skall göras, hur det skall göras och varför det behöver göras. Inget dravel utanför client side. Inga hänvisningar hit och dit. Inga märkvärdiga ord.

Up-to-date betyder att allt som beskrivs är det för dagen relevanta, fritt från obsoleta funktioner.

Komplett betyder att skribenten har gjort färdigt sitt arbete och inte tröttnat och lämnat det halvfärdigt.

[Marta]

Löst, koden ändrad.
Har kommit en bit nu, men här är det tvärnit och hittar ingen info.
Använder en buffer som ligger kvar, eftersom det är så jag föredrar att det skall vara.

Den här lilla testrutinen körs vi tryck på mellanslag, men inget ändras och xdg_surface_configure utförs inte. Klickar jag därefter på terminalfönstret så testrutan tappar focus så utförs configure, men ingen ändring. Klickar på testrutan, configure utförs på nytt och ändringen visas.

Så hur f*n skall jag göra för att ändringen omedelbart skall visas?

Kod: Markera allt

         
         if (key==0x39){
           flipp = flipp!=1;
           drawBkgnd(flipp);
           wl_buffer_add_listener(wbuf, &buffer_listener, NULL);
           wl_surface_attach(surface, wbuf, 0, 0);
           wl_surface_damage_buffer(surface, 0, 0, INT32_MAX, INT32_MAX);
           wl_surface_commit(surface);
         };

Kod: Markera allt

static void xdg_surface_configure(void *data,
        struct xdg_surface *xdg_surface, uint serial){

    printf("configure\n");

    xdg_surface_ack_configure(xdg_surface, serial);
    wl_buffer_add_listener(buffer, &buffer_listener, NULL);
    wl_surface_attach(surface, buffer, 0, 0);
    wl_surface_commit(surface);
};

[Icecap]

Om du bara vill toggle flipp, duger flipp ^= 1; fint.

[Marta]

Problemet är att det visade mönstret inte ändras. Koden exekveras, flipp flippas, men mönstret i rutan uppdateras inte. Avsikten med det hela är att finna ut vad som krävs för att Wayland slall göra en omedelbar uppdatering till den grafik som finns i buffern efter drawBkgd har körts.

Ändringen sker, men den visas inte som jag vill den skall göra, alltså absolut omedelbart. Ett par olika exempel jag hittat är grnd för detta, men de visar bara en ruta och tvärlåser sedan. Har lagt till kod för tangentbord och, trodde jag, för att uppdatera bilden.

[Marta]

Nu är min lilla editor så gott som helt portad till Wayland. Återstår clip/paste och att snygga till lite detaljer. Det mesta var betydligt enklare än befarat. Det som tog emot mest var helt oväntat repeterande tangenter, som Wayland lämpat över på applikationen.

En smådetalj jag inte förstår är att den grafiska cursorn döljs vid tvåfinger scroll på tangentbordets trackpad. Den blir osynlig och måste föras utanfööör fönstret och tillbaka för att åter bli synlig. Rutinen för att dölja den körs inte. Wayland har inte detekterat någon touchpad. Någon som känner till eller sett något om liknande strul med Wayland?

[Marta]

Har nu testat att kompilera min editor för RPi5/ARM och det fungerar fint till största delen, men att dra storleken på fönstren funkar inte. Det visas symboler för resize, men fönstret följer inte med. Det funkar med både Weston och i Fedora.

Använder xdg_toplevel_resize till detta. Binder xdg_wm_base ver.3 för dessa. RPi har förvånansvärt nog endast ver.2, så fick sänka. Funkar ändå i Weston och Fedora.

Är där skillnad i detta sammanhang mellan xdg_wm_base ver. 2 och 3?
Finns ver.3 funktionaliteten kvar fast den binds med ver.2?

Är uppe i ver. 6 nu, så RPi måste väl uppgradera snart? Är det ver.2 som är problemet så är det väl knappt värt ansträngningen att åtgärda.