- Es scheint, dass nicht zu viele Optionen möglich sind, um mit dem fb aus dem Benutzerbereich auf einem Desktop zu programmieren, die über das hinausgehen, was Sie erwähnt haben. Dies könnte ein Grund sein, warum einige der Dokumente so alt sind. Sehen Sie sich dieses Howto für Gerätetreiber-Writer an, auf das von einigen offiziellen Linux-Dokumenten verwiesen wird: www.linux-fbdev.org [slash] HOWTO [slash] index.html. Es referenziert nicht zu viele Schnittstellen. Obwohl das Betrachten des Linux-Quellbaums größere Code-Beispiele bietet.
- opentom.org [Schrägstrich] Hardware_Framebuffer ist nicht für eine Desktop-Umgebung. Es verstärkt die Hauptmethodik, aber es scheint zu vermeiden, alle Zutaten zu erklären, die notwendig sind, um den "schnellen" doppelten Puffer zu machen, den es erwähnt. Ein anderer für ein anderes Gerät, der einige wichtige Pufferinformationen offen lässt, ist wiki.gp2x.org [slash] wiki [slash] Writing_to_the_framebuffer_device, obwohl es zumindest andeutet, dass Sie fb1 und fb0 verwenden können, um die doppelte Pufferung zu aktivieren (zu diesem Zweck) Gerät .. obwohl für Desktop, fb1 ist möglicherweise nicht möglich oder es kann auf andere Hardware zugreifen), dass die Verwendung von flüchtigen Schlüsselwort könnte angebracht sein, und wir sollten auf die vsync achten.
- asm.sourceforge.net [slash] Artikel [slash] fb.html Assembler Sprachroutinen, die auch erscheinen (?), Nur um die Grundlagen der Abfrage, Öffnen, ein paar Grundlagen, mmap, Zeichnen von Pixelwerten zu tun zum Speichern und zum Kopieren in den fb-Speicher (stelle sicher, dass ich eine kurze Stosb-Schleife verwende, nehme ich an, statt eine längere Annäherung).
- Vorsicht 16 bpp Kommentare beim Googling Linux Frame Buffer: Ich habe fbgrab und fb2png während einer X-Sitzung ohne Erfolg verwendet. Diese erzeugten jeweils ein Bild, das einen Schnappschuss meines Desktop-Bildschirms suggerierte, als ob das Bild des Desktops mit einer sehr schlechten Kamera unter Wasser aufgenommen und dann in einem dunklen Raum überbelichtet worden wäre. Das Bild war vollständig in Farbe, Größe und fehlenden Details gebrochen (überall mit Pixelfarben übersät, die nicht dazugehörten). Es scheint, dass/proc/sys auf dem Computer, den ich verwendet habe (neuer Kernel mit höchstens geringen Modifikationen ... von einem PCLOS-Derivat), fb0 16 bpp verwendet, und die meisten Dinge, die ich gegoogelt habe, haben etwas in diese Richtung gesagt, aber Experimente führen mich dazu eine ganz andere Schlussfolgerung.Neben den Ergebnissen dieser beiden Fehler von Standard-Framepuffer-Grab-Dienstprogrammen (für die von dieser Distribution gehaltenen Versionen), die 16 Bits angenommen haben, hatte ich ein anderes erfolgreiches Testergebnis, das Bildpuffer-Pixeldaten als 32 Bits behandelt. Ich habe aus cat/dev/fb0 Daten eine Datei erstellt. Die Größe der Datei endete bei 1920000. Ich schrieb dann ein kleines C-Programm, um zu versuchen, diese Daten zu manipulieren (unter der Annahme, dass es Pixeldaten in irgendeiner Kodierung oder anderen waren). Ich habe es irgendwann genagelt, und das Pixelformat entsprach genau dem, was ich von X bekommen hatte (TrueColor RGB 8 Bit, kein Alpha, sondern 32 Bit). Beachten Sie einen anderen Hinweis: meine Bildschirmauflösung von 800x600 mal 4 Bytes ergibt genau 1920000. Die 16-Bit-Ansätze, die ich anfangs versuchte, erzeugten alle ein ähnliches gebrochenes Bild wie fbgrap, also ist es nicht so, als ob ich nicht die richtigen Daten betrachtet hätte. [Lassen Sie es mich wissen, wenn Sie den Code, mit dem ich die Daten getestet habe, wollen. Im Grunde lese ich nur den gesamten fb0-Dump ein und spucke ihn dann wieder in die Datei aus, nachdem ich eine Kopfzeile "P6 \ n800 600 \ n255 \ n" hinzugefügt habe, die die passende ppm-Datei erstellt und alle Pixel durchläuft, die ihre Reihenfolge manipulieren erweitern sie, .. mit dem Ende erfolgreiches Ergebnis für mich, um jedes 4. Byte zu fallen und die erste und dritte in jeder 4-Byte-Einheit zu wechseln. Kurz gesagt, habe ich den scheinbaren BGRA-fb0-Dump in eine ppm-RGB-Datei umgewandelt. ppm kann mit vielen Bildbetrachtern unter Linux betrachtet werden.]
- Vielleicht möchten Sie die Gründe für das Programmieren mit fb0 noch einmal überdenken (dies könnte auch dafür verantwortlich sein, dass nur wenige Beispiele existieren). Sie können keine lohnenden Leistungszuwächse über X erzielen (dies war meine, wenn auch begrenzte Erfahrung), während Sie die Vorteile der Verwendung von X aufgeben. Dieser Grund könnte auch dafür verantwortlich sein, warum wenige Codebeispiele existieren.
- Beachten Sie, dass DirectFB nicht fb ist. DirectFB hat in letzter Zeit mehr Liebe bekommen als das ältere fb, da es sich mehr auf den sexiereren 3D hw accel konzentriert. Wenn Sie so schnell wie möglich auf einen Desktop-Bildschirm rendern möchten, ohne die Hardware-Beschleunigung (oder sogar 2D-Beschleunigung) zu verwenden, dann ist fb vielleicht in Ordnung, aber Sie erhalten nichts, was X Ihnen nicht bietet. X verwendet scheinbar fb, und der Overhead ist wahrscheinlich vernachlässigbar im Vergleich zu anderen Kosten, die Ihr Programm wahrscheinlich haben wird (rufen Sie X nicht in einer engen Schleife auf, sondern am Ende, sobald Sie alle Pixel für den Frame eingerichtet haben). Auf der anderen Seite kann es sauber sein, mit fb zu spielen, wie in diesem Kommentar beschrieben: Paint Pixels to Screen via Linux FrameBuffer
Das ist ein bisschen allgemein, können Sie mir eine genauere Richtung geben, um zu schauen? – NoMoreZealots