Zły tryb pracy wyświetlacza

[Elvis]

Mam problem ze sterownikiem do wyświetlacza. Problem wyglada następująco:

Prawdopodobnie tryb pracy jest niepoprawny, ale nie mam pomysłu jak to możliwe, że obraz jest w sumie poprawny, poza tym że bez kolorów i 3 razy powtórzony.

Może ktoś ma pomysł co może być przyczyną takiego działania?

[deshipu]

Bardzo ci współczujemy z powodu twojego problemu.

Może napisz nam jeszcze co to za wyświetlacz i sterownik, jak jest podłączony i do czego, w czym to coś programujesz, z jakich bibliotek korzystasz, jeśli korzystasz, może nawet kawałek kodu demonstrujący problem?

Na oko to wygląda tak, jakbyś mu dawał kolory zakodowane w bajty źle -- albo w złej kolejności, albo mu dajesz bajt (albo nibble) na kolor a on oczekuje zamiast tego kilku czarno-białych obrazów, etc.

[Elvis]

W sumie to nie chodziło mi o solidną dawkę sarkazmu, ale jak widać muszę się cieszyć z tego co mogę dostać.

Nie napisałem nic o sterowniku, ani platformie, bo zastanawia mnie jak to możliwe, że obraz jest akurat w ten sposób zniekształcony - 3 krotne powtórzenie z zachowaniem proporcji obrazu.

Ale skoro pytasz, to jest wyświetlacz TM4300B (http://www.pdaatl.com/doc/tm4300b.pdf), podłączony do płytki ewaluacyjnej Atmel-a z procesorem sama5d2 (http://www.atmel.com/Images/Atmel-44083-32-bit-Cortex-A5-Microprocessor-SAMA5D2-Rev.B-Xplained-Ultra_User-Guide.pdf). Jądro linux-a 4.4 z modyfikacjami Atmel-a, a na tym Android 4.4.2. Sterowniki w tej chwili są oryginalne, chociaż jak widać nie bezbłędne.

Zanim zacznę debugować, zastanawiam się po prostu jaki może być powód takiego zachowania wyświetlacza.

[deshipu]

W mojej odpowiedzi nie było ani szczypty sarkazmu, wszystko, co tam napisałem było absolutnie szczere. Wypraszam sobie.

Taki efekt jest bardzo łatwo uzyskać, gdy wysyłasz dane w postaci RRRRRGGGGGBBBBB a wyświetlacz oczekuje RGBRGBRGBRGBRGB.

[ Dodano: 28-12-2016, 20:18 ]

Ewentualnie gdy wyświetlacz oczekuje danych 300x100, a ty mu wysyłasz 100x300.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Elvis]

Tylko, że musiałbym wysyłać 1/3 linii w danym kolorze - takiego trybu nie widziałem, ale popatrzę w dokumentacji.

Wydaje mi się, że wysyłanie jest poprawne, wcześniej używałem w tym środowisku czystego linuxa i też były problemy z wyświetlaniem, aż któryś z programów poprawnie poustawiał rejestry. Myślę więc, że generowanie danych jest poprawne, w RGB, natomiast coś dolega wyświetlaczowie, tzn. jest ustawiony w jakiś egzotyczny tryb. I stąd było moje pytanie - co to może być?

[ Dodano: 28-12-2016, 20:23 ]

Wyświetlacz ma rozdzielczość 480x272, jak widać w poziomie wszystko się zgadza, poza tym że 3 razy powtórzone...

[deshipu]

Wysyłasz 1/3 linii, bo wysyłasz tylko bajty dla jednego koloru. Wszystko się zgadza.

Jak byś dał nieporuszone zdjęcie, to można by nawet wywnioskować jaki tryb jest dokładnie potrzebny.

[Elvis]

Jeśli to coś pomoże, to prezesyłam kilka zdjęć więcej:

[deshipu]

Dobra, ten środkowy chyba jest najlepszy do naszych celów.

