Měl jsem úspěch s několika následujícími experimenty.
Nejprve zjistěte, zda X používá TrueColor RGB vycpaný na 32 bitů (nebo prostě předpokládejte, že tomu tak je). Pak zjistěte, zda máte oprávnění k zápisu na fb0 (a že existuje). Pokud jsou pravdivé (a očekávám, že mnoho moderních sad nástrojů/stolních počítačů/PC je může používat jako výchozí), pak byste měli být schopni udělat následující (a pokud tyto výchozí hodnoty neplatí, pak pravděpodobně stále můžete dosáhnout určitého úspěchu s následující testy, i když podrobnosti se mohou lišit):
Test 1:otevřete virtuální terminál (v X) a zadejte:$ echo "ddd ... ddd">/dev/fb0, kde ... je ve skutečnosti několik obrazovek d. Výsledkem bude jeden nebo více (částečných) šedých čar přes horní část obrazovky v závislosti na délce řetězce odezvy a na tom, jaké rozlišení pixelů jste povolili. Můžete si také vybrat jakákoli písmena (hodnoty ASCII jsou všechny menší než 0x80, takže vytvořená barva bude tmavě šedá... a písmena změňte, pokud chcete něco kromě šedé). Je zřejmé, že to lze zobecnit na smyčku shellu nebo můžete cat velký soubor vidět efekt jasněji:např.:$ cat /lib/libc.so.6>/dev/fb0, abyste viděli skutečné barvy některých fsf příznivci;-P
Nedělejte si starosti, pokud se přepíše velký kus obrazovky. X má stále kontrolu nad ukazatelem myši a stále má představu o tom, kde jsou okna mapována. Jediné, co musíte udělat, je chytit libovolné okno a trochu ho přetáhnout, abyste hluk vymazali.
Test 2:cat /dev/fb0> xxxpak změňte vzhled své plochy (např. otevírejte nová okna a zavřete ostatní). Nakonec proveďte opak:cat xxx> /dev/fb0, abyste získali zpět svou starou plochu!
Ha, ne tak docela. Obrázek vaší staré plochy je iluze a rychle se s ní obejdete, když otevřete jakékoli okno na celou obrazovku.
Test 3:Napište malou aplikaci, která zachytí předchozí výpis /dev/fb0 a upraví barvy pixelů, např. pro odstranění červené složky nebo rozšíření modré nebo převrácení červené a zelené atd. pixelů do nového souboru, na který se můžete podívat později pomocí jednoduchého shellového přístupu testu 2. Všimněte si také, že pravděpodobně budete mít co do činění s B-G-R-A 4bajtovým množstvím na pixel. To znamená, že chcete ignorovat každý 4. bajt a také považovat první v každé sadě za modrou složku. „ARGB“ je big-endian, takže pokud navštívíte tyto bajty prostřednictvím zvyšujícího se indexu pole C, bude na prvním místě modrá, potom zelená a pak červená... tj. B-G-R-A (ne A-R-G-B).
Test 4:Napište aplikaci v libovolném jazyce, která se bude opakovat rychlostí videa a odešle nečtvercový obrázek (předpokládejte xeyes) na část obrazovky, abyste vytvořili animaci bez jakýchkoli okrajů oken. Chcete-li získat další body, nechte animaci pohybovat po celé obrazovce. Po nakreslení malého řádku o velikosti pixelů budete muset přeskočit velký prostor (abyste vykompenzovali šířku obrazovky, která je pravděpodobně mnohem širší než animovaný obrázek).
Test 5:zahrajte si trik na kamaráda, např. rozšiřte test 4 tak, aby se na jeho ploše objevil obrázek animované osoby (možná se nafilmujte, abyste získali data pixelů), pak přejdete na jednu z jejich důležitých ploch složky, zvedne složku a roztrhá ji na kusy, pak se začne hystericky smát a pak vyletí ohnivá koule a pohltí celou jejich plochu. I když to všechno bude iluze, mohou se trochu zbláznit... ale použijte to jako zkušenost s učením, abyste předvedli Linux a open source a ukázali, jak je pro nováčka mnohem děsivější, než ve skutečnosti je. ["virus" jsou v Linuxu obecně neškodné iluze]
Přemýšlím o napsání programu založeného na framebufferu, jen proto, že potřebuji umět rolovat (vodopád SDR). Viz https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=232493&p=1425567#p1425567 Scroll test považuji za úspěšný. V těchto 2 strukturách, které načteme pomocí ioctl pro info, je také něco o barevné hloubce. Zdá se, že jste svůj program založili na stejném příkladu jako já. Jak získat barvu pixelů z framebufferu na linuxu (Raspberry Pi)
Ten můj na mém Raspberry Pi funguje dobře, ať už s X nebo ne. Na obrazovku mého notebooku to nemá žádný vliv. To má /dev/fb0, program běží a čísla vypadají správně, ale vizuálně to nic nedělá. Možná je to s dvojitou vyrovnávací pamětí nebo tak něco.
Pod X ve skutečnosti nezpůsobuje žádné škody. Pokud některá okna přetáhnete, věci se překreslí, vše se vrátí. Pak jsem se rozhodl zálohovat to, co je na obrazovce, a vrátit to zpět, když jsem skončil, to také funguje. Okno, které jsem přesunul a vrátil zpět, funguje stejně, jako bych se ho nikdy nedotkl. X si neuvědomuje, že jsem se popletl s vyrovnávací pamětí obrazovky, ví, co tam vložil, a podle toho registruje kliknutí myší. Pokud bych přesunul okno a nevložil ho zpět, kliknutí by stále fungovalo tam, kde bylo.
Řekl bych, že buďte opatrní, než se pokusíte zapisovat do /dev/fb0, jak bylo navrženo výše. Zkoušel jsem to pod Xin ubuntu 10.04 a a) vizuálně se nic nestalo, b) zničilo to všechna okna shellu, dokonce i další tty, což vedlo k chybám jádra a nedostatečné funkčnosti.
Pokud používáte X11, MUSÍTE projít přes X11 API, abyste mohli kreslit na obrazovku. Obcházení X serveru je velmi nefunkční (a často, jak jste viděli, nefunguje). Může také způsobit pády nebo jen obecné poškození zobrazení.
Pokud chcete být schopni běžet všude (na konzoli i pod X), podívejte se na SDL nebo GGI. Pokud vás zajímá pouze X11, můžete použít GTK, QT nebo dokonce Xlib. Existuje mnoho, mnoho možností...