Dansker hos Intel: Linux-grafik på vej mod et paradigme-skifte

Danske Kristian Høgsberg Kristensen fortæller her i et Version2-interview om arbejdet med en ny grafik-protokol til Linux, Wayland, som snart bliver standard i Ubuntu.

Der er noget i gære i fundamentet under de mange desktop-miljøer, der findes til Linux.

Hos Intel i USA sidder den 35-årige danske softwareudvikler Kristian Høgsberg Kristensen og arbejder på en ny grafisk protokol, Wayland, som kan vise sig at blive et opgør med den måde, desktop-miljøerne har fungeret på i årevis.

Blandt andet har selskabet bag Linux-distributionen Ubuntu, Canonical, besluttet, at Wayland på sigt skal bruges sammen med brugergrænsefladen Unity under Ubuntu.

Læs også: Ubuntu dropper Windows-look: Apples lækkerhed er det nye sort

Brugere af Linux vil formentlig kende til desktop-miljøerne Gnome og KDE, der er faste følgesvende til mange Linux-distributioner.

Alt efter brugerens temperament kan vinduesrammer, ikoner og knapper under Gnome og KDE variere lige så meget i form og farve som dyrene i en zoologisk have, så brugeren kan designe sin egen personlige skrivebords-oplevelse.

Fælles for dem er dog næsten altid displayserveren X.org, også kaldet X.

Den håndterer normalt input fra mus og keyboard, som den formidler videre til den såkaldte window manager, der står for selve placeringen og genoptegningen af vinduerne på skrivebordet.

Populært sagt er X bindeleddet mellem hardwaren og Linux-kernen, klientapplikationerne og window manageren, der opdaterer skrivebordet, når brugeren for eksempel lukker et vindue med et klik på krydset i hjørnet.

Men X har med fremkomsten af de nyere compositing window managers mistet en god del af sin eksistensberettigelse, mener i hvert fald en del af Linux-miljøet. Inklusive Kristian Høgsberg Kristensen.

Derfor har han arbejdet på Wayland siden 2008 ? først som ansat hos Red Hat, indtil han i november 2009 skiftede til Intel, som han stadig arbejder for hjemme fra privaten i Cambridge, Massachusetts i USA.

Waylands opgave er kort fortalt at tage X ud som et fordyrende mellemled i kommunikationen mellem hardware, klientapplikationer og window manager'en.

Kristian Høgsberg Kristensen (KHK) fortæller her i et e-mail-interview med Version2 om arbejdet med Wayland, som lige nu er hans fuldtidsbeskæftigelse.

V2: Forklar kort, hvad Wayland er? Hvordan adskiller Wayland sig fra X?

KHK: »Det er lidt vanskeligt at forklare, desværre.«

»Wayland er grundlæggende en protokol, der gør en håndholdt enhed eller et desktop-miljø (for eksempel brugergrænsefladen på en Meego-tavle-pc, Gnome Shell eller Ubuntu Unity) i stand til at blive en display-server og snakke direkte sammen med klientapplikationerne.«

»Wayland er ikke en ny display-server, som erstatter X. Men nutidens mobile brugergrænseflader og moderne desktop-miljøer bruger ikke længere ret meget af X, og derfor er X i stigende omfang en mellemmand, der står i vejen for desktop-shell'ens mulighed for at styre og udnytte hardware'en bedre.«

V2: Hvornår påbegyndte du udviklingen af Wayland, og hvilket behov var det, du gerne ville opfylde med Wayland?

KHK: »Wayland begyndte som et sideprojekt, da jeg arbejdede hos Red Hat. Jeg var på Red Hats X-team, hvor jeg arbejdede på at få en OpenGL-accellereret 'composited desktop' slået til som default.«

»I den klassiske model for X tegner X-serveren direkte til en 'front buffer'. Når et vindue flyttes, beder X-serveren klienten om et genoptegne det område (på desktoppen, red.), der blotlægges på skærmen.«

»Med en 'composited desktop' tegnes hvert vindue i sin egen buffer, og derefter er der et nyt trin, hvor compositor'en tager alle bufferne og tegner det endelige desktop-billede. Under X er compositor'en en ekstern proces, der modtager besked fra X-serveren, når en klient opdaterer sit vindue, og desktoppen skal genoptegnes.«

»Vi kom ret langt med arbejdet (hos Red Hat, red.), og den moderne Linux-desktop bygger på features som AIGLX og DRI2, som vi implementerede dengang. Men det stod også klart, at compositor'en overtog flere og flere af X's opgaver.«

»De få opgaver, som X stadig står for, håndteres bedre af compositor'en. Men det er for eksempel ikke lykkedes at udskille input-håndtering på en pæn og effektiv facon.«

