X Window Systemin ydinprotokolla

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 30. marraskuuta 2013 tarkistetusta versiosta . tarkastukset vaativat 18 muokkausta .

X Window Systemin pää (juuri)protokolla ( eng.  X Window System core protocol ) on rasterivideopäätteiden verkkoikkunajärjestelmän X Window -järjestelmän vuorovaikutuksen muoto . X-ikkuna perustuu asiakas-palvelin- malliin, eli yksi palvelin hallitsee kaikkia I/O:ita, kuten näyttö(t), näppäimistö ja hiiri, kaikki sovellukset toimivat asiakkaina, jotka ovat vuorovaikutuksessa käyttäjän ja muiden asiakkaiden kanssa palvelimen kautta. Tämän vuorovaikutuksen tarjoaa juuriprotokolla. On myös muita protokollia, jotka ovat sekä "lisäosia" juuren päällä että täysin itsenäisiä.

X Window Systemin juuriprotokolla mahdollistaa vain neljän tyyppisiä datapaketteja, jotka lähetetään asynkronisesti verkon yli: pyynnöt, vastaukset, tapahtumat ja virheilmoitukset. Asiakas lähettää palvelimelle pyynnöt suorittaakseen jonkin toiminnon (esimerkiksi luoda uuden ikkunan) ja/tai käskeä palvelinta lähettämään takaisin joitakin tietoja. Palvelimen vastaus varmistaa, että nämä tiedot välitetään asiakkaalle. Palvelin lähettää tapahtumat ilmoittamaan asiakkailleen käyttäjän toiminnasta tai muusta palvelinpuolen toiminnasta, josta tietty asiakas on kiinnostunut. Palvelin lähettää asiakkaalleen virheilmoitukset, jos asiakaspyyntöjen käsittelyssä ilmenee virheitä. Pyynnöt voivat tuottaa vastauksia, tapahtumia tai virheilmoituksia. Protokolla ei aseta pakollista järjestystä pakettien lähettämiselle verkon yli. Pääprotokollalle on laajennuksia, joissa on omat pyynnöt, vastaukset, tapahtumat tai virheilmoitukset.

System X ilmestyi MIT :ssä vuonna 1984 (X11:n nykyinen versio on syyskuussa 1987). Sen kehittäjä Bob Shifler ja Jim Geths ohjasivat sen kehittämisen aikana sääntöä, jonka mukaan juuriprotokollan tulisi luoda "mekanismi, ei joukko käytäntöjä". Tämän seurauksena juuriprotokolla ei määrittele asiakkaiden välistä vuorovaikutusta eikä asiakkaan ja käyttäjän välistä vuorovaikutusta. Niitä koskevat lisämääritykset [1] , kuten ICCCM ja Freedesktop.org , ja ne suoritetaan yleensä automaattisesti käyttämällä ennalta määritettyä widgetisarjaa .

Yleiskatsaus

Viestintä palvelimen ja asiakkaiden välillä tapahtuu vaihtamalla paketteja kanavan yli. Yhteyden muodostaa asiakas (protokollassa ei ole määritelty, kuinka asiakas aloittaa). Lisäksi asiakas lähettää ensimmäisen paketin, joka sisältää käytettävän lopputuloksen ja tiedot protokollan versiosta sekä asiakkaan odottaman autentikoinnin tyypin, palvelimen käytettäväksi. Palvelin vastaa lähettämällä takaisin paketin, joka vahvistaa tai kieltää yhteyden tai pyytää lisätodennusta. Jos yhteys vahvistetaan, dataa sisältävä paketti lähetetään asiakkaalle käytettäväksi myöhemmässä vuorovaikutuksessa palvelimen kanssa.

