Bufor ramki w Linuksie 10


KNOPPIX_bootingOstatnimi czasu zarówno w prasie poświęconej Linuksowi, jak i na forach internetowych o tej tematyce panuje wzmożona dyskusja na temat serwerów wyświetlania: X-Server, Mir, Wayland, jak i ciągłe porównywanie zamkniętych sterowników do kart graficznych z ich otwartymi odpowiednikami opartymi o DRM (Direct Rendering Manager). Ten artykuł nie będzie jednak bezpośrednio nawiązywał do tej tematyki. Skupię się w nim natomiast na innym podsystemie odpowiedzialnym za wyświetlanie obrazu, który niemalże od zawsze towarzyszy Linuksowi, a o którego istnieniu zapewne większość z was nawet nie słyszała. Mowa tu o buforze ramki.

 

Czym jest bufor ramki?

 

Już pierwsze układy graficzne dla komputerów IBM-PC były przystosowane do pracy w dwóch trybach: tekstowym i graficznym. Ten pierwszy był wykorzystywany do pracy w systemie operacyjnym DOS i Unix/Linux, natomiast z tego drugiego korzystały gry i aplikacje graficzne. Tryb tekstowy bardzo upraszczał metodę wyświetlania grafiki. System po prostu informował kartę graficzną po kolei jakie znaki ma wyświetlać, a firmware układu graficznego wyświetlał pola z tymi znakami zgodnie z pewnymi standardami. Do dziś na tej zasadzie działa między innymi wyświetlanie grafiki w BIOS-ie. Jednak nawet jeżeli ktoś oczekuje po systemie jedynie sprawnej pracy w terminalu, to tryb tekstowy wiązał się z wieloma ograniczeniami: nie pozwalał na wyświetlanie znaków diakrytycznych, nie pozwalał na modyfikację rozdzielczości, czy częstotliwości wyświetlania oraz dostarczał bardzo ograniczoną gamę barw. Jednak prawdziwe problemy pojawiły się na komputerach, które nie obsługiwały trybu tekstowego (Apple Macintosh). W konsekwencji programiści Linuksa postanowili zbudować zaawansowany podsystem do obsługi trybu graficznego.

 

Podsystem ten został nazwany buforem ramki (fbdev, framebuffer). Zgodnie z uniksową zasadą „wszystko jest plikiem” tworzył on plik /dev/fb{n} , gdzie {n} to numer przypisywany dla każdej podłączonej karty graficznej. Plik ten można edytować jak każdy normalny plik tekstowy zapisując w nim wartości barwy dla pikseli, które następnie są wyświetlane na ekranie. Oczywiście nikt ręcznie nie będzie zapisywał tego pliku. Szybko powstały dodatkowe mechanizmy i biblioteki umożliwiające automatyczne zapisywanie i odczytywanie pliku, a które zaczęto powszechnie stosować do wyświetla grafiki na ekranie. To rozwiązanie stało się powszechnie stosowane do emulowania terminalu tekstowego w trybie graficznym. Tak emulowany terminal może wyświetlać tekst w wysokiej rozdzielczości, ze znakami diakrytycznymi i w pełnej palecie barw. Pozwala też na wyświetlanie obrazów w terminalu, a nawet oglądanie filmów przy pomocy np. MPlayera.

 

W czasach powstawania fbdev były już dostępne pewne standardy (VGA, VESA), z którymi były zgodne karty graficzne. Powstały więc sterowniki (vesafb, vga16fb) wykorzystujące ich możliwości. Sterowniki te pozwalały nie tylko na wyświetlanie pikseli odpowiednich kolorów, ale także pozwalały ustawić np. rozdzielczość ekranu i częstotliwość odświeżania. Z biegiem czasu powstawały dalsze sterowniki przystosowane już do korzystania z możliwości konkretnych kart graficznych. Wprowadzono też proste metody akceleracji, takie jak zapełnienie danego obszaru jedną barwą. Nawet zyskujący coraz bardziej na popularności X-Server zyskał sterownik xf86-video-fbdev, który umożliwił mu korzystanie z bufora ramki.

 

