Wayland
vis serverprotokoll for Linux-skrivebordet From Wikipedia, the free encyclopedia
Remove ads
Wayland er et fritt og åpent vindussystem for Unix og Unix-liknende operativsystemer. Det er en direkte etterfølger til vindussystemet X (X11). Det består av en kommunikasjonsprotokoll mellom en vindustjener og dens klienter, og er implementert i programmeringsspråket C.[5]
Linuxkjernen og derivater av Berkeley Software Distribution (BSD) har i årenes løp overtatt mange av oppgavene til X11, deriblant minnehåndtering, prioritering av kommandoer og modus-setting. Andre funksjoner er overtatt av programvarebiblioteker for skrifttyper og 2D-grafikk. Wayland overlater disse oppgavene til operativsystemkjernen og biblioteker, og er derfor både enklere og raskere enn X11. Mange skrivebordsmiljøer som opprinnelig benyttet X11 som en mellomliggende prosess utenfor operativsystemkjernen, har etterhvert gått over til å støtte Wayland.
Wayland er blitt tatt i bruk av FreeBSD, DragonFly BSD og av ledende Linuxdistribusjoner som Slackware, Debian, Gentoo, openSUSE, Fedora, OpenMandriva Lx og Arch Linux. Ubuntu benyttet vindustjeneren Mir fra versjon 13.10, men gikk over til Wayland i versjon 18.04.
Wayland blir utviklet av freedesktop.org under ledelse av danske Kristian Høgsberg.[6] Kildekoden er åpent tilgjengelig under MIT-lisensen.[7] Første versjon ble lansert 9. februar 2012. Siste versjon er 1.23.1 som ble lansert 24. august 2024.
Remove ads
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.
② Wayland compositor ser gjennom sin scenegraf for å avgjøre hvilket vindu som skal motta den aktuelle event. Den velger rett vindu og transformerer skjermkoordinatene til vinduets logiske koordinater ved å foreta inverse transformasjoner.
③ Når klienten mottar den aktuelle event, oppdaterer den brukergrensesnittet som respons. Renderingen finner sted av klienten via EGL, og klienten sender en indikasjon tilbake til compositor for å indikere at regionen ble oppdatert.
④ Wayland compositor samler skademeldinger fra dets klienter og deretter rekomponerer skjermen. Den kan deretter direktle sende systemkallet ioctl for å skedulere en pageflip med KMS.
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.[8] 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.[9] 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.[9] Videre er X11 blitt forsøkt holdt moderne ved å tilføye utvidelser som XRandR, XRender og COMPOSITE;[9] 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.
Remove ads
Arkitektur
Protokollens arkitektur
Protokollen til Wayland kalles Weston. Den følger en klient-tjener modell hvor klienter er grafiske applikasjoner som ber om piksel-buffer på skjermen, og tjeneren (compositor) er den som kontrollerer dette bufferet.
Waylands referanseimplementasjon har blitt designet som en to-lags protokoll:[10]
- Et lavnivå lag som håndterer interprosesskommunikasjon (IPK) mellom de to involverte prosesser – klienten og tjeneren – og marshalling av de data de utveksler. Dette laget er meldingbasert og vanligvis implementert ved å bruke operativsystemkjernens IPK tjenester, spesielt Unix domain sockets i tilfellet med Linux og Unix-liknende operativsystemer.[11]
- Et høynivå lag bygd over det, som håndterer informasjonen som klienten og tjeneren behøver for å implementere de grunnleggende egenskapene ved et vindussystem. Dette laget er implementert som en asynkron objektorientert protokoll.[12]
Mens lavnivå laget ble skrevet manuelt i C, er høynivålaget automatisk generert fra en beskrivelse av elementer av protokollen som er lagret i XML.[13] Hver gang protokollbeskrivelsen i denne XML-filen forandrer seg, kan C-koden som implementerer en slik protokoll bli regenerert for å inkludere de nye forandringene. Referanseimplementasjonen av protokollen til Wayland er delt i to biblioteker. Biblioteket som håndterer klienter kalles libwayland-client og biblioteket som håndterer tjenere kalles libwayland-server.
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.[12] 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.[12]
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.[12] 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.[14]
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.[15] 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.[16]
Kjernegrensesnitt
Filprotokollen /wayland.xml[13] er en XML-fil som lister grensesnitt sammen med deres forespørsler, events og andre attributter. Dette sett av grensesnitt er minimum som er påkrevd for å implementere en Wayland compositor.
Noen av de mest grunnleggende grensesnitt er:[15]
- wl_display – det sentrale globale objekt, et spesielt objekt som innkapsler Wayland-protokollen selv
- wl_registry – det globale registerobjekt, hvor tjenerens registrerer alle globale objekter som den ønsker skal være tilgjengelig for alle klienter
- wl_compositor – et objekt som representerer tjeneren, og som kombinerer forskjellige grensesnitt til et enkelt output
- wl_surface – et objekt som representerer et rektangulært område på skjermen, definert av en lokasjon, størrelse og pikselinnhold
- wl_buffer – et objekt som, når det er tilknyttet et wl_surface objekt, gir et visbart innhold
- wl_output – et objekt som representerer det visbare området på skjermen
- wl_pointer, wl_keyboard, wl_touch – objekter som representerer ulike utstyr for innmatning, som pekere og tastatur
- wl_seat – et objekt som representerer et sete (et sett med utstyr for innmatning/utmatning) i multisetekonfigurasjoner
En typisk Wayland klient sesjon starter ved å åpne en forbindelse med tjeneren ved å bruke objektet wl_display. Dette er et spesielt lokalt objekt som representerer forbindelsen og ikke lever sammen med tjeneren. Ved å bruke dets grensenitt kan klienten sende forespørsler til det globale objektet wl_registry i tjeneren, hvor alle de globale objektnavnene lever, og binde de som klienten er interessert i. Vanligvis binder klienten minst et wl_compositor objekt, hvorfra det vil be om et eller flere wl_surface objekter for å vise output på skjermen.[14]
Tilleggsgrensesnitt
En Wayland compositor kan definere og eksportere sine egne tilleggsgrensesnitt.[15] 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[17]).
Utvidelser til kjerneprotokollen
Remove ads
Versjonshistorikk[18]
Remove ads
Se også
Referanser
Eksterne lenker
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads