Nie miałem do tej pory żadnych doświadczeń z obsługą wyświetlaczy
graficznych na Raspberry Pi, dlatego chciałbym zapytać od której strony
to ugryźć.

Wyświetlacz to prosty LCD 320x240 na ILI9341. Jest już podłączony do
RasPi przez SPI, system widzi go jako /dev/fb1. Testowo udało mi się na
nim wyświetlić konsolę. Moim celem jest jednak generowanie na nim
prostego interfejsu graficznego: trochę tekstu, jakieś paski postępu,
może jakieś proste grafiki z plików. Nie chcę na tym odpalać pełnego
interfejsu okienkowego.

Główne pytanie brzmi tak: czy wśród standardowych bibliotek dostępnych
na Linuxa (Raspbian Jessie) znajduje się coś, co pozwalałoby w prosty
sposób rysować na wyświetlaczu, wykorzystując pisząc bezpośrednio do
framebuffera, z pominięciem całego systemu okienkowego?

do góry

On 15/11/2016 08:17, Atlantis wrote:
> Nie miałem do tej pory żadnych doświadczeń z obsługą wyświetlaczy
> graficznych na Raspberry Pi, dlatego chciałbym zapytać od której strony
> to ugryźć.
>
> Wyświetlacz to prosty LCD 320x240 na ILI9341. Jest już podłączony do
> RasPi przez SPI, system widzi go jako /dev/fb1. Testowo udało mi się na
> nim wyświetlić konsolę. Moim celem jest jednak generowanie na nim
> prostego interfejsu graficznego: trochę tekstu, jakieś paski postępu,
> może jakieś proste grafiki z plików. Nie chcę na tym odpalać pełnego
> interfejsu okienkowego.
>
> Główne pytanie brzmi tak: czy wśród standardowych bibliotek dostępnych
> na Linuxa (Raspbian Jessie) znajduje się coś, co pozwalałoby w prosty
> sposób rysować na wyświetlaczu, wykorzystując pisząc bezpośrednio do
> framebuffera, z pominięciem całego systemu okienkowego?
>


pod pythonem uzywam Adafruit_ILI9341

https://github.com/adafruit/Adafruit_Python_ILI9341

do góry

W dniu 2016-11-15 o 09:22, cezar pisze:

> pod pythonem uzywam Adafruit_ILI9341
>
> https://github.com/adafruit/Adafruit_Python_ILI9341

1) Jeśli nie muszę, nie używam Pythona. Preferuję standardowe C,
ewentualnie C++.
2) Z tego co widzę, to ta biblioteka dostarcza swój własny sterownik i
nie korzysta z framebuffera. Skoro już udało mi się skomunikować
wyświetlacz z jądrem Linuksa, to wolałbym iść tą drogą. Szukam
biblioteki, która dostarczy mi przynajmniej najbardziej podstawowe
funkcje graficzne, ale sama będzie pisała do framebuffera.

do góry

On Tue, 15 Nov 2016 09:47:19 +0100, Atlantis <m...@w...pl>
wrote:
> wyświetlacz z jądrem Linuksa, to wolałbym iść tą drogą. Szukam
> biblioteki, która dostarczy mi przynajmniej najbardziej podstawowe
> funkcje graficzne, ale sama będzie pisała do framebuffera.

Ciekawe czy coś znajdziesz, po co ktoś miałby coś takiego tworzyć
skoro jest x11?

--
Marek

do góry

Dnia 15.11.2016 Marek <f...@f...com> napisał/a:
> On Tue, 15 Nov 2016 09:47:19 +0100, Atlantis <m...@w...pl>
> wrote:
>> wyświetlacz z jądrem Linuksa, to wolałbym iść tą drogą. Szukam
>> biblioteki, która dostarczy mi przynajmniej najbardziej podstawowe
>> funkcje graficzne, ale sama będzie pisała do framebuffera.
>
> Ciekawe czy coś znajdziesz, po co ktoś miałby coś takiego tworzyć
> skoro jest x11?
>

Tworzono. Najbardziej rozbudowaną był DirectFB. Cairo bodajże do dziś
wspiera ten backend. Był port GTK2.
https://www.cairographics.org/backends/

Działał pod tym Gimp, Firefox (gdzieś tak do 3.6), webkit. Sam używałem
klienta VNC, mplayera, prostych przeglądarek graficznych, pdf (mupdf
fbdev), przeglądarki internetowej netsurf, links.
Dziś Linux Frame-Buffer jest w kompletnym zamrożeniu. Nie dodaje się już
nowych driverów. Zachęca się do przejścia na DRM/KMS, który oferuje
pewną formę emulacji fbdev.

Firmy które to wykorzystywały w swoich projektach często tworzyły swoje
własne rozwiązania.

do góry

On Tue, 15 Nov 2016 15:12:36 -0000 (UTC), grapeli23
<g...@g...com> wrote:
> Tworzono. Najbardziej rozbudowaną był DirectFB. Cairo bodajże do
dziś
> wspiera ten backend. Był port GTK2.
> https://www.cairographics.org/backends/