»Alt i alt mener jeg, at det er rimeligt at kalde skiftet væk fra den klassiske X-model og over til en 'composited desktop' for et paradigmeskifte. Vi har været i stand til at gøre X-serveren moderne og relevant ved at tilføje udvidelser, men jeg mener, at tilføjelsen af en compositor er at gå for langt.«

»Vi kan ikke fremstille en ordentlig 'composited desktop', hvis ikke vi designer display-serverens arkitektur omkring compositor'en.«

»Det er det, vi forsøger at gøre med Wayland.«

V2: Hvad er de primære fordele ved Wayland sammenlignet med X?

KHK: »Det er en ny og meget enklere arkitektur, som sætter compositor'en i centrum.«

»Wayland er langt mindre, og den er ikke så meget en erstatning for X. Wayland fjerner derimod X fuldstændig og flytter de manglende brudstykker ind i compositor'en og klienterne.«

»Dermed får vi mulighed for at reducere X's rolle til at være en kompatibilitetsmulighed i stedet for at være en stor, obligatorisk komponent, som vi kun udnytter en brøkdel af.«

V2: Hvad er de vigtigste problemer/mangler, der pt. er forbundet med at
køre X som en klient til Wayland og omvendt, sammenlignet med at køre 'ren' X eller 'ren' Wayland?

KHK: »Vi kan køre Wayland som en X-klient, hvilket primært er godt til debugging, eller vi kan køre X under Wayland, som er den måde, hvorpå vi opretholder bagudkompatibiliteten med X-applikationer.«

»Integrationen på lav-niveau ? for eksempel at få X-applikationernes vinduer til at blive vist under Wayland og modtage input-events ? er mindre problematisk. Det store problem ligger i at få integrationen på højt niveau ? såsom copy-paste og drag-and-drop ? til at fungere sømløst mellem en X-applikation og en Wayland-applikation. Det samme gælder, når det kommer til at integrere en X-applikation med task-switcher'en i Wayland.«

V2: Hvordan er den aktuelle driverunderstøttelse for Wayland?

KHK: »Wayland har alle drivere til fælles med X. Det er det, der gør, at den overhovedet er et realistisk alternativ.«

»Modesetting (skift at skærmopløsning, red.) håndteres af Linux-kernen ganske som under X. Vi benytter de samme 3D-drivere som X, selvom Wayland tilgår dem gennem EGL og GLES2 i stedet for GLX og OpenGL.«

»Så alt, hvad der kan køre en moderne, 'composited' desktop under X, vil også kunne køre under Wayland. De fleste af de folk, der i dag arbejder på Linux-grafik, arbejder på 3D-driverne i Mesa eller driverne på kerne-siden. Alt det arbejde bruges både af Wayland og X.«

V2: Der har været stærke reaktioner mod Wayland i Linux-miljøet. Havde du ventet det på forhånd? I hvilket omfang er reaktionerne
berettigede?

KHK: »Nej, det er ikke overraskende. Når du ændrer noget i den måde, Linux fungerer på, vil det medføre stærke reaktioner fra nogen personer på nettet.«

»Det er klart, at dét at erstatte X er en af de ting, der fanger folks opmærksomhed, men jeg synes faktisk ikke, at der har været ret mange stærke reaktioner i mod Wayland.«

»Der har været talt meget om, hvordan og om Wayland skal håndtere 'remote displays', og der har været bekymring for, at det ikke kommer til at fungere, fordi det ikke er prioriteret i Waylands design.«

»Det kommer dog til at fungere fint, fordi vi bare kan føre Wayland-protokollen gennem en tunnel over TCP-protokollen eller lignende og sende komprimerede bitmaps i en kanal ved siden af.«

»Protokollen har ikke round trips og er derfor meget resistent over for latency, og faktisk er det ofte mere kompakt at sende komprimerede ændringer til et vindue i stedet for renderingskommandoerne.«

V2: Hvad har Mark Shuttleworths (stifter af Canonical, red.) udmeldinger omkring Wayland betydet for den fortsatte udvikling?

KHK: »Marks blogindlæg skabte en masse opmærksomhed og var en solid opbakning til projektet.«

»Det betyder, at folk ofte har hørt om Wayland og tager projektet seriøst, når man taler med dem. Så på den måde har det været en stor hjælp.«

»Bortset fra blogindlægget har jeg dog ikke hørt fra Canonical, men jeg er stadig optimistisk omkring, at de vil begynde at hjælpe, så snart de har fået deres nuværende release ud af døren.«

V2: Har du modtaget henvendelser fra andre distributioner/projekter i
open source-miljøet?

