Ustawienie trybu jądra vs. Framebuffer?

W KMS sterowniki graficzne są przenoszone do jądra. Ponieważ bufor ramki był już w jądrze, nie spodziewałbym się, że wpłynie to na działanie bufora ramki. Jednak przeczytałem, że KMS zastępuje fb, powiększa fb, wymaga fb i wymaga usunięcia obsługi fb. Co za cholera? Odpowiedź, której szukam, to wyjaśnienie związku między KMS a buforem ramki.

Używam uvesafb, aby uzyskać natywną rozdzielczość w tty. Moim celem jest zrozumienie, jak to będzie działać w systemie z KMS. Pomogłoby to również objąć takie tematy jak: Czy przewijanie jest szybsze w KMS? Czy narzędzia takie jak fbterm i fbida działają tak samo? Czy stabilność jest lepsza?

Przede wszystkim istnieją zasadniczo dwa typy klasycznych sterowników bufora ramki:

• Ogólne sterowniki sprzętu i oprogramowania układowego (np. Vga, vesafb / uvesafb, efifb)
• Sterowniki specyficzne dla sprzętu (np. Rivafb, atyfb)

Wszystkie klasyczne sterowniki bufora ramki miały podstawową obsługę ustawiania trybów, ale w niewielkim stopniu lub w ogóle obsługiwały przyspieszenie sprzętowe.

W klasycznym projekcie X nie było to tak naprawdę problemem: aby uzyskać przyspieszenie 2D, serwer X działał jako root i miał bezpośredni dostęp do sprzętu. Zasadniczo całkowicie ominął sterownik bufora ramki. W przypadku obsługi 3d (i 2d na nowszych kartach) używałby również sterownika DRM jądra, który pośredniczy w dostępie i zarządza pamięcią wideo.

W tej konfiguracji były dwa miejsca, w których dokonano ustawiania trybów: zarówno w sterowniku bufora ramki jądra, jak i na serwerze X przestrzeni użytkownika. To powielanie kodu (i sporadyczne walki między kierowcami, np. Na przełączniku VT) nie były idealne.

Ponadto w jądrze były dwa oddzielne sterowniki dla tego samego sprzętu: sterownik bufora ramki i sterownik DRM. W niektórych przypadkach (np. Intelfb sprzed km) możesz załadować jeden lub drugi, ale nie oba jednocześnie.

KMS było rozwiązaniem tych problemów. To:

• Scala specyficzny dla jądra sterownik bufora ramki i sterownik drm w jeden sterownik.
• Zapewnia interfejs dla X serwera do sterowania ustawieniami trybów, dzięki czemu X serwer nie musi mieć bezpośredniego dostępu do sprzętu. (Rzeczywiście, dzięki KMS serwer X nie potrzebuje już uprawnień roota.)

Kilka interesujących uwag: Migracja do obecnej wersji KMS rozpoczęła się około 2004 r .; zobacz e-mail Jona Smirl na temat rearchitektury konsoli .

Aby odpowiedzieć na bardziej szczegółowe pytania:

• Szybkość ogólnie nie będzie gorsza niż jeden z nieprzyspieszonych sterowników ogólnych (np. VGA, vesafb), ale konsola tekstowa bufora ramek KMS została zaprojektowana dla wygody i awaryjnego użycia, a nie prędkości, a konsola nie jest w pełni przyspieszona w niektórych sterownikach. Na przykład owinięte długie linie są dość złe na kartach Intel.
• Aplikacje zaprojektowane do korzystania ze starych interfejsów bufora ramki nadal będą działać na buforze ramki KMS.

KMS ustawia rozdzielczość wyświetlania i głębokość w przestrzeni jądra, a nie w przestrzeni użytkownika. Tak więc to zastępuje. Umożliwia natywną rozdzielczość w buforze ramki.

Ustawienie trybu jądra