Jednak w miarę jak graficzna obsługa komputerów stawała się coraz popularniejsza, projektowe wady buforu ramki stawały się coraz wyraźniejsze. Jak nietrudno się domyśleć, zapisanie wszystkich wartości pikseli pliku /dev/fb0 na komputerze z ekranem o wysokiej rozdzielczości jest dużym wyzwaniem, a proces ten należy powtarzać wielokrotnie w ciągu każdej sekundy, żeby zachować wrażenie płynności wyświetlania. Architektura sterowników też nie ułatwiała zadania, gdyż zapewniają one jedynie skromne możliwości akceleracji 2D i zero możliwości akceleracji 3D. Nic więc dziwnego, że zarówno NVIDIA, jak i ATI postanowiły zapewnić wsparcie dla linuksowego desktopu nie korzystając z bufora ramki. W tym celu ich zamknięte sterowniki zostały przystosowane do działania w przestrzeni użytkownika, gdzie dokonują całej akceleracji a także zajmują się pełną obsługą układu. Podobne podejście przyjęli również developerzy otwartych sterowników do kart graficznych, opierając je na architekturze DRI1. W późniejszym okresie uznano, że nie jest to najlepsze rozwiązanie. Stworzono DRI2, w którym niskopoziomową obsługę kart graficznych przeniesiono do jądra systemu i nazwano DRM. Poza swoimi podstawowymi zadaniami DRM zapewnia też kompatybilne API dla fbdev, co pozwala na przejęcie jego zadań. Bufor ramki na desktopach odszedł niemalże zupełnie w odstawkę.

 

Gzie i po co się go stosuje?

 

Jednak desktopy to nie jest główny rynek Linuksa. Bufor ramki nadal jest chętnie stosowany w wielu innych segmentach. W przypadku serwerów korzystanie z X-Servera, jak i zamkniętego oprogramowania (w tym sterowników) jest potencjalną luką w bezpieczeństwie. Jednak konsola tekstowa o wysokiej rozdzielczości, czy inne dobrodziejstwa płynące z trybu graficznego są nadal wysoce pożądane. Na tym rynku fbdev to powszechna technologia, a producenci układów graficznych dla tego segmentu nadal rozwijają swoje sterowniki buforu ramki.

 

Także producenci systemów wbudowanych chętnie korzystają z buforu ramki. Dzięki temu mogą zbudować minimalistyczne jądro Linuksa, a do wyświetlania grafiki nie muszą korzystać z X-Servera. W ten sposób na urządzeniu o bardzo ograniczonych zasobach nadal można korzystać z Linuksa i trybu graficznego.

 

Jednak szczególnie poważne zastosowanie bufor ramki znajduje wśród producentów telewizorów. Wyświetlanie obrazu na telewizorze, to przecież nic innego, jak umiejscowienia pikseli o odpowiednich kolorach w odpowiednich miejscach. Nie może być tu przecież mowy o jakiejkolwiek akceleracji grafiki, a w związku z tym nie trzeba nawet marnować zasobów systemu na uruchamianie X-Servera.

 

Jaka czeka go przyszłość?

 

W miarę jak technika idzie do przodu, rosną też oczekiwania względem możliwości telewizorów. Na szczególną uwagę zasługują tu działania Philipsa, który stał się głównym motorem rozwojowym DirectFB, z powodzeniem przez nich stosowanego. DirectFB to prosta biblioteka stanowiąca interfejs dla sterowników bufora ramki. Zapewnia ona możliwości serwera wyświetlania z prawdziwego zdarzenia, a ponadto może korzystać z akceleracji 3D przy pomocy Mesa. DirectFB niewątpliwie stanowi przyszłość bufora ramki, a jego możliwości pozwalają niwelować ograniczenia fbdev przy jednoczesnym zachowaniu minimalistycznego podejścia.

 

Jednak nad buforem ramki zbierają się ciemne chmury. Programiści jądra Linuksa coraz częściej wyrażają pogląd, że nie podoba im się posiadanie dwóch zestawów sterowników do jednego sprzętu (DRM i fbdev), a w konsekwencji proponują całkowite usunięcie buforu ramki. W tym celu pracuje się nad stworzeniem minimalistycznego sterownika DRM, który mógłby obsługiwać wszystkie układy graficzne (najprawdopodobniej zgodnie ze standardem VESA). Proponuje się też stworzenie nowego emulatora terminala, który pracowałby w przestrzeni użytkownika i korzystał z DRM. Także Wayland ma się stać serwem wyświetlania, z którego bezpiecznie będzie można korzystać zamiast DirectFB. Po tych zabiegach będzie można najprawdopodobniej usunąć cały podsystem bufora ramki tak, żeby użytkownicy tego nie odczuli. Programiści Intela już nawet wyrazili chęć usunięcia kompatybilności ich sterowników DRM z fbdev, ale na razie ta prośba nie została wysłuchana. Przyszłość bufora ramki stoi więc pod wielkim znakiem zapytania, a czas pokaże jaki los spotka ten pierworodny podsystem do obsługi trybu graficznego.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

