Ostatnimi 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.