Ale to na pewno system.okienkowy z menadzerem? Bo to, że można
interfejs jednej aplikacji wyświetlić na fbdev to jasne, sdl też.
chyba umiał korzystać z fb. Atlatisowi chyba chodziło o środowisko a
nie pojedynczy interfejs

--
Marek

do góry

On 2016-11-15 09:17, Atlantis wrote:
> sposób rysować na wyświetlaczu, wykorzystując pisząc bezpośrednio do
> framebuffera, z pominięciem całego systemu okienkowego?

Jesli widzisz to jako framebuffer to możesz zainstalować sam serwer X-ów
do FB, bez managera okien. Wtedy napiszesz aplikację w czymkolwiek (ja
np. w Javie mam dobre doświadczenia ale równie dobrze może być Qt,
Python, whatever) i będzie ona dzialać fullscreen. Uzyskasz tanim
kosztem efekt całkiem przyzwoity.

do góry

Dnia 15.11.2016 Marek <f...@f...com> napisał/a:
> On Tue, 15 Nov 2016 15:12:36 -0000 (UTC), grapeli23
><g...@g...com> wrote:
>> Tworzono. Najbardziej rozbudowaną był DirectFB. Cairo bodajże do
> dziś
>> wspiera ten backend. Był port GTK2.
>> https://www.cairographics.org/backends/
>
> Ale to na pewno system.okienkowy z menadzerem? Bo to, że można
> interfejs jednej aplikacji wyświetlić na fbdev to jasne, sdl też.
> chyba umiał korzystać z fb. Atlatisowi chyba chodziło o środowisko a
> nie pojedynczy interfejs
>

https://en.wikipedia.org/wiki/DirectFB

do góry

W dniu 2016-11-15 o 18:20, Sebastian Biały pisze:

> Jesli widzisz to jako framebuffer to możesz zainstalować sam serwer X-ów
> do FB, bez managera okien. Wtedy napiszesz aplikację w czymkolwiek (ja
> np. w Javie mam dobre doświadczenia ale równie dobrze może być Qt,
> Python, whatever) i będzie ona dzialać fullscreen. Uzyskasz tanim
> kosztem efekt całkiem przyzwoity.

A jak będzie wyglądała kwestia zużycia zasobów? Bo zastanawiam się, czy
to przypadkiem nie będzie strzelanie z armaty do komara. Tak naprawdę
potrzebuje czegoś bardzo prostego, przypominającego rozwiązania z
Arduino. To ma być typowe urządzenie embedded, a wyświetlacz ma
zapewniać dostęp do paru podstawowych informacji i ustawień.

Na dobrą sprawę mógłbym sobie napisać funkcję put_pixel() operującą na
/dev/fb1 i potem podpiąć do niej jakieś biblioteki z Arduino. Sądziłem
po prostu, że może coś takiego już istnieje, biorąc popularność Linuksa
w zastosowaniach wbudowanych...

do góry

On 2016-11-15 21:13, Atlantis wrote:
> A jak będzie wyglądała kwestia zużycia zasobów? Bo zastanawiam się, czy
> to przypadkiem nie będzie strzelanie z armaty do komara.

Server X na framebuffer to tylko proxy do pamięci z /dev/

> Tak naprawdę
> potrzebuje czegoś bardzo prostego, przypominającego rozwiązania z
> Arduino. To ma być typowe urządzenie embedded, a wyświetlacz ma
> zapewniać dostęp do paru podstawowych informacji i ustawień.

Problem w tym że jesli zrobisz to ręcznie czeka Cie rzeźba
*niemiłosierna* z napisaniem każdej kontrolki, systemu eventów itp.
Server X do FB jest lightweight. Używałem go na tym cudzie:

http://www.goodluckbuy.com/images/detailed_images/sk
u_89640_1.jpg

To jest komputer nieporównywalnie słabszy od Pi. Nie dośc że uciągnął Xy
to jeszcze Javę a w środku javy JavaScript (Rhino) w którym była
wlaściwa algorytmika sterowania maszyną. GUI na Swing wyszło za darmo bo
*był* serwer X i wyglądało profesjonalnie, cokolwiek to znaczy.
Zadziałało od razu, bez marudzenia.

Skoro to maleństwo uciągneło java+X to naprawde, bez obaw o zasoby Pi.
Managera okien bym nie stawial jesli ma być embedded, ale Xy jak
najbardziej. Jak mówie, Xy to tylko takie proxy do /dev/fb. Może dośc
pokręcone, ale co to kogo obchodzi.

> Na dobrą sprawę mógłbym sobie napisać funkcję put_pixel() operującą na
> /dev/fb1 i potem podpiąć do niej jakieś biblioteki z Arduino.

Zajedziesz się. Nie warto. Postawienie X fb to kilka chwil i nagle
dostajesz dostep do masy softu działającego *wprost*, wliczając to nawet
takie cuda jak wxWidgets, QTopia, Qt gdzie można zrobić gui z grubej rury.

> Sądziłem
> po prostu, że może coś takiego już istnieje, biorąc popularność Linuksa
> w zastosowaniach wbudowanych...

Xy istnieją :) To jest Pi więc używanie ręcznie wydziarganych algorytmów
rysowania kresek wydaje się być naciągane...

do góry