Kun yhteys on muodostettu, asiakkaan ja palvelimen välillä kanavan kautta vaihdetaan neljän tyyppisiä paketteja:

  1. Pyyntö: Asiakas pyytää tietoja palvelimelta tai pyytää toimintoa.
  2. Vastaa: Palvelin vastaa pyyntöön. Kaikki pyynnöt eivät tuota vastauksia.
  3. Tapahtuma: Palvelin ilmoittaa asiakkaalle tapahtumista, kuten näppäimistön tai hiiren syötöstä, ikkunan liikkeestä, koon muuttamisesta tai koko näytöstä jne.
  4. Virhe: Palvelin lähettää virhepaketin, jos pyyntö on virheellinen. Koska pyynnöt ovat jonossa, niiden luomia virhepaketteja ei voida lähettää välittömästi.

Pyynnöt ja vastaukset lähetetään eripituisina paketteina, kun taas tapahtuma- ja virhepakettien kiinteä pituus on 32 tavua .

Windows

Sitä, mitä useimmissa X Window Systemin graafisissa käyttöliittymissä kutsutaan ikkunaksi, kutsutaan huipputason ikkunaksi. Termiä ikkuna käytetään myös viittaamaan ikkunoihin, jotka sijaitsevat toisessa ikkunassa, eli pääikkunan aliikkunassa. Graafiset elementit, kuten painikkeet, valikot, kuvakkeet jne. voidaan toteuttaa aliikkunan avulla.

Asiakas voi pyytää ikkunan luomista. Tarkemmin sanottuna se voi pyytää aliikkunan luomista olemassa olevaan ikkunaan. Tämän seurauksena asiakkaiden luomat ikkunat järjestetään puuhun (hierarkiaan). Tämän puun juuri on juuriikkuna, joka on erityinen ikkuna, joka luodaan automaattisesti palvelimen käynnistyessä. Kaikki muut ikkunat ovat suoraan tai epäsuorasti juuriikkunan aliikkunoita. Ylätason ikkunat ovat juuriikkunan suoria aliikkunoita. Ilmeisesti juuriikkuna on samankokoinen kuin näyttö (vaikka se voi olla suurempi, jolloin käyttäjä voi siirtää näkyvää aluetta), ja se on kaikkien muiden ikkunoiden alla.

Ikkunan sisällön säilymistä ei aina taata ajan mittaan. Erityisesti ikkunan sisältö voi tuhoutua, kun ikkunaa siirretään, sen kokoa muutetaan, se peitetään muilla ikkunoilla ja yleensä tehdään kokonaan tai osittain näkymättömäksi. Erityisesti sisältö katoaa, jos X-palvelin ei tue ikkunan sisällön tallentamista apumuistiin. Asiakas voi pyytää ikkunan sisällön tallentamista apumuistiin, mutta palvelimen ei tarvitse tehdä niin. Näin ollen asiakkaat eivät voi olettaa, että lisämuistin tuki on olemassa. Jos ikkunan näkyvässä osassa on määrittelemätöntä sisältöä, tapahtuma lähettää asiakkaalle viestin, että ikkunan sisältö tulee piirtää uudelleen.

Jokaiseen ikkunaan liittyy joukko attribuutteja, kuten ikkunan geometria (koko ja sijainti), taustakuvat, pyydetäänkö se tallentamaan apumuistiin jne. Protokolla sisältää pyynnöt asiakkaalle tarkistaa ja muuttaa ikkunan attribuutteja .

Windows voi olla InputOutput tai InputOnly. Ensimmäisen tyyppisiä ikkunoita voidaan näyttää näytöllä ja käyttää piirtämiseen. Toisen tyyppisiä ikkunoita ei näytetä näytöllä, niitä käytetään vain syötteiden vastaanottamiseen.

Ikkunoiden ympärillä yleisesti näkyvät koristeelliset reunat ja otsikkorivin (mahdollisesti painikkeita sisältävä) luo ikkunanhallinta , ei ikkunan luova asiakas. Ikkunanhallinta hallitsee myös näihin elementteihin liittyviä syötteitä, kuten ikkunan koon muuttamista, kun käyttäjä napsauttaa ja vetää ikkunakehystä. Asiakkaat työskentelevät yleensä ikkunassa, ne luodaan ottamatta huomioon ikkunahallinnan tekemiä muutoksia. Harkitse myös niitä ikkunoiden hallintaohjelmia, jotka korvaavat yleisen pääikkunan ylätason ikkunoissa. Useimmat ikkunanhallintaohjelmat tekevät tämän nyt. Taustalla olevan protokollan näkökulmasta ikkunanhallinta on asiakas, kuten muutkin sovellukset.