Popatrz dokładnie na górę tej jedynki w "21" -- zauważysz dwie rzeczy. Po pierwsze, one nie są takie same -- tak naprawdę, to każda pokazuje inną składową kolorystyczną tego obrazu. Po drugie, te kolory są całkowicie pomieszane -- owszem, tam gdzie powinny być jasne rzeczy, tam generalnie są jasne, a tam gdzie powinny być ciemne, są ciemniejsze, ale nie zgadzają się dokładnie. Po trzecie tam, gdzie powinny być cienkie białe kreski na czarnym tle -- zamiast tego masz jaskrawe kolory. Jaskrawe kolory są też na granicach pomiędzy jasnym i ciemnym -- tam, gdzie połowa bajtu by była jasna, a połowa ciemna.

I teraz tak. Historycznie, kolorowe karty graficzne, ze względów technicznych, miały pamięć obrazu podzieloną na tyle czarno-białych obrazów (nazywanych "płaszczyznami"), ilu bitowy miał być kolor. Zatem na przykład 16-kolorowy tryb karty EGA miał 4 czarno-białe obrazy 640x480 pikseli. Żeby dowiedzieć się jaki kolor miał piksel w danym miejscu musiałeś policzyć w którym bajcie i bicie dany piksel wypada na każdym z tych obrazów, odczytać wartość każdego z tych bitów i zsumować je z przesunięciem zależnym od płaszczyzny -- wtedy dostawałeś kolor. Ustawienie było analogiczne, ale w drugą stronę. Jak się możesz łatwo domyślić, takie coś jest dosyć powolne od strony programu, który musi to wszystko liczyć, a potem dla zmiany jednego piksela zmodyfikować aż 4 bajty w 4 różnych miejscach pamięci.

Dlatego karta VGA wprowadziła rewolucyjną rzecz, a mianowicie tryb 13h, w którym jednemu bajtowi w pamięci obrazu odpowiadał jeden piksel. To umożliwiło rewolucyjne graficznie gry, takie jak Doom.

Ale wracając do naszego trybu, jeślibyś spróbował w trybie 13h rysować tak, jakby to był tryb 16-kolorowy EGA, to dostałbyś artefakty bardzo podobne do tego, co pokazałeś:

- obszary jasne nadal byłyby jasne -- jak masz bajt ze wszystkimi 8 bitami ustawionymi w jednym trybie (czyli 8 białych pikseli), to w drugim trybie się on wyświetli jako jeden biały piksel.

- jednak konkretne kolory się nie zgadzają

- w szczególności, bajty, które mają połowę pikseli białych a połowę czarnych przetłumaczą się na jakiś jaskrawy kolor, który ma część składowych RGB na maksa, a część na 0. Więc będziesz mieć jaskrawe kolory na brzegach obszarów (zakładając, że nie używasz palety).

[Elvis]

Nie wydaje mi się, żeby bitplany miały cokolwiek wspólnego z moim problemem. Po pierwsze sama5d2 nie obsługuje takiego trybu wyświetlania. Po drugie, gdyby z jakiegoś powodu Android postanowił wygenerować taki właśnie bufor ramki, mielibyśmy cały bitplan dla koloru czerwonego, później zielonego, a na końcu niebieskiego - tak to działało w trybie EGA (każdy bit koloru miał kolejną bitmapę), nie było mieszania każdej po każdej linii.

Możliwe że coś podobnego wynika z przliczania YUV, które sama5d2 może wykonywać sprzętowo, ale nadal nie wiem jak mogłoby to dawać uzyskany efekt.

Natomiast co do zalet trybu 13h... to czy ja wiem, czy on był rewolucyjny bo adresowany bajtowo - raczej 256 kolorów dawało niesamowite możliwości 🙂 Do tego zapas pamięci RAM w karcie VGA pozwalał na podwójne buforowanie i można było tworzyć prawdziwe cuda.

[Elvis]

Może nikogo to nie zainteresuje, ale na wszelki wypadek podam rozwiązanie mojego problemu. Taki efekt uzyskamy jeśli zdekodujemy obraz zapisany w 16-bitowym RGB (565), jako 24-bitowe RGB (888).