Wayland

Bakgrunn

Linux er et operativsystem som benytter beskyttelsesringer i moderne mikroprosessorer.  Dette er en mekanisme som beskytter data og funksjonalitet mot feil i programmer og uønsket adferd. Utføring av maskinkode for å modifisere registrene for deskriptortabeller er eksempel på noe som kan få hele systemet til å krasje hvis det er feil i programvaren, og som må overlates til dedikert og betrodd programvare.
Linux skiller mellom brukermodus og supervisory mode. Programmer i brukermodus har ikke lov til å utføre disse maskinvarerelaterte kommandoene direkte. De må sende et systemkall til supervisory mode, hvor en betrodd del av Linux utfører funksjonen. Denne betrodde delen av Linux er Linuxkjernen. Vi sier at Linuxkjernen kjører i ring 0, mens de øvrige prosesser kjører i ring 3.
Vindussystemet X er programvare som kjører som en ekstern prosess i ring 3. Moderne skrivebordsmiljøer som KDE, GNOME og Xfce kjører i tillegg som eksterne prosesser som sender kall til en X Server. Man får dermed en situasjon hvor grafikken i Linux sender kall gjennom to abstraksjonslag. Dette er unødvendig komplekst og ressurskrevende.
Mange av funksjonene i X11 har i årenes løp blitt flyttet inn i operativsystemkjernen til Linux. Dette gjelder minnehåndtering, prioritering av kommandoer og modus-setting. Andre funksjoner i X11 er overtatt av programvarebiblioteker for skrifttyper og 2D-grafikk: Cairo, pixman, FreeType, fontconfig, pango, etc. I stedet for at skrivebordsmiljøene foretar kall til X11, som igjen foretar systemkall til kjernen, er filosofien bak Wayland at skrivebordsmiljøene bør få aksess til disse spesialiserte funksjonene gjennom systemkall direkte til kjernen.
X11 har etterhvert utviklet en kompleksitet som omfatter kode-tabeller, glyf-rasterisering og overføring av disse til hurtigminnet, X logical font descriptions (XLFD), tegning av stiplete linjer, polygoner, buer og andre grafiske primitiver som ble introdusert på 1980-tallet. Alt dette må støttes for å hevde at et program er kompatibel med X11, selv om de færreste tar dette i bruk. Videre er X11 blitt forsøkt holdt moderne ved å tilføye utvidelser som XRandR, XRender og COMPOSITE; disse er beholdt i Wayland av kompatibilitetshensyn.
Wayland er ment å erstatte X11 og å tilby et raskere og enklere vindussystem. En rekke grafiske utviklingsbiblioteker støtter Wayland: GTK+ (fra versjon 3.10), Qt (fra versjon 5.0), Clutter, Enlightenment Foundation Libraries, Simple DirectMedia Layer (fra versjon 2.0.2), GLFW (fra versjon 3.1) og FreeGLUT. Det samme gjør en rekke skrivebordsmiljøer og grafiske skall. GNOME hadde eksperimentell støtte for Wayland i versjon 3.10, og fikk full støtte i versjon 3.12. KDE Software Compilation fikk full støtte fra versjon 5.7. MATE fikk støtte i versjon 1.12. Enlightenment støtter Wayland fra versjon E19 (0.19). Skrivebordsmiljøet Hawaii har eksklusiv støtte for Wayland. Glx-dock støtter Wayland fra versjon 3.4.

Oversikt over protokollen

Waylandprotokollen er blitt beskrevet som asynkron og objektorientert. Objektorientert betyr at tjenestene som tilbys av tjeneren er presentert som en serie objekter som lever på samme tjener. Hvert objekt implementerer et grensesnitt som har et navn, et antall metoder (kalt forespørsler) såvel som flere assosierte events. Hver forespørsel og event har null eller flere argumenter, hver enkelt har et navn og en datatype. Protokollen er asynkron fordi forespørsler ikke må vente på synkroniserte svar eller bekreftelser for å unngå round-trip delays og oppnå forbedret ytelse.
Klienter kan foreta en forespørsel (en metode invokasjon) på samme objekt hvis objektets grensesnitt er støttet av forespørselen. Klienten må også legge ved de påkrevde data for argumentene til slike forespørsler. Dette er måten klientene ber om tjenester fra tjeneren. Tjeneren i sin tur sender informasjon tilbake til klienten ved å forårsake objektet å sende events. Disse events kan utgå fra tjeneren som respons på en forespørsel, eller de kan sendes asynkront, på grunn av hendelser internt (utløst av en innmatningskilde, f.eks. en datamus eller et tastatur) eller tilstandsforandring. Feilbetingelsene blir også signalisert som en event av tjeneren.
For at en klient skal bli istand til å foreta en forespørsel til et objekt, trenger den først å meddele tjeneren ID-nummeret den vil bruke for å identifisere objektet. Det er to typer objekter i tjeneren: Globale objekter og ikke-globale objekter. Globale objekter blir kunngjort av tjeneren til klientene når de skapes (og også når de ødelegges), mens ikke-globale objekter vanligvis skapes av andre objekter som allerede eksisterer som en del av deres funksjonalitet.
Grensesnittet og deres forespørsler og events er kjerne-elementer som definerer Wayland-protokollen. Hver versjon av protokollen inkluderer et sett med grensesnitt, sammen med deres forespørsler og events, som er forventet å være i enhver Wayland compositor. Denne kan valgfritt implementere og definere deres egne grensesnitt med sine egne forespørspler og events, for å utvide funksjonaiteten ut over kjerneprotokollen. For å speile endringer mellom ulike versjoner av protokollen, inneholder grensesnitt et versjonsnr-attributt i tillegg til dets navn; dette attributtet tillater et grensesnitt å bli behandlet forskjellig fra tidligere versjoner av seg selv, med flere eller færre forespørsler og events. Hver tjener fremviser ikke bare grensesnittet, men også versjonen; og objektene implementerer en spesiell versjon av et grensesnittet.

Tilleggsgrensesnitt

En Wayland compositor kan definere og eksportere sine egne tilleggsgrensesnitt. Denne egenskap blir brukt til å utvide protokollen hinsides den grunnleggende funksjonalitet som er sørget for av kjernegrensesnittene, og har blitt standardmåten å implementere protokollens utvidelser på. Visse tjenere kan velge å tilføye grensesnitt som gir spesialiserte eller unike funksjoner. Wayland kan implementere dem som eksperimentelle grensesnitt for nye konsepter og ideer, hvorav noen senere kan bli en del av kjerneprotokollen (slik som wl_subsurface grensenittet som ble tilføyd i Wayland 1.4).