10 komentarzy do “Bufor ramki w Linuksie

  • mr_x

    Ja słyszałem o buforze ramki, ale nie znałem jego całej fascynującej historii.

    Artykuł bardzo ciekawy i czekam na więcej tego typu wiadomości.

  • salvadhor

    Nic nie wymaga tak gruntownej przebudowy, jak system i podsystem wyświetlania w Linuksie 🙂

    Dzięki teoretyzowaniu deweloperów, zamiast praktycznego podejściu do tematu, w XXI wieku Linux bez sterowników 3d nie potrafi rysować pulpitu i przemieszczać okien bez ‚rwania’ się ramek, czyt. – totalnie bez synchronizacji i jakiegoś buforowania. To paranoja, żeby na potrzeby estetycznego biurka trzeba było instalować zamknięte sterowniki, angażować do pracy GPU, itp. Zauważcie – wszystkie te peany na temat ‚śmigającego Linuksa’ dotyczą coraz mocniejszych konfiguracji sprzętowych. Optymalizacja poszła w las, skoro wygodniej jest zarządzić, że system ‚nie pójdzie’ poniżej 1GB i iluś tam GHz procesora.

    Środowiskom minimalistycznym jak Xfce i LXDE brakuje tylko tego ‚czegoś’, żeby się ładnie i szybko okna rysowały. O dziwo, do przodu są tutaj wolne sterowniki ATI, o ile akurat ma się obsługiwaną przez nie kartę gfx.

  • nycko

    Świetnie się czyta Pańskie artykuły. Wiem, że wakacje, że sezon ogórkowy, itp. itd., ale b. proszę CZĘŚCIEJ mnie dokarmiać fachową wiedzą!

  • sda

    [quote comment=”53857″]Nic nie wymaga tak gruntownej przebudowy, jak system i podsystem wyświetlania w Linuksie 🙂

    Dzięki teoretyzowaniu deweloperów, zamiast praktycznego podejściu do tematu, w XXI wieku Linux bez sterowników 3d nie potrafi rysować pulpitu i przemieszczać okien bez ‚rwania’ się ramek, czyt. – totalnie bez synchronizacji i jakiegoś buforowania. To paranoja, żeby na potrzeby estetycznego biurka trzeba było instalować zamknięte sterowniki, angażować do pracy GPU, itp. Zauważcie – wszystkie te peany na temat ‚śmigającego Linuksa’ dotyczą coraz mocniejszych konfiguracji sprzętowych. Optymalizacja poszła w las, skoro wygodniej jest zarządzić, że system ‚nie pójdzie’ poniżej 1GB i iluś tam GHz procesora.

    Środowiskom minimalistycznym jak Xfce i LXDE brakuje tylko tego ‚czegoś’, żeby się ładnie i szybko okna rysowały. O dziwo, do przodu są tutaj wolne sterowniki ATI, o ile akurat ma się obsługiwaną przez nie kartę gfx.[/quote]

    Myślę, że to kwestia wyboru „nowe funkcjonalności” vs „optymalizacja tego co jest”. Myślę, że ze względu na szybki rozwój sprzętu bardziej opłacalne jest dorzucanie nowych funkcjonalności niż optymalizacja (większość użytkowników narzeka na sprzęt a nie na programistów gdy wolno chodzi komputer a żeby system był popularny musi być nowoczesny). Osobiście wolałbym aby system graficzny był możliwie lekki bo pracuję na wirtualnych systemach (łatwość backupów) a ostatnio bez 3D tak jak napisałeś jest coraz trudniej (jeśli mówimy o nowych, najpopularniejszych dystrybucjach i ich środowiskach graficznych).

  • maniek5009

    salvadorze – nie pozostaje się nie zgodzić. Brak synchronizacji poziomej dyskwalifikuje Linuksa jako centrum multimedialne czy też w przyszłości – do gier. W blaszaku mam ATI HD3200, ale nawet nie chcę mówić, ile czasu czekałem od zakupu na dobre, otwarte sterowniki (całe lata 😉 ). Na laptopie mam Nvidię ION, znacznie mocniejszą grafikę, która też nie radzi sobie z synchronizacją poziomą – podobnie jak zamknięte sterowniki do ATI…

  • dzidziaka

    salvadhor, a co powiesz o optymalizacji debiana 7 na pentium 166mx i 32 Mb ramu?
    system dziala jako proxy, swapuje, ale daje rade
    oczywiscie nie zainstalujesz debiana na mniej niz chyba teraz 128Mb ramu, ale od czego maszyna stacjonarna i przeniesienie dysku 🙂

  • mst

    Dzięki za artykuł, akurat biorę się za pisanie gry na Androida i właśnie przewinął mi się temat Frame Buffera. Trochę historii również nie zaszkodzi 😉

  • makson Autor wpisu

    [quote comment=”54023″]@makson,

    jak zwykle bardzo doby tekst. Twoje artykuły można czytać gdzieś jeszcze czy piszesz tylko dla Czytelni?[/quote]
    Cieszę się, że ci się podobają. Artykuły o tematyce „popularno-naukowej” piszę jedynie dla Czytelni ubuntu.pl.
    Pozdrawiam