Tietoja ikkunasta saa suorittamalla xwininfo-ohjelma. Kun tämä ohjelma ajetaan komentoriviltä argumentilla --tree, se näyttää ikkunasta aliikkunoiden puun sekä niiden tunnisteet ja geometriatiedot.

Pikselikartat ja piirustusalueet

Bittikarttakuva tallennetaan palvelimen muistiin, se ei näy näytöllä, vaan se voidaan piirtää kokonaan tai osittain ikkunaan. Ikkunan sisältö voidaan tallentaa bittikarttana. Tämä mahdollistaa kaksinkertaisen puskuroinnin. Windowsille soveltuvat grafiikkatoiminnot soveltuvat myös bittikarttoihin.

Ikkunoita ja bittikarttoja kutsutaan piirustusalueiksi. Piirustusalueiden sisältö tallennetaan palvelimelle. Asiakas voi lähettää pyynnön siirtää alueen sisältö palvelimelta asiakkaalle tai päinvastoin.

Graafiset kontekstit ja fontit

Asiakas voi pyytää useita grafiikkatoimintoja, kuten alueen tyhjennystä, alueen kopioimista toiseen, pisteiden, viivojen, suorakulmioiden ja tekstin piirtämistä. Raivauksen lisäksi kaikki toiminnot voidaan suorittaa kaikilla piirustusalueilla.

Useimmat graafisia operaatioita koskevat pyynnöt sisältävät graafisen kontekstin, tietorakenteen, joka sisältää parametrit graafisia operaatioita varten. Grafiikkakonteksti sisältää etualan värin, taustavärin, tekstin fontin ja muut asetukset. Grafiikkatoimintoja pyydettäessä asiakas sisällyttää grafiikan kontekstin. Kaikki grafiikan kontekstiasetukset eivät vaikuta toimintaan: esimerkiksi kirjasin ei vaikuta viivan piirtämiseen.

Ydinprotokolla velvoittaa käyttämään palvelinpuolen kirjasimia. Nämä kirjasimet tallennetaan tiedostoina, ja palvelin käyttää niitä suoraan paikallisen tiedostojärjestelmän kautta tai verkon kautta käyttämällä toista kirjasinpalvelimeksi kutsuttua ohjelmaa. Asiakas voi pyytää luettelon palvelimella olevista fonteista, pyytää lataamaan jonkin kirjasimen palvelimelle (jos sellaista ei vielä ole palvelimella) tai ladata fontin (jos muut asiakkaat eivät käytä sitä) palvelin. Asiakas voi pyytää tietoa kirjasimesta (esimerkiksi fontin noususta) ja tietyn rivin viemästä tilasta, kun se piirretään tietyllä kirjasimella.

Fonttinimet X Window -pääprotokollan tasolla ovat mielivaltaisia ​​merkkijonoja. X:n looginen kirjasinkäytäntö määrittelee tarkalleen, kuinka fontit pitäisi nimetä niiden attribuuttien mukaan. Nämä käytännöt määrittelevät myös lisäominaisuuksien arvot, joita kirjasimilla voi olla.

xlsfonts-ohjelma näyttää luettelon palvelimelle tallennetuista fonteista, näyttää kirjasinsymbolit ja antaa käyttäjän valita fontin nimen liitettäväksi toiseen ikkunaan.

Palvelinpuolen kirjasinten renderöintiä pidetään nyt vanhentuneena, ja useimmat asiakkaat (GTK, Qt) tekevät jo kirjasinten hahmontamista. Fonttien hahmontamiseen asiakkaat käyttävät Xft- tai cairo-kirjastoja ja XRender-laajennuksia. Ydinprotokollan määrittely ei kuvaa asiakaspuolen kirjasinten hahmontamista.

Resurssit ja tunnisteet

