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...