Obsługa ekranu LCD na Raspberry Pi

W dniu 2016-11-16 o 01:38, snipped-for-privacy@gmail.com pisze:4

Naprawdę nie rozumiem, gdzie problem. Rozumiem, że to może komuś przeszkadzać na samym początku, gdy trzeba się nauczyć pewnych charakterystycznych "skrótów" stosowanych w C. W chwili konwencja stosowana w C jest dla mnie czymś oczywistym i takie zapisy ani trochę mi nie przeszkadzają.

No i poza tym rozwiązania wprowadzone w C przyjęły się w wielu popularnych językach, jak C++, Java czy PHP.

Dnia 17.11.2016 Atlantis snipped-for-privacy@wp.pl napisał/a:

Są już gotowe rozwiązania. Klient MPD działający bez X-ów za pośrednictwem frmebuffera i SDL.

W dniu 2016-11-17 o 11:11, grapeli23 pisze:

Słowo kluczowe: touchscreen. U mnie nie ma ekranu dotykowego. Jest prosty wyświetlacz na ILI9341. Do sterowania posłużą dwa przyciski + enkoder obrotowy, ewentualnie wspomagane przez pilota IR. Na chwilę obecną chciałem wyświetlać na tym ekranie parę podstawowych informacji o odtwarzanym utworze i ustawieniach MPD. Potem ewentualnie mógłbym dodać jakieś menu do przeglądania playlist, sterowania odtwarzaniem itp.

Dnia 17.11.2016 Atlantis snipped-for-privacy@wp.pl napisał/a:

Znaczy się dużo łatwiej. W niczym on nie przeszkadza i nie wadzi.

Służy do tego LIRC.

W dniu 2016-11-17 o 11:29, grapeli23 pisze:

Chodziło mi o to, że ten klient jest chyba pisany z myślą o touchscreenie. U mnie go NIE ma. Jedyne sprzętowe sterowanie to dwa przyciski + enkoder obrotowy. No i jeszcze pilot IR.

Wiem, to już mam skonfigurowane.

Dnia 17.11.2016 Atlantis snipped-for-privacy@wp.pl napisał/a:

Bez ekranu dotykowego, to tylko łatwiej.

Takie projekty są tworzone.

W dniu 2016-11-17 o 12:01, grapeli23 pisze:

Ciągle nie rozumiem. Pisałem, że w moim przypadku nie wchodzi w grę skorzystanie z gotowego programu, jeśli jego obsługa opiera się ekranie dotykowym, bo ja w swoim projekcie takowego nie przewidziałem. Ty odpowiadasz wysyłając linki do kolejnego projektu opartego na ekran dotykowy...

Wracamy do punktu wyjścia - muszę sobie to sam napisać tak, żeby gadało z moim hardwarem.

No chyba, że sugerujesz zmodyfikowanie któregoś z gotowych projektów. To już by było jakieś rozwiązanie. Przy czym nie wiem, czy nie będzie łatwiej napisać tego od podstaw. Zwłaszcza, że ja tak naprawdę nie potrzebuję zbyt wielkiej funkcjonalności.

Dnia 17.11.2016 Atlantis snipped-for-privacy@wp.pl napisał/a:

Jeśli ktoś nie rozumie że to co działa na ekranie dotykowym zadziała równie skutecznie na takim bez, to ja podziękuję i mogę życzyć jedynie dalszych sukcesów.

W dniu 2016-11-17 o 12:50, grapeli23 pisze:

ROTFL! Teraz to już naprawdę nie wiem, czy Ty tak na serio, czy najzwyczajniej w świecie trollujesz... W takim razie napiszę wprost: nie, nie twierdzę, że program napisany z myślą o ekranie dotykowym nie odpali się RasPi z LCD bez digitizera. Słowem kluczowym w tym przypadku jest jednak ergonomia obsługi. Proponujesz zastosowanie programów, w których połowa ekranu jest zajęta przez elementy interfejsu dotykowego. I co ja mam niby z tym zrobić? Myszkę podpiąć?

Wolę napisać swój własny kod. Choćby był dużo skromniejszy pod względem funkcjonalności, choćby z początku służył jedynie do wyświetlania informacji odczytywanych z MDP, to przynajmniej będę miał te informacje wyświetlone na całej powierzchni LCD, a nie tym kawałku, który akurat nie jest zajmowany przez wirtualne przyciski.

Ale po co lekki klient na Pi?

Od zawsze można w C z klasami, czyli niepełnym C++.

C++ to rozwinięcie C i poza patalogiami pisanymi przez idiotów każdy program w C jest poprawny w C++. Qt stoi w połowie.

Ale Qt nie podziękował, dał im do reki MOCa i skończyło się własnie w połowie.

a) nie zajmuje tyle b) nawet jesli zajmuje 40MB to co szkodzi?

Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż kilka MB za centa.