Kaikki tiedot ikkunoista, bittikartoista, fonteista ja muista objekteista tallennetaan palvelimelle. Asiakas tallentaa näiden objektien tunnisteet (yksilölliset numerot) ja käyttää niitä niminä ollessaan vuorovaikutuksessa palvelimen kanssa. Esimerkiksi asiakas, joka haluaa luoda ikkunan, lähettää palvelimelle pyynnön luoda ikkuna annetulla tunnuksella. Asiakas voi käyttää tunnistetta myöhemmin esimerkiksi pyytääkseen viivoja piirtämään ikkunaan. Seuraavat objektit on tallennettu palvelimelle ja ovat asiakkaan käytettävissä digitaalisten tunnisteiden kautta:

Näitä objekteja kutsutaan resursseiksi. Kun asiakas pyytää luomaan jonkin näistä resursseista, se määrittää myös sen tunnisteen . Esimerkiksi uuden ikkunan luomiseksi asiakas määrittää sekä ikkunan attribuutit (vanhemmat, leveys, korkeus ja niin edelleen) että ikkunaan liittyvän tunnisteen.

Tunnisteet ovat 32-bittisiä kokonaislukuja , joiden kolme tärkeintä bittiä ovat aina nolla. Jokaisella asiakkaalla on omat tunnuksensa, joita voidaan käyttää uusien resurssien luomiseen. Palvelin antaa tämän joukon kuittauspaketissa (asiakkaalle lähetetty paketti ilmoittamaan, että yhteys on hyväksytty) ja se esitetään kahdena numerona. Asiakkaat valitsevat tunnisteet tästä joukosta siten, että eri kohteilla on eri tunnisteet.

Kun resurssi on luotu, asiakas voi käyttää sen tunnusta pyynnöissä palvelimelle. Jotkut toiminnot vaikuttavat näihin resursseihin (esimerkiksi pyyntö siirtää ikkuna), muut palvelimelle tallennettujen resurssien pyynnöt (esimerkiksi ikkunan attribuuttien pyynnöt).

Tunnisteet ovat ainutlaatuisia paitsi asiakkaalle myös palvelimelle. Joten kahdella ikkunalla ei voi olla samaa tunnusta, vaikka ne olisivat luoneet kaksi eri asiakasta. Asiakas voi käyttää mitä tahansa objektia sen tunnisteen perusteella (jopa toisen asiakkaan objektiin).

Tämän seurauksena kaksi samaan palvelimeen yhdistettyä asiakasta voivat käyttää samaa tunnistetta viitatakseen samaan resurssiin. Jos asiakas esimerkiksi luo ikkunan, jonka tunnus on 0x1e00021, ja välittää sen numeron 0x1e00021 toiselle sovellukselle (millä tahansa käytettävissä olevilla tavoilla, kuten tallentamalla numeron tiedostoon, johon myös muut sovellukset pääsevät), tämä toinen sovellus voi toimia samalla ikkuna.. Tätä ominaisuutta käyttää esimerkiksi Ghostview -ohjelman X Window -versio : tämä ohjelma luo lapsiikkunan, tallentaa sen tunnisteen ympäristömuuttujaan ja kutsuu Ghostscriptiä , joka piirtää PostScript -tiedoston sisällön ja näyttää sen tässä ikkuna [8].

Resurssit tuhoutuvat yleensä sen jälkeen, kun ne luonut asiakas sulkee yhteyden palvelimeen. Ennen yhteyden sulkemista asiakas voi kuitenkin lähettää palvelimelle pyynnön olla tuhoamatta niitä.

Tapahtumat

Tapahtumat ovat palvelimen asiakkaalle lähettämiä paketteja, joissa on sanoma, että tapahtui mitä asiakas odotti. Esimerkiksi tapahtuma lähetetään, kun käyttäjä painaa näppäintä tai hiiren painiketta. Tapahtumia voidaan käyttää muuhunkin kuin vain syöttöön: tapahtumat esimerkiksi lähettävät osoituksen uusien aliikkunoiden luomisesta tiettyyn ikkunaan.