KHK: »Adam Jackson fra Red Hat har sagt, at de anser Wayland for at være en lovende teknologi til desktoppen i fremtiden.«

V2: Hvor meget tid bruger du selv på at udvikle på Wayland? Hvor langt
er Wayland fra at være klar til brug i egentlige
produktionsmiljøer?

KHK: »Jeg arbejder fuld tid på Wayland nu. Selve kernen i Wayland-protokollen har længe været på plads, men der ligger stadigvæk arbejde i input-håndteringen.«

»På nuværende tidspunkt ligger den primære arbejdsopgave dog i at integrere Wayland med de eksisterende desktopmiljøer og -toolkits.«

»For eksempel kan Wayland allerede meget af det, der er brug for ved Meegos brugergrænseflade til tavle-pc'er. Men der skal meget arbejde til omkring brugergrænsefladen og Qt-framework'et for at få Meego-brugergrænsefladen til at køre under Wayland.«

»Det samme gælder for andre desktop-miljøer som Gnome Shell, Ubuntu Unity eller KDE: Afhængigheden af X er allestedsnærværende.«

»Selv hvis Wayland var færdigudviklet i dag, ville der stadig ligge masser af arbejde gemt i at flytte de desktop-miljøer fra X og over på Wayland.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kenni Lund

Svarer han ikke på det her?

»Der har været talt meget om, hvordan og om Wayland skal håndtere 'remote displays', og der har været bekymring for, at det ikke kommer til at fungere, fordi det ikke er prioriteret i Waylands design.«

»Det kommer dog til at fungere fint, fordi vi bare kan føre Wayland-protokollen gennem en tunnel over TCP-protokollen eller lignende og sende komprimerede bitmaps i en kanal ved siden af.«

Er der i praksis nogen som benytter X client/server modellen over et netværk i dag? Jeg synes altid at performance har været for dårlig til at det kan bruges andre steder end i et hurtigt LAN. Så snart at vi bevæger os ud i WAN, evt. over VPN/SSH, så bliver performance ofte for dårlig til at det kan benyttes i praksis. Her lammetæver en VNC-server ovenpå X fuldstændig den gammeldags løsning med X server/client eller X-forwarding af et individuelt program over SSH.

  • 0
  • 0
Maciej Szeliga

Er der i praksis nogen som benytter X client/server modellen over et netværk i dag? Jeg synes altid at performance har været for dårlig til at det kan bruges andre steder end i et hurtigt LAN. Så snart at vi bevæger os ud i WAN, evt. over VPN/SSH, så bliver performance ofte for dårlig til at det kan benyttes i praksis. Her lammetæver en VNC-server ovenpå X fuldstændig den gammeldags løsning med X server/client eller X-forwarding af et individuelt program over SSH.

Ja, det er der over ssh og performance er ikke noget specielt issue, jeg spiller ikke "whatever det grafiktungeste spil pt. hedder" over X. Det her viser problemet med at forstå hvad X gør og hvorfor den anden måde at gøre det på (vnc, rdp mv.) ikke kan sammenlignes.

  • 0
  • 0
Hans Schou

Kenni Lund,

Er der i praksis nogen som benytter X client/server modellen over et netværk i dag?

Jeg har brugt X til at konfigurere en VirtualBox på en server i Tyskland, men når først den er oppe at køre, så er det VBoxHeadless med en VNC. Det fungerer fint selv om det er langsomt, da det jo ikke er særligt meget X jeg reelt bruger.

  • 0
  • 0
Jarnis Bertelsen

Vi vil ikke undvære FUNKTIONALITET som vi rent faktisk bruger for at nogen (ikke specielt veldefineret gruppe) skal få lidt hurtigere grafik.

Man kunne også sige "Vi vil ikke undvære PERFORMANCE for at bevare en funktionalitet som kun få benytter og som i langt de fleste tilfælde vil kunne erstattes af anden teknologi (læs vnc)". Jeg tror du skal definere dit "Vi" for at dit udsagn holder vand Maceij.

  • 0
  • 0
Maciej Szeliga

Klager ang. PERFORMANCE kan rettes til spaderne hos nVidia og ATI, grafisk performance på Linux er primært et driverissue. "Vi" er dem som ikke lige tilfældigvis leder efter en erstatning for Windows spillemaskinen, der er meget få andre steder hvor X er et reelt performanceproblem. "Vi" er dem som ikke vil køre Linux alt for langt væk fra UNIX fordi vi vil undgå porteringsproblemer, det er os som kører Oracle, DB2, Domino, SAP mv. på Linux, det er os som betaler for SLES og RHEL.

  • 0
  • 0
Log ind eller Opret konto for at kommentere