Pare kresek zaczyna być nietrywialnym zagadnieniem kiedy nalezy je narysować ładnie, równo, ciekawie, elastycznie, wygodnie itp duperele.

Chebel chyba od dziesięciolecia probuje ewangelizować ludzi że a&&b jest gorsze niż a and b komplenie nie rozumiejąc istoty lepszośc języków ktora leży zupełnie gdzie indziej niż w duperelach składniowych.

IMHO nic lepszego i szybszego w programowaniu niż Swing w Javie nie znajdziesz. Jest mały i nie zajedzie Pi, jak powiedziałem działa na znacznie gorszym hardware.

Jesli jednak chcesz alternatywnego przepisu to sugeruje tak:

Najmniejszym znanym mi środowiskiem do pisania GUI bedzie wxWidgets. Pewno jest jakis pakiet wx-dev na Pi. Piszesz na pececie (nawet na windowsie), kiedy jesteś zadowolony możesz to skompilować na Pi i cieszyć się działaniem.

WxWidgets ma jeszcze jedną niedocenianą zaletą: ma driver który rysuje wprost na framebufferze, bez udziąłu managera okien, systemu, widgetów systemowych itp. Sam rysuje kazdy pixel samodzielnie. Może sie nadać.

Jednak dalej silnie sugeruje Swinga. Nie dośc że developujesz sobie na PC to jeszcze nic nie trzeba kompilowac na Pi. Odpalasz i działa. Niewielkim kłopotem może byc jednak dostęp do hardware, musiałbyś opisać jak to robisz aby ocenić czy z javy się da (a da) i jak.

Mimo to rysowanie kresek, fontów, gradiendów itp rzeczy tylko *pozornie* wydają się łatwe. Na tej grupie bez wątpienia znadziesz na kilogramy programistów z gatunku "co, ja nie potrafie?" ale nie o to chodzi mam nadzieję.

Poszukaj X server framebuffer. Powinien jakis być. Po jego instalacji

*nic* sie nie stanie. Jesli chcesz żeby zobaczyc go w pracy: napisz na konsoli X i naciśnij enter. Jesli Twój FB działa, zobaczysz na ekranie szachownicę i kursor na środku. Od tego momentu mógłbys już odpalać aplikacje na tym ekranie.

Nie rób tego w Xach. Naprawdę, nie chcesz się tym bawić na tak niskim poziomie. Po to powstały wysokopoziomowe bibloteki.

Załatwia to zmienna env DISPLAY="127.0.0.1:0.0". Co to po dwukropku z grubsza określa na którym ekranie pojawi się aplikacja która znajdzie taką zmienną, ale prawie na pewno będzie to 0.0 bo bedzie jeden.

Jak pokazać który fb ma być uzywany przez Xy nie pamiętam. Doszukaj w docu. Domyślnie odpala się na jedynym dostepnym.

Użytkownik "Sebastian Biały"

Chebel chyba od dziesięciolecia probuje ewangelizować ludzi że a&&b jest gorsze niż a and b komplenie nie rozumiejąc istoty lepszośc języków ktora leży zupełnie gdzie indziej niż w duperelach składniowych.

Użytkownik "Sebastian Biały"

...

a) nie zajmuje tyle b) nawet jesli zajmuje 40MB to co szkodzi?

Wygoda pisania i łatwość debugowania na PC są znacznie ważniejsze niż kilka MB za centa.

Już pisałem że pracowało bez najmniejszego problemu na *znacznie* mniejszym embedded niz Pi. I jeszcze poganiało engine JS. Twierdzenie że Java nie pójdzie na Pi uważam za komiczne.

Na przykład w paradygmatach. Albo w metaprogramowaniu. Albo w równoległości wbudowanej w język. Albo w biblitekach. Albo w pierdyliardzie miejsc gdzie są rzeczy istotne z punktu widzenia programisty. Składnia nie należy do rzeczy specjalnie istotnych (poza Perlem gdzie nalezy do rzeczy dyskwalifikujących) bo współczesne języki imperatywne niczym istotnym sie nie różnią.

Użytkownik "Sebastian Biały"

Już pisałem że pracowało bez najmniejszego problemu na *znacznie* mniejszym embedded niz Pi. I jeszcze poganiało engine JS. Twierdzenie że Java nie pójdzie na Pi uważam za komiczne.

Sugerujesz że testowanie na szybszym sprzecie nie ma sensu? Sugerujesz że należy pisać kod na embedded skoro ma pracować na embedded? Serio?

Użytkownik "Sebastian Biały"

Na przykład w paradygmatach. Albo w metaprogramowaniu. Albo w równoległości wbudowanej w język. Albo w biblitekach. Albo w pierdyliardzie miejsc gdzie są rzeczy istotne z punktu widzenia programisty. Składnia nie należy do rzeczy specjalnie istotnych (poza Perlem gdzie nalezy do rzeczy dyskwalifikujących) bo współczesne języki imperatywne niczym istotnym sie nie różnią.