Snazil jsem se nejakou dobu najit reseni, ktere by mi umoznilo zobrazovani multimedialniho obsahu (Text, obrazky, videa) bez nutnosti provozovat X11.
Zkousel jsem pouzit Kivy Framework, ale ten se ukazal jako prilis nestabilni. Mizerny vykon, nekdy se obrazky nenacetly, pady aplikace.
Nenasel jsem moznost zobrazovani HTML 5 pod framebufferem s podporou akcelerace a Javasriptu. Resenim by bylo Qt5, ale to vyzaduje dobrou znalost C++ resp. Qml.
Nakonec jsem koupil jinou desku s podporou Androidu a resim to prez Cordovu.
nieco podobne som robil
https://github.com/magicqe/rwt/blob/master/screenshot.png
je to prehravac internetovych radii, zobrazuje cas a pocasie, ovlada sa to cez dotykovu obrazovku alebo dialkove;
problem je zie tie dotykove displeje su pripojene cez GPIO
a to je dost bieda, v kerneli je slaba podpora tychto touchscreenov
Taky bych rád akcelerovaný HTML5 prohlížeč pro Raspberry Pi. Schválně jsem se teď mrkl na NetSurf, o kterém autor článku píše, že verzi s výstupem na FB má, a zdá se, že už trochu javascript podporuje (nedávno zahodili SpiderMonkey a přešli na Duktape). Musím se podívat někdy, jak na tom v praxi doopravdy je.
Ono i Netsurf pro GTK je hooodne rychle, samozrejme s urcitymi problemy v layoutu. Ale Root se zobrazuje dobre (toto pisu prave v Netsurfu), takze jen doufejme, ze autori nesejdou ze spravne cesty a nezacnou pridavat 'ficurky' a kazdou verzi menit vzhled GUI, ale skutecne se zameri na JS.
Tyhle články směřující k hardware a low-level věcem mě baví, díky. Dotaz: Co se přesně skrývá pod tím binárním blobem. Měl jsem za to, že na posílání zpráv přes mailboxy a zápis do framebufferu stačí mít zjednaný přístup do paměti (třeba přes nějaký driver), a pak už není potřeba nic. Jasně, problém je v nedostupnosti dokumentace.
Jeden (vlastne dva :) bloby se loaduji uz pri bootu:
http://wiki.beyondlogic.org/index.php?title=Understanding_RaspberryPi_Boot_Process
V minulém roce jsem vedl GSoC projekt čínského studenta, který měl za úkol vyřešit podporu RPi framebufferu pro real-time operační systém RTEMS
jednalo se právě o vyřešení nastavení a přístupu přes mailboxy na té nejnižší úrovni. Popis projektu zde
https://devel.rtems.org/wiki/GSoC/2015/rpi_graphic
projekt se podařilo dokončit do stavu, kdy příklady z Microwindows
https://github.com/ghaerr/microwindows
na RPi chodily. Bohužel nezbyl čas na dotažení propojení na klávesnici a především je potřeba dořešit několik drobností aby rozdělení adresního prostoru a konfigurace MMU podle nastavení z bootu odpovídala mnou stanovených požadavků pro začlenění do hlavního vývojového stromu RTEMS. Takže projekt je zatím jen ve vývojovém GITu mnou vedeného studenta
https://github.com/yangqiao/rtems/
a čaká, až nějakým zázrakem budu mít tak dva dny volného času nebo až se najde někdo další. Bohužel GSoC na toto téma již RTEMS asi nedostane (pro RTEMS další GSoC nejspíš v létě zase povedu, ale na jiné RTEMS komunitou odsouhlasené téma).
Pokud by se tedy našel někdo, kdo by si s RTEMSem na RPi chtěl pohrát, tak budu rád. Finance ani naší skupinou na ČVUT financovaný projekt na to nedostanu. Priority jsou jinde, multicore, Linux, FPGA nebo jiné RTOS pro safety a automotive MCU a průmyslové partnery. Pokud by se ale přihlásil někdo z ČVUT FEL, tak projekt mohu vypsat jako bakalářskou práci.
Co se týče budoucnosti VC4 na Linuxu, tak to začíná vypadat velmi dobře, Broadcom uvolnil dostatek informací k tomu, že již existuje otevřená náhrada binárního blobu, který systém zavádí a pracuje se na otevřené implementaci driveru pro VC4. Vývojové nástroje
https://github.com/anholt/vc4-gpu-tools
podporu v jádře vyvíjí Eric Anholt. Asi nejvíce up to date jeho větev
https://github.com/anholt/linux/commits/drm-vc4-next
práce běží i na open source mesa 3D driveru
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/vc4
Takže možností zapojit se do zajímavých a často i užitečných projektů je mnoho.
Tak vsak to neni server, kam by se pripojovaly tisice uzivatelu, kteri by si mezi sebou framebuffer kradli :) Neni to ani desktop, proste krabka urcena pro bastleni (v tom nejlepsim slova smyslu), takze sednes, pripojis se, delas s framebufferem, ovladas bez problemu GPIO a je to.
Mas tam v defaultu jednoho uzivatele (pi), tusim vypnuty ssh, takze je jasny, ze kdyz se pripoji, tak proste je fyzicky u Raspberry. Pokud to chces jinak, dva radky to spravi - jeden pro zapnuti sshd, druhy pro vyrazeni "pi" ze skupiny "video".
Tedy ja osobne bych to videl jeste jinak: proste framebuffer je pristupnej prave pro toho uzivatele, kterej je fyzicky u pocitace. Ostatne tento uzivatel muze ovladat klavesnici, mys, akcelerovany X-ka, tak proc ne framebuffer.