Jokainen tapahtuma liittyy ikkunaan. Jos käyttäjä esimerkiksi napsauttaa hiirtä, tapahtuma viittaa ikkunaan, jonka päällä kohdistin oli napsautuksen aikaan. Tapahtumapaketti sisältää tämän ikkunan tunnuksen.

Asiakas voi pyytää palvelinta lähettämään tapahtuman toiselle asiakkaalle. Tätä käytetään järjestämään asiakkaiden välistä vuorovaikutusta. Tällainen tapahtuma syntyy esimerkiksi, kun asiakas pyytää valittua tekstiä, ja palvelin lähettää sen asiakkaalle, joka omistaa valitun tekstin sisältävän ikkunan.

Palvelin lähettää tapahtuman Expose, jos asiakkaan ikkuna-alueen kuva on tyhjennetty muistista ja ikkuna tulee näkyviin. Ikkunakuva poistetaan muistista, jos ikkuna on pienennetty, peitetty toisella ikkunalla ja muissa tapauksissa.

Useimmat tapahtumatyypit lähetetään asiakkaalle vain, jos he ovat aiemmin ilmoittaneet kiinnostuksensa niihin. Asiakas voi esimerkiksi olla kiinnostunut näppäimistötapahtumista, mutta ei hiiritapahtumista. Tästä huolimatta tietyntyyppiset tapahtumat välitetään asiakkaille, vaikka he eivät niitä erikseen pyytäneet.

Asiakas valitsee tarvittavat tapahtumatyypit asettamalla erityisen ikkunaattribuutin - tapahtumamaskin. Esimerkiksi ikkunan sisällön piirtämisen aloittamiseksi asiakkaan on saatava Expose. Palvelin lähettää tämän tapahtuman kuitenkin vain, jos asiakas on asettanut oikean bitin ikkunan tapahtumamaskiin.

Eri asiakkaat voivat pyytää tapahtumia samasta ikkunasta. He voivat jopa asettaa eri tapahtumamaskeja samaan ikkunaan. Esimerkiksi yksi asiakas voi pyytää vain näppäimistötapahtumia, kun taas toinen voi pyytää vain hiiritapahtumia. On kuitenkin olemassa useita erilaisia ​​tapahtumia, jotka voidaan toimittaa vain yhdelle asiakkaalle. Nämä ovat erityisesti hiiren napsautusviestitapahtumia ja joitain ikkunoiden hallintaan liittyviä muutoksia.

xev- ohjelma, joka näyttää tapahtumia suhteessa ikkunaan. Erityisesti komento xev -id WIDkyselee kaikki mahdolliset tapahtumat ikkunassa tunnisteella WIDja tulostaa ne.

Esimerkkejä

Seuraavassa on esimerkki mahdollisesta vuorovaikutuksesta palvelimen ja ohjelman välillä, joka luo ikkunan mustalla laatikolla ja poistuu näppäinpainalluksistaan. Tässä esimerkissä palvelin ei lähetä vastausta, koska asiakas lähettää pyynnön, joka ei tuota vastauksia. Nämä kyselyt voivat aiheuttaa virheitä.

  1. Asiakas avaa yhteyden palvelimeen ja lähettää alkuperäisen paketin, joka ilmoittaa käyttämänsä tavujärjestyksen.
  2. Palvelin hyväksyy yhteyden (valtuutusta ei käytetä tässä esimerkissä) lähettämällä sopivan paketin, joka sisältää muita tietoja, kuten juuriikkunan tunnuksen (esimerkiksi 0x0000002b) ja tunnukset, jotka asiakas voi luoda.
  3. Asiakas pyytää luomaan oletusgrafiikkakontekstin tunnuksella 0x00200000 (tämä pyyntö, kuten muutkin tämän tyyppiset pyynnöt, ei esimerkiksi luo vastauksia palvelimelta).
  4. Asiakas pyytää palvelinta luomaan ylimmän tason ikkunan (eli se määrittää pääikkunan ylätason 0x0000002b), jonka tunnus on 0x00200001, koko 200x200, sijainti (10,10) jne.
  5. Asiakas pyytää ikkunan attribuutin muutosta 0x00200001, mikä osoittaa kiinnostusta Expose- ja KeyPress-tapahtumien vastaanottamiseen.
  6. Asiakas pyytää ikkunan 0x00200001 näyttämistä (eli se näytetään näytöllä).
  7. Kun ikkuna tulee näkyviin ja sen sisältö on piirrettävä, palvelin lähettää Expose-tapahtuman asiakkaalle.
  8. Vastauksena tähän tapahtumaan asiakas pyytää laatikon piirtämistä lähettämällä PolyFillRectangle-pyynnön, jonka ikkunatunnus on 0x00200001 ja grafiikkakonteksti 0x00200000.

Jos ikkuna menee päällekkäin toisen ikkunan kanssa eikä mene päällekkäin sen kanssa, jos taustavarastoa ei hallita, toimi seuraavasti:

  1. Palvelin lähettää toisen Expose-tapahtuman kertoakseen asiakkaalle, että sen ikkunaa piirretään uudelleen.
  2. Asiakas piirtää ikkunan uudelleen ja lähettää jälleen PolyFillRectangle-pyynnön palvelimelle.

Värit

Protokollatasolla väriä edustaa 32-bittinen etumerkitön kokonaisluku, jota kutsutaan pikseliarvoksi . Seuraavat elementit osallistuvat väriesitykseen:

  1. värisyvyys ( colordepth);
  2. värikartta ( colormap) - taulukko, joka sisältää värin punaisten, vihreiden ja sinisten komponenttien intensiteetin arvot;
  3. visuaalinen tyyppi ( visual type), joka määrittää, kuinka taulukkoa käytetään edustamaan värejä.

Yksinkertaisimmassa tapauksessa värikartta sisältää RGB-triadin peräkkäin. pixelvalue xon taulukon x:s rivi. Jos asiakas voi muuttaa värikartan merkintöjä, näkymä tunnistetaan visuaalisella luokalla PseudoColor . Visuaalinen luokka StaticColoron samanlainen, mutta asiakas ei voi muuttaa väritaulukon merkintöjä.

Saatavilla on yhteensä 6 visuaalista luokkaa. Jokainen on määritelty eri tavalla edustaa RGB-kolmiota pikseliarvolla. PseudoColorja StaticColorkaksi ensimmäistä. Seuraavat kaksi - GrayScaleja StaticGrayeroavat siinä, että niissä näkyy vain harmaan sävyjä.

Loput kaksi visuaalista luokkaa eroavat yllä olevista siinä, että ne eivät käytä pikseliarvokolmiota, vaan käyttävät kolmea eri taulukkoa punaisen, vihreän ja sinisen intensiteettiarvoille.

Värien esityksen mukaan pikseliarvo muunnetaan RGB-kolmioksi seuraavissa tapauksissa:

  1. pikseliarvo nähtiin bittijonona;
  2. tämä sekvenssi on jaettu kolmeen osaan;
  3. jokainen näistä kolmesta bitistä nähtiin kokonaisuutena ja käytettiin indeksinä arvon etsimiseen kustakin kolmesta erillisestä taulukosta.

Tämä mekanismi edellyttää, että värikartta koostuu kolmesta erillisestä taulukosta, joista kukin on yksi pääväreistä. Muunnoksen tuloksena on vielä kolme intensiteettiarvoa. Tämän näkymän käyttämät visuaaliset luokat ovat: DirectColortai TrueColor, jotka eroavat siinä, että asiakas voi muuttaa värikartan tai ei.

Kaikki nämä kuusi mekanismia värien esittämiseksi pikseliarvoilla vaativat joitain lisäparametreja toimiakseen. Nämä valinnat kerätään visuaaliseen tyyppiin , joka sisältää visuaalisen luokan ja muut värien esittämisvaihtoehdot. Jokaisella palvelimella on rajoitettu määrä asennettuja visuaalisia tyyppejä, ja jokaiseen tyyppiin on liitetty numeerinen tunniste. Tunnisteet ovat 32-bittisiä etumerkittömiä kokonaislukuja, mutta ne eivät välttämättä eroa resurssi- tai atomitunnisteista.

