Σε αυτό το άρθρο μαθαίνουμε τι είναι ο Wayland, τι ακριβώς προσφέρει και ποιες ειναι οι διαφορές του από τον X server που είναι υπεύθυνο για τα γραφικά σε όλες τις διανομές Linux. Στο τέλος, δίνουμε μερικά χρήσιμα links...
# Ας ξεκινήσουμε από τα βασικά. Τι είπαμε ότι είναι ο X server;
Ο Χ server είναι μια ανοικτού κώδικα υλοποίηση του X Window System (ή X11), ενός συστήματος και δικτυακού πρωτοκόλλου που ξεκίνησε από το MIT και στο οποίο βασίζονται τα γραφικά περιβάλλοντα του Unix και του Linux. O Χ server αναπτύσσεται από το Ίδρυμα X.org στο οποίο συμμετέχουν προγραμματιστές από εταιρείες όπως η Intel, η Red Hat, η Novell κλπ.
# Άρα ό,τι γραφικά βλέπουμε στο Linux οφείλονται στον X server;
Κατά βάση ναι. Το Χ11, και κατ' επέκταση ο X server, είναι περισσότερο ένα πρωτόκολλο για διασύνδεση μονάδων εισόδου με το γραφικό περιβάλλον και την οθόνη και καθορίζει μόνο μερικά πρωταρχικά στοιχεία γραφικών. Δεν ασχολείται με τη σχεδίαση (rendering) του γραφικού περιβάλλοντος, δηλαδή τα μενού, τα κουμπιά κλπ. Αυτή τη δουλειά την αναλαμβάνει ένα διαχειριστής παραθύρων όπως ο Kwin στο KDE, ο Metacity στο Gnome κλπ. Τα εφέ που έχουμε συνηθίσει να έχουμε στο Linux οφείλονται στους σύγχρονους “compositing” διαχειριστές παραθύρων. Αντίθετα με τους παλιούς διαχειριστές παραθύρων που σχεδίαζαν κάθε πρόγραμμα στο δικό του παράθυρο, οι compositing διαχειριστές παραθύρων συνδυάζουν τους buffers κάθε παραθύρου σε ένα μεγάλο framebuffer για όλη την οθόνη. Π.χ. o Κwin, ο Metacity και ο Compiz το κάνουν αυτό.
# Απ' όσο ξέρω, ο Χ δουλεύει μια χαρά τόσα χρόνια ακόμα και με τους νέους διαχειριστές παραθύρων. Γιατί να το αλλάξουμε;
Καταρχήν γιατί το X11 ξεκίνησε το 1984 και η υλοποίηση του X.org το 2004. Μεγάλα κομμάτια του Χ11 είναι σήμερα άχρηστα. Άσχετα όμως από την ηλικία του κώδικα, ο X server είναι τελικά πηγή προβλημάτων για το compositing, όπως πολύ εύστοχα αναλύεται και στη σελίδα του Wayland (goo.gl/gVm8S).
# Τι προβλήματα; Μια χαρά λειτουργεί το KDE μου...
Ο πιο απλός τρόπος να το καταλάβεις είναι να ακολουθήσεις ένα σήμα καθώς εισάγεται από μια συσκευή εισόδου (π.χ. το ποντίκι) μέχρι τη στιγμή που η αλλαγή θα φανεί στην οθόνη, όπως στο σχήμα 1.
# Δεν τα πάω καλά με τα διαγράμματα. Εξήγησέ μου τι ειναι αυτό που βλέπω...
Καταρχήν, το σήμα πηγαίνει από τον πυρήνα στο Χ server μέσω του driver evdev (βήμα 1). Ο πυρήνας Linux αναλαμβάνει το χειρισμό της συσκευής και τη «μετάφραση» του όποιου πρωτοκόλλου με το οποίο λειτουργεί εκείνη στο στάνταρ πρωτόκολλο του evdev.
Στη συνέχεια, παίρνει το λόγο ο X server. Η πρώτη του δουλειά είναι να καθορίσει το παράθυρο το οποίο σχετίζεται με το σήμα του χρήστη και να μεταφέρει το σήμα σε όλους του «πελάτες» (βήμα 2). Ο ίδιος ο X δεν θα μπορούσε να κάνει κάτι παραπάνω με το σήμα γιατί δεν γνωρίζει καν ποια είναι η ακριβής θέση και η γεωμετρία του παραθύρου στην οθόνη. Αυτό είναι δουλειά του compositor, του διαχειριστή παραθύρων που λέγαμε πριν, ο οποίος είναι υπεύθυνος για την θέση, τη γεωμετρία και τα εφέ κάθε παραθύρου.
Σε αυτό το σημείο ο πελάτης παίρνει το σήμα και αποφασίζει τι πρέπει να γίνει. Η πιο απλή περίπτωση είναι ότι κάτι θα πρέπει να αλλάξει στο γραφικό περιβάλλον. Π.χ. να τονιστεί το κουμπί πάνω από το οποίο βρίσκεται ο δείκτης του ποντικιού. Οπότε ο πελάτης στέλνει αυτό το αίτημα πίσω στον X server (βήμα 3).
O Χ server με τη σειρά του υπολογίζει την περιοχή που περικλείει την ζητούμενη αλλαγή στο παράθυρο και την στέλνει στον compositor για να κάνει το rendering, δηλαδή τη δημιουργία των γραφικών (βήμα 4).
Μόλις το αίτημα φτάσει στον διαχειριστή παραθύρων, αυτός προσδιορίζει ότι πρέπει να ανασυνθέσει το τμήμα εκείνο της οθόνης που περιλαμβάνει το παράθυρο. Το περίεργο είναι ότι ο compositor, αν και είναι υπεύθυνος για τη ανασύνθεση της οθόνης και των περιεχομένων των παραθύρων, πρέπει να στείλει το αίτημα για rendering πίσω στον X server (βήμα 5)!
Τέλος, μόλις ο X server λάβει το αίτημα για rendering συνήθως αντιγράφει τον back buffer του compοsitor στον framebuffer (βήμα 6). Αυτό το βήμα γίνεται για να ξέρει ο X server τι γίνεται με τα παράθυρα που πέφτουν το ένα πάνω στο άλλο. Είναι όμως άχρηστο βήμα γιατί πολύ απλά ο compositor τρέχει πάντα σε πλήρη οθόνη, και ξέρει ακριβώς που βρίσκονται τα παράθυρα.
# Δεν βρίσκω κάποιο ιδιαίτερο πρόβλημα. Απλώς μερικά παραπάνω βήματα...
Πες καλύτερα άχρηστα βήματα και είσαι μέσα! Ο X server δεν ξέρει ποιο ακριβώς παράθυρο θα λάβει τελικά το σήμα (π.χ. το βασικό παράθυρο μιας εφαρμογής ή ένας διάλογος που μόλις άνοιξε) ούτε μπορεί να μετασχηματίσει τις συντεταγμένες της οθόνης (π.χ. ότι ο δείκτης του ποντικιού βρίσκεται στο σημείο (400, 500)) σε συντεταγμένες παραθύρου. Στην πράξη, η επανασχεδίαση του τμήματος της οθόνης που αφορά το σήμα θα γίνει από τον compositor. Όμως, για κάποιον άγνωστο λόγο ο Χ κρατά υπό τον έλεγχό του τη διαδικασία...
# Ωπα! Σε λίγο θα μας πεις ότι και ο X server είναι άχρηστος...
Εν μέρει είναι! Πολλές από τις λειτουργικότητες που κάποτε ήταν προνομιακό πεδίο του Χ server έχουν πλέον μεταφερθεί στον πυρήνα Linux (π.χ. Kernel Mode Setting) ή σε ξεχωριστές βιβλιοθήκες. Να αναφέρω μερικές; evdev, mesa, freetype, Cairo, Qt, και πάει λέγοντας. Όπως πολύ εύστοχα το θέτει η τεκμηρίωση του Wayland, ο X server “είναι πλέον ένας διαμεσολαβητής που απλώς προσθέτει ένα επιπλέον βήμα ανάμεσα στις εφαρμογές και τον compositor αλλά και ένα έξτρα βήμα ανάμεσα στον compositor και το hardware”.
# Και ποια είναι η διαφορά του Wayland ;
Πολύ απλά: ο Wayland που δημιουργήθηκε από τον Kristian Hoegsberg ενοποιεί τον διαχειριστή παραθύρων με τον display server σε μία μονάδα. Έτσι ο έλεγχος του KMS και των σημάτων από τον evdev γίνεται από τον compositor, ο οποίος στέλνει απευθείας τα σήματα στους πελάτες του. Και αντίστροφα, οι πελάτες στέλνουν τα αιτήματά τους για rendering απευθείας στον compositor. Ο τρόπος λειτουργίας του Wayland φαίνεται στο παρακάτω διάγραμμα.
# Θα μας εξηγήσεις αυτό το διάγραμμα λίγο περισσότερο;
Aς τα εξηγήσω από την αρχή. Αρχικά (βήμα 1), ο πυρήνας παίρνει το σήμα από το evdev και το στέλνει απευθείας στον Wayland που είναι και display server και compositing διαχειριστής παραθύρων (για την ακρίβεια, ο compositor λέγεται Weston, στο μέλλον θα χρησιμοποιούνται και οι KWin, Mutter κλπ). Σημείωσε ότι δεν χρειάζεται να γράψουμε νέους drivers αφού ο Wayland είναι συμβατός με εκείνους του X server.
Έπειτα, ο compositor εξετάζει το σήμα και προσδιορίζει κατευθείαν ποιο παράθυρο θα λάβει το σήμα (βήμα 2). Κι αυτό γιατί γνωρίζει τα πάντα για τη θέση των παραθύρων, τη γεωμετρία τους και τους μετασχηματισμούς που έχουν υποστεί. Και με μια αντίστροφή των αρχικών μετασχηματισμών μπορεί άνετα να μεταφράσει τις συντεταγμένες της οθόνης (π.χ. τη θέση του δείκτη του ποντικιού) σε συντεταγμένες του συγκεκριμένου παραθύρου.
Στη συνέχεια το λόγο παίρνει κατευθείαν ο Wayland client (βήμα 3). Αυτός παίρνει το σήμα και προσδιορίζει ποια αλλαγή πρέπει να γίνει στο περιβάλλον της εφαρμογής, όπως θα γινόταν με τον Χ server. Σε αντίθεση όμως με τον X server, η σχεδίαση του παραθύρου γίνεται από τον ίδιο τον client! Ο τελευταίος απλώς ενημερώνει τον compositor για το ποια περιοχή της οθόνης άλλαξε (βήμα 4).
Τέλος, ο Wayland μαζεύει όλα αυτά τα αιτήματα από τους "πελάτες" (clients) του και ανασυνθέτει την οθόνη (βήμα 5).
# Δηλαδή οι clients θα κάνουν μόνοι τους πλέον τη σχεδίαση του παραθύρου τους;
Σχεδόν! Στην πράξη, ο Wayland ζητά από τον κάθε πελάτη να σχεδιάσει τον εαυτό του σε ένα bitmap. Στη συνέχεια, μαζεύει τα bitmaps από όλους τους πελάτες και ανασυνθέτει την ολική εικόνα του γραφικού περιβάλλοντος.
# Περίεργο. Νόμιζα ότι οι clients χρειάζονται τον Χ server για να κάνουν rendering...
Κι όμως υπάρχει και εναλλακτικός μηχανισμός που μάλιστα χρησιμοποιούμε ήδη και στο X: το direct rendering. Σε αυτήν την μέθοδο, ο client και ο server μοιράζονται το ίδιο buffer μνήμης. Ο πελάτης απλώς συνδέεται με μια υπάρχουσα βιβλιοθήκη σχεδίασης που ξέρει να χειρίζεται την κάρτα γραφικών (π.χ. την openGL) και κάνει το rendering απευθείας στο buffer. Ο compositor με τη σειρά του παίρνει τα περιεχόμενα του buffer και τα χρησιμοποιεί σαν “υφή” (texture) όταν ανασυνθέτει το γραφικό περιβάλλον. Από κάποιο σημείο και μετά, ο πελάτης λέει στον compositor μόνο ποιον buffer να χρησιμοποιήσει και πότε και που ακριβώς σχεδίασε νέα πράγματα εκεί.
# Αχά! Δηλαδή ο client απλώς ανανεώνει συνεχώς τα περιεχόμενα του ίδιου buffer;
Αυτός είναι ο ένας τρόπος, αλλά μπορεί να οδηγήσει σε προβλήματα και φλικαρίσματα της οθόνης αν o client κάνει rendering στον buffer την ώρα που ο compositor ανασυνθέτει όλη την επιφάνεια εργασίας. Αυτό λύνεται συνήθως με χρήση εφεδρικού buffer, στον οποίο κάνει rendering ο "πελάτης".
Υπάρχει και άλλος τρόπος: το νέο περιεχόμενο του παραθύρου να σχεδιάζεται απευθείας σε νέο buffer. Η εφαρμογή δημιουργεί νέο buffer για κάθε αλλαγή ή έχει δύο-τρεις buffers και τους εναλλάσσει κυκλικά. Η ουσία είναι ότι και στις δύο περιπτώσεις ο client ειναι υπεύθυνος για τη σχεδίαση, για τη διαχείριση της μνήμης αλλά και την ενημέρωση του compositor για το τι ακριβώς έχει αλλάξει στην οθόνη. Ο compositor δεν κάνει ποτέ ενημέρωση της οθόνης από μόνος του. Η γενική ιδέα είναι ότι ακόμα κι αν η εφαρμογή περάσει νέο buffer στον compositor, μπορεί να έχει αλλάξει μόνο ένα πολύ μικρό τμήμα μνήμης (π.χ. το χρώμα ή η θέση του κέρσορα), οπότε δεν χρειάζεται να ανανεωθούν τα πάντα..
# Καλά όλα αυτά, αλλά δεν χάνουμε τις δικτυακές δυνατότητες του X;
Σαφώς! Μια από τις αιτίες της αυξημένης πολυπλοκότητας του X server, ήταν οι προδιαγραφές του: έπρεπε να μπορεί να τρέχει μια εφαρμογή στον υπολογιστή (server) Α αλλά το παράθυρό της να σχεδιάζεται στον υπολογιστή (πελάτη) Β. Κι αυτό για να μπορεί να εξυπηρετεί απομακρυσμένους πελάτες που θα του ζητούσαν να σχεδιάσει για χάρη τους γραφικά. Προφανώς, οι σχεδιαστές του X11 είχαν στο μυαλό τους τις ανάγκες των thin clients, οι οποίοι τις δεκαετίες του '70 και του '80 μεσουρανούσαν: ο χρήστης θα μπορούσε να τρέχει την εφαρμογή του εξολοκλήρου στον server και να την προβάλλει στην οθόνη του thin client του με εκτέλεση μερικών Χ11 εντολών που λάμβανε μέσω του δικτύου.
# Ωραία. Πότε θα δούμε το Wayland στις διανομές Linux;
Βασικά ίσως να μπορείς να το δοκιμάσεις από τώρα, αν έχεις το θάρρος και το χρόνο να το στήσεις στη διανομή σου. Οδηγίες για να κάνεις build υπάρχουν στο site του Wayland - για τα αποτελέσματα μην ρωτάς!
To Gnome/GTK+ στο Fedora 19 υποστηρίζει το Wayland με την έννοια ότι μπορείς να τρέξεις τον Weston compositor ως X client με ελάχιστες ρυθμίσεις. Οι χρήστες του Arch Linux μπορούν να δουν αυτόν τον οδηγό εγκατάστασης του Wayland στο Arch.
Το σίγουρο είναι ότι το KDE και το Gnome κάποια στιγμή θα εγκαταλείψουν το X.org και θα περάσουν ολοκληρωτικά στο Wayland. To ίδιο θα κάνει και το Mate (δείτε εδώ ένα βίντεο). Επιπλέον, από την έκδοση KDE 4.11 και μετά, ο KWin έχει πειραματική υποστήριξη για τον Wayland. Δες εδώ έναν οδηγό για να τρέξεις το KDE Plasma desktop με τον Wayland. Τέλος, το Wayland έχει ήδη μεταφερθεί στο Raspberry Pi.
# Και με το Ubuntu τι έγινε; Γιατί δεν θα χρησιμοποιήσει το Wayland;
Αρχικά η Canonical και ο Mark Shuttleworth είχαν ανακοινώσει ότι θα το Ubuntu θα βασιστεί στον Wayland, αλλά τελικά ακύρωσαν τα πάντα και αποφάσισαν να φτιάξουν έναν νέο display server, τον Mir. To Mir σε μια light μορφή και περισσότερο για testing θα είναι διαθέσιμο στο Ubuntu 13.10.
# Για να τελειώνουμε. Πες μου με δύο λόγια τι είναι και τι προσφέρει ο Wayland;
Ο Wayland είναι ένας νέος display server. Το βασικό του πλεονέκτημα είναι ότι πρόκειται για σχετικά νέο project που αναπτύσσεται με βάση πρόσφατες τεχνολογίες γραφικών όπως το kernel modesetting. Το κυριότερο ειναι ότι ενσωματώνει έναν compositing διαχειριστή παραθύρων. Επιπλέον, οι developers του Wayland έχουν σκόπιμα αποφύγει να του δώσουν δικτυακές δυνατότητες. Δηλαδή, αντιθετα με τον X server, το μηχάνημα όπου τρέχει μια εφαρμογή δεν μπορεί να είναι διαφορετικό από το μηχάνημα που τρέχει o display server. Το αποτέλεσμα ειναι λιγότερη πολυπλοκότητα για τον Wayland.
- Συνδεθείτε ή εγγραφείτε για να σχολιάσετε
