- Wygląda na to, że może nie być zbyt wielu opcji do zaprogramowania za pomocą fb z przestrzeni użytkownika na pulpicie, poza tym, o którym wspomniałeś. To może być jeden z powodów, dla których niektóre dokumenty są tak stare. Spójrz na to howto dla pisarzy sterowników urządzeń, do którego odwołują się niektóre oficjalne dokumenty linuxowe: www.linux-fbdev.org [slash] HOWTO [slash] index.html. Nie odwołuje się do zbyt wielu interfejsów .. chociaż patrząc na drzewo źródłowe linux oferuje większe przykłady kodu.
- opentom.org [slash] Hardware_Framebuffer nie jest przeznaczone do środowiska graficznego. Wzmacnia ona główną metodologię, ale wydaje się, że unika wyjaśnienia wszystkich składników niezbędnych do przeprowadzenia "szybkiego" podwójnego przełączania bufora, o którym wspomina. Kolejny dla innego urządzenia i pozostawia pewne kluczowe szczegóły dotyczące buforowania to wiki.gp2x.org [slash] wiki [slash] Writing_to_the_framebuffer_device, chociaż przynajmniej sugeruje, że możesz użyć fb1 i fb0, aby włączyć podwójne buforowanie (w tym urządzenie .. chociaż na komputerze stacjonarnym fb1 może nie być możliwe lub może uzyskać dostęp do innego sprzętu), że użycie słowa kluczowego volatile może być właściwe, i że powinniśmy zwrócić uwagę na wersję vsync.
- asm.sourceforge.net [slash] articles [slash] fb.html Procedury języka asemblerowego, które również pojawiają się (?), Aby po prostu wykonać podstawowe pytania, otworzyć, ustawić kilka podstawowych, mmap, rysowanie wartości pikseli do przechowywania i kopiowania do pamięci fb (upewniając się, że używam krótkiej pętli stosb, jak sądzę, zamiast dłuższego podejścia).
- Uważaj na 16 komentarzy bpp podczas korzystania z Google Frame Buffer: Użyłem fbgrab i fb2png podczas sesji X bez rezultatu. Każdy z nich wyrenderował obraz, który zasugerował migawkę mojego pulpitu, tak jakby obraz pulpitu został zrobiony przy użyciu bardzo złego aparatu, pod wodą, a następnie prześwietlony w ciemnym pokoju. Obraz był kompletnie zepsuty w kolorze, rozmiarze i brakowało dużo szczegółów (kropkowane na całym tle pikselowymi kolorami, które nie pasowały). Wygląda na to, że/proc/sys na używanym przeze mnie komputerze (nowe jądro z co najwyżej niewielkimi modyfikacjami ... z pochodnej PCLOS) twierdzą, że fb0 używa 16 bpp, a większość rzeczy, które wypróbowałem, stwierdziło coś podobnego, ale eksperymenty prowadzą mnie do bardzo odmienny wniosek.Poza wynikami tych dwóch awarii ze standardowych programów narzędziowych do przechwytywania bufora ramki (dla wersji posiadanych przez tę dystrybucję), które mogły przyjąć 16 bitów, miałem inny wynik testu zakończony traktowaniem danych pikseli bufora ramki jako 32 bity. Stworzyłem plik z danych pobranych przez cat/dev/fb0. Rozmiar pliku zakończył się 1920000. Potem napisałem mały program C, aby spróbować manipulować tymi danymi (przy założeniu, że był to piksel w niektórych kodowaniach lub innych). Ostatecznie przyjąłem to do siebie, a format pikseli pasował dokładnie do tego, co otrzymałem od X, gdy pytałem (TrueColor RGB 8 bitów, bez alfa, ale wyściełane do 32 bitów). Zauważ inną wskazówkę: moja rozdzielczość ekranu 800x600 razy 4 bajty daje dokładnie 1920000. Podejścia 16-bitowe, które próbowałem początkowo, wszystkie dały podobny obraz z podziałem na fbgrap, więc nie jest tak, jakbym nie szukał właściwych danych. [Daj mi znać, jeśli chcesz kod, którego użyłem do przetestowania danych. Zasadniczo po prostu czytam cały zrzut fb0, a następnie wypluwam go z powrotem do pliku, po dodaniu nagłówka "P6 \ n800 600 \ n255 \ n", który tworzy odpowiedni plik ppm, i podczas pętli nad wszystkimi pikselami manipulującymi ich kolejnością lub rozszerzanie ich, ... z końcowym wynikiem pomyślnym dla mnie, że spadam co czwarty bajt i przełączam pierwszą i trzecią w każdej 4-bajtowej jednostce. Krótko mówiąc, zamieniłem pozorny zrzut BGRA fb0 na plik ppm RGB. ppm można oglądać za pomocą wielu przeglądarek pic na Linuksie.]
- Możesz chcieć ponownie rozważyć powody, dla których chcesz programować przy użyciu fb0 (może to również wyjaśniać, dlaczego istnieje kilka przykładów). Możesz nie osiągnąć żadnego opłacalnego przyrostu wydajności w stosunku do X (było to moje, choć ograniczone doświadczenie), jednocześnie rezygnując z korzyści wynikających z używania X. Przyczyna ta może również wyjaśniać, dlaczego istnieje kilka przykładów kodu.
- Należy zauważyć, że DirectFB nie jest fb. DirectFB ma ostatnio więcej miłości niż starszy fb, ponieważ jest bardziej skupiony na bardziej seksownym 3d hw accel. Jeśli chcesz renderować na ekran komputera tak szybko, jak to możliwe bez użycia akceleracji sprzętowej 3D (lub nawet 2d hw accel), to fb może być w porządku, ale nie da ci niczego, czego X nie da. X najwyraźniej używa fb, a narzut jest prawdopodobnie nieistotny w porównaniu do innych kosztów, które twój program prawdopodobnie będzie miał (nie wywołuj X w żadnej ciasnej pętli, ale zamiast tego na końcu po ustawieniu wszystkich pikseli dla ramki). Z drugiej strony może być fajnie grać z fb, jak opisano w tym komentarzu: Paint Pixels to Screen via Linux FrameBuffer
To trochę ogólne, czy mógłbyś wskazać mi bardziej konkretny kierunek? – NoMoreZealots