Kun yhteys hyväksytään asiakkaalta, palvelimelle lähetetty kuittauspaketti sisältää sarjan lohkoja, joista jokainen sisältää tietoa yhdestä näytöstä. Jokaiselle näytölle suhteelliset lohkot sisältävät luettelon muista lohkoista, jokainen suhteellinen lohko määrittää näytön tukeman värisyvyyden. Tämä luettelo sisältää kunkin värisyvyyden visuaaliset tyypit. Tämän seurauksena jokainen näyttö liittyy joihinkin mahdollisiin värisyvyysarvoihin ja kunkin näytön jokainen värisyvyys mahdollisiin visuaalisiin tyyppeihin. Näitä visuaalisia tyyppejä voidaan käyttää muille näytöille ja eri värisyvyyksille.

Jokaisen visuaalisen tyypin osalta kuittauspaketti sisältää molemmat nämä tunnisteet ja todelliset sisältöparametrit (visuaalinen tyyppi jne.) Asiakas tallentaa nämä tiedot, koska se ei voi pyytää näitä tietoja uudelleen tulevaisuudessa. Lisäksi asiakkaat eivät voi muuttaa tai luoda uusia visuaalisia tyyppejä. Uuden ikkunan luomista koskevat pyynnöt sisältävät värisyvyyden ja visuaalisen tyypin tunnisteen värien näyttämiseksi kyseisessä ikkunassa.

Värikarttoja käytetään näyttöä ohjaavasta laitteistosta riippumatta (eli näytönohjain voi käyttää palettia (väritaulukkoa) tai ei. Palvelimet käyttävät värikarttoja, vaikka laitteisto ei käyttäisi palettia. Kun laitteisto käyttää paletteja, rajoitettu määrä värikarttoja voidaan asentaa. Erityisesti värikartat asetetaan, kun laitteisto näyttää yhdenmukaiset värit. Asiakas voi pyytää palvelinta asentamaan värikartan. Tämä voi kuitenkin edellyttää toisen värikartan poistamista: poistetun värikartan käytön seurauksena kuva on väärillä väreillä, kaksinkertainen väripurskevaikutus tai voimakkaat värit. Tämä ongelma voidaan ratkaista käyttämällä vakiovärikarttoja. Nämä ovat värikarttoja, joissa on ennalta määritettyjä assosiaatioita pikseliarvojen ja värien välillä. Tämän laadun ansiosta vakiovärikarttoja voidaan käyttää erilaisissa sovelluksissa.

Värikarttojen luomista säätelee ICCCM-sopimus. Vakiovärikartat määritellään ICCCM- ja Xlib-spesifikaatioissa.

Osa X-värijärjestelmää on X Color Management System (xcms). Tämä järjestelmä ilmestyi X11R6 Release 5:n kanssa vuonna 1991. Tämä järjestelmä sisältyy useisiin Xlib-lisäominaisuuksiin, jotka löytyvät joukosta funktioita, joiden nimet alkavat Xcms:llä. Järjestelmä määrittelee laiteriippumattomat väriteemat, jotka voidaan jo muuntaa laitekohtaisiksi RGB-järjestelmiksi. Järjestelmä sisältää Xlib Xcms* -toiminnot sekä X Device Color Characterization Convention (XDCCC), joka kuvaa kuinka eri laiteriippumattomat värijärjestelmät muunnetaan laiteriippuvaisiksi RGB-värijärjestelmiksi. Tämä järjestelmä tukee CIEXYZ-, xyY-, CIELUV- ja CIELAB-värijärjestelmiä sekä TekHVC:tä.

Atomit

Ominaisuudet

Näytä

Kaappaa

Laajennukset

Valtuutus

Xlib ja muut asiakaskirjastot

Ei määritetty X Window Systemin juuriprotokollassa

Kirjallisuus

Linkit

Muistiinpanot

  1. Jim Gettys , Open Source Desktop Technology Road Map Arkistoitu 2006-01-02 .