Προς το περιεχόμενο

Wayland vs X


tr3quart1sta

Προτεινόμενες αναρτήσεις

Έξω από τις τεχνικές αδυναμίες του Xorg, το πραγματικό πρόβλημα του X Server, είναι ότι έχει ξεπεράσει σε σημασία ακόμα και τον Linux Kernel, ενώ παράλληλα είναι πολύ δεμένος μαζί του και τον αναγκάζει να εκτελεί εργασίες που δεν είναι αρμοδιότητα του. Ξέρετε τον Display Server του Android, του Mac, του iPad, των Windows? Όχι (εκτός αν είσαστε αρκετά Nerds!), αντίθετα όλοι γνωρίζουμε τον X Server γιατί απλά είναι υπεύθυνος για το 99% των φορών που δεν ξεκινάει το γραφικό περιβάλλον η κρασάρει.

 

brokenx.png

 

Ένα από τα πολλά μηνύματα λάθους που όλοι έχουμε δει!

 

Θα προσπαθήσω να περιγράψω την λειτουργία του X Server & Wayland (ώστε να δείτε τις διαφορές) όσο πιο απλά και σύντομα γίνεται. Θα παραλείψω αρκετές λειτουργίες και θα δώσω την γενική εικόνα πως λειτουργούν τα πράγματα. Εξάλλου όποιος ενδιαφέρεται περισσότερο θα ήταν καλύτερο να παραπεφθεί στα Official Documentation του Wayland και Xorg.

 

 

Πριν ξεκινήσω θα εξηγήσω κάποιους όρους που θα χρησιμοποιηθούν παρακάτω.

 

Display Server: O Display Manager. Το κομμάτι αυτό που είναι υπεύθυνο για την επικοινωνία Hardware+Kernel+Software με την οθόνη (Display) μας. Λέγεται Server γιατί εξυπηρετεί (Serves) πολλούς Clients.

 

Client: Με τον όρο Client αναφερόμαστε στις εφαρμογές που τρέχουν πάνω στον Server. Πχ, τον Nautilus, τον Firefox, η ακόμα και ολόκληρο το Gnome-Shell και ακόμα παραπέρα Client θα μπορούσε να είναι ένας άλλος Display Manager η Display Server που θα εξυπηρετούσε τους δικούς τους Clients. Όμως εδώ θα περιοριστούμε ότι Client είναι απλά μια εφαρμογή (Nautilus).

 

Compositor: Είναι το Software που είναι υπεύθυνο για να ζωγραφίζει τα γραφικά στην οθόνη μας. Πχ τοποθετεί τα παράθυρά, ζωγραφίζει UI E (User Interface Elements) -Buttons, Borders, Scrollbars κτλ. Ουσιαστικά είναι ο Window Manager, Mutter για το GNOME, Compiz για το Unity.

 

KMS (Kernel Mode Setting): Ορίζει την ανάλυση (Screen Resolution) (πχ 1680×1050) και το βάθος χρώματος (Color Depth) (πχ 32bit). Το Mode Setting μπορεί να παίζει στον Kernel (KMS) η στον User (UMS).

 

Buffer: Είναι μια περιοχή της μνήμης που αποθηκεύει προσωρινά, δεδομένα που μεταφέρονται από μια διεργασία σε άλλη. Πίο απλά είναι ένα Array που κρατάει διάφορες τιμές στην μνήμη οι οποίες μπορεί να αλλάξουν από ένα device input event. Πχ ένας Buffer που κρατάει την κίνηση του ποντικιού πάνω στην οθόνη σε μορφή άξονα x,y θα ήταν κάπως έτσι

Buffer = {X1,Y1,X2,Y2…..Xν,Yν}.

 

Draw – Update/Redraw: Όσοι έχουν κάνει Animation γνωρίζουν καλά τι είναι icon_smile.gif Για τους υπόλοιπους, όταν θέλουμε να ζωγραφίσουμε κάτι στην οθόνη (πχ ένα παράθυρο Nautilus) την πρώτη φόρα κάνουμε Draw. Αν το μετακινήσουμε (πχ drag με το ποντίκι) κάνουμε Redraw/Update. Παίρνουμε την τελευταία θέση του παραθύρου (Buffer1 [x, width, y, height]) και την μετακινούμε πχ ένα Pixel δεξία, τότε έχουμε (Buffer2[χ+1, width, y, height]). Σβήνουμε τον Buffer1 και κάνουμε Draw τον Buffer2. Αυτό χοντρικά είναι το Update.

Update γίνεται σε οτιδήποτε αλλάζει την γραφική κατάσταση στο παράθυρο. Πχ Mouse Over πάνω σε ένα Button που αλλάζει το χρώμα.

 

Event: Όταν μετακινούμε το ποντίκι η πατάμε ένα πλήκτρο στέλνουμε ένα Event στον Kernel ότι το πλήκτρο Χ πατήθηκε. Αντίστοιχα όταν κλικάρουμε ενα Button στέλνουμε ένα Event στον Display Server ότι το Button έγινε Pressed.

 

Damaged Event: Το Event στην δεύτερη περίπτωση από πάνω (αυτό που στέλνεται στον display server) μπορεί να αφορά ένα click σε ένα check box. Αυτό σημαίνει ότι ο Client θα πρέπει να γίνει Redraw. Έτσι το Event αυτό στέλνεται στον Compositor και όνομάζεται Damaged Event.

 

evden: Είναι το κομμάτι του Kernel που διαχειρίζεται τα Input Events (events από εξωτερικές συσκεύες, mouse, keyboard, joystic κτλ) και τα μεταφράζει σε events που γίνονται κατανοητά από τον Display Server (X Server, Wayland).

 

Scene Graph: Είναι η δομή που καθορίζει την λογική υπόσταση των γραφικών πάνω στην οθόνη μας. Κάτι σαν χαρτογράφηση (που είναι τι, τι μέγεθος έχει, κτλ) των Clients στον X Server.

 

Και μετά από το παραπάνω μπλα-μπλα, ας δούμε κάτι πιο ενδιαφέρον, πως διαχειρίζεται ο X Server και πως ο Wayland ένα Damaged Event. Για να είναι πιο κατανοητό θα χρησιμοποιήσω ένα σενάριο που έχουμε ανοίξει ένα παράθυρο Nautilus (αυτός είναι ο Client μας) και το κάνουμε Drug σε άλλο position (θέση) στο Desktop μας.

 

 

Στον Χ Server

 

 

 

x-architecture.pngX Server Architecture

 

 

 

 

 

1. Ο Kernel διαβάζει το Event από το Mouse και το στέλνει στον X Server από το evden input driver.

 

2. Ο X Server καταλαβαίνει σε ποίον Client απευθύνεται το Event και το στέλνει εκεί. Όμως ο X δεν ξέρει ποία είναι η θέση του Client πάνω στην οθόνη, γιατί αυτή διαμορφώνεται από τον Compositor και μπορεί να έχει αλλάξει κατάσταση.

 

3. Ο Client διαβάζει το Event και αφού βλέπει ότι πρέπει να γίνει Redraw (θυμηθήτε κάνουμε Drag τον Nautilus) στέλνει πάλι πίσω στον X εντολή για Rendering.

 

4. O X στέλνει την εντολή για Rendering στο Hardware (GPU) να κάνει το Rendering. Επίσης υπολογίζει τα όρια στα οποία πρέπει να γίνει το Rendering και τα στέλνει στον Compositor σαν Damaged Event

 

5. Το Damaged Event λέει στον Compositor ότι έχει αλλάξει η θέση του Nautilus πάνω στην οθόνη, και αυτό θα πρέπει να γίνει Redraw. O Compositor κάνει Rendering τα περιεχόμενα ολόκληρης της οθόνης (όλων των Clients) βασισμένο στο Screengraph που παρέχει ο Χ που σημαίνει ότι θα πρέπει να ξανα-εποικινωνήσει (!!) με τον X για να γίνει το Rendering

 

6. O X δέχεται την εντολή για Rendering από τον Compositor και αντιγράφει τον Buffer2 στον Buffer1 (παράδειγμα από τον Buffer πιο πάνω)

 

 

 

Στον Wayland ο Compositor είναι και ο Display Server. Ας δούμε το ίδιο παράδειγμα.

 

 

 

wayland-architecture.pngWayland Architecture

 

 

 

1. Ο Kernel παίρνει το Event και το στέλνει στον Compositor.

 

2. O Compositor καταλαβαίνει σε ποιον Client απευθύνεται το Event μέσω του Screengraph που κρατάει. Επίσης καταλαβαίνει τι αλλαγές πρέπει να γίνουν πάνω σε αυτό το Screengraph και τις εφαρμόζει.

 

3. Η αλλαγή έχει ήδη γίνει στον Client και ο Client απλά ενημερώνει τον Compositor ποία περιοχή έχει αλλάξει για να κάνει Update το Screengraph.

 

4. Ο Compositor παίρνει την εντολή από τον Client, κάνει Update το Screen και ενημερώνει τους buffers στον πυρήνα.

 

Ο X Server είναι απλά ένας μεσάζοντας ανάμεσα στις εφαρμογές και στον Compositor, και ανάμεσα στον Compositor και το Hardware. Δυο επιπλέον βήματα που δεν χρειάζονται

Και αυτό ακριβώς το πρόβλημα (που είναι ο λόγος 10άδων άλλων προβλημάτων) θα λύσει ο Wayland.

 

Επειδή η μετάβαση από τον X στον Wayland είναι τεράστια αλλαγή, και πολλά Toolkits δεν έχουν γίνει ακόμα Port (και κάποια δεν θα γίνουν ποτέ), θα πρέπει να επιτευχθεί ενα Backward Compatibility. O Wayland είναι αρκετά ευέλικτος για να μπορεί να τρέξει τον X σαν Client, και με την σειρά του ο Χ να τρέξει τους δικούς του Clients.

 

 

 

x-on-wayland.png

 

(via osarena.net)

  • Like 7
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημοσ. (επεξεργασμένο)

Γιατί τα X-Windows αναφέρονται ως "σύστημα";. Δεν είναι απλά το γραφικό περιβάλλον του Linux;

http://magaz.hellug.gr/35/01_X-Windows-1.html

 

Is Wayland network transparent?

http://wayland.freedesktop.org/faq.html#heading_toc_j_8

Επεξ/σία από sergyma
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • 2 χρόνια αργότερα...

Αυτο το έχω και εγώ απορια. Όσο και να έψαξα για το αν ο openbox θα γινει port στον Wayland, δεν βρηκα κάτι.

 

Έχουν δώσει κάπου καμια απαντηση για αυτο;

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • 1 μήνα μετά...

Απορια.

 

Για να δουλεψει μια εφαρμογη στον wayland, πρεπει να αλλαχτει κωδικας στην εφαρμογη ή στο toolkit (gtk qt κλπ) που αυτη χρησιμοποιει?

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Στα πιο διαδεδομένα toolkits (gtk, qt) αλλά και σε λιγότερο διαδεδομένα (EFL) έχει γίνει αρκετή δουλειά για υποστήριξη Wayland. Kαι τα 3 που ανέφερα, τρέχουν ούτως ή άλλως και σε λειτουργικά με διαφορετικά υποσυστήματα για γραφικά. Οι περισσότερες εφαρμογές μάλλον δεν θα χρειαστούν μεγάλες αλλαγές, εκτός και αν χρησιμοποιούν κατευθείαν τον X. Θα υπάρχει πάντως ο Xwayland - όπως στο OSX υπάρχει ο Xquartz- στον οποίο θα μπορούν να τρέχουν εφαρμογές (και wm) που δεν θα "μεταφερθούν" σε wayland.

  • Like 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Ο Χwayland είναι αναγκαίος, καθώς υπάρχουν εφαρμογές που χρησιμοποιούν tookits που δεν αναπτύσσονται πλέον και δεν θα δουλεύουν σε "καθαρό" wayland (π.χ. gtk2). Δεν ξέρω πόσο overhead θα έχει σε σχέση με την σημερινή κατάσταση, ο wayland όμως δουλεύει διαφορετικά από τον X, οπότε δεν αποκλείεται να είναι ασήμαντο...
Δεν γνωρίζω πόσες επεκτάσεις του X θα υποστηρίζονται από τον Xwayland (ότι σύχρονο έχει ο X είναι επέκταση, το κεντρικό πρωτόκολλο έχει σταματήσει να αναπτύσσεται στο τέλος της δεκαετίας του '80).
Η περσινή παρουσίαση του Daniel Stone με τίτλο "The real story behind wayland and X" είναι εξαιρετική πηγή πληροφοριών για τα σημερινή κατάσταση:

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • 10 μήνες μετά...

Κατέβασα το RebeccaBlackOS που έχει wayland, σε live cd, αλλά δε μου δούλευε το ποντίκι/πληκτρολόγιο.

KDE νομίζω έχει.

 

Πάντως και πάλι είναι σε εντελώς πρώιμο στάδιο η ανάπτυξη.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημοσ. (επεξεργασμένο)

Εντάξει είπα να δοκιμάσω κάποιο απο τα 5 live cds.

Στο arch, δοκίμασα με gdm και Gnome-Wayland επιλογή αλλά δεν με κάνει login, ενώ το gnome δουλεύει κανονικά χωρίς wayland.

Το wayland-launch από τερματικό, βγάζει error: "failed to choose egl config".

Θα δοκιμάσω τα git πακέτα από το aur.

Το weston μεσα σε kde δουλεύει, οκ, αλλά δεν είναι native και ό,τι εφαρμογή κι αν τρέξω, βγαίνει εκτός weston.

 

Συγκεκριμένα πανομοιότυπο με αυτό:

 

Date: 2013-04-18 EDT
[12:47:15.206] weston 1.1.0
               http://wayland.freedesktop.org/
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.1.0
               Build:  
[12:47:15.207] OS: Linux, 3.4.38-1-lts34, #1 SMP PREEMPT Wed Apr 3 17:36:42 EDT 2013, i686
[12:47:15.207] Loading module '/usr/lib/weston/drm-backend.so'
[12:47:15.208] initializing drm backend
[12:47:15.218] using /dev/dri/card0
[12:47:15.278] failed to choose EGL config
[12:47:15.278] EGL error state: EGL_SUCCESS (0x3000)
[12:47:15.278] failed to initialize egl
[12:47:15.322] fatal: failed to create compositor
Επεξ/σία από capthookb
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • 8 μήνες μετά...

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
  • Δημιουργία νέου...