Levný čínský 3,5″ dotykový displej, Raspberry Pi 4 a čerstvý Debian 13. Návody z internetu nefungovaly, displej svítil bíle a pak ukazoval všechno zrcadlově. S Claudem jsem se prokousal od dmesg až k úpravě ovladače v kernelu – a cestou zjistil, jak (ne)ladit hardware s AI.
Výchozí situace: bílá obrazovka
Displej je klasický levný klon s nápisem „3.5inch RPi Display, 480×320, XPT2046 Touch Controller“. Nasadíte ho na GPIO, nainstalujete ovladač a hotovo. Aspoň podle návodů.
U mě po zapnutí svítil celý bíle. Podsvícení jede, data nic. Chtěl jsem tam mít jen obyčejnou textovou konzoli, nic víc.
Otevřel jsem chat s Claudem a začali jsme klasicky: zapnout SPI, přidat overlay do config.txt, rebootovat. Nic. Teprve když jsem poslal výstup z pár diagnostických příkazů, vylezlo první vodítko – dotyková vrstva se načetla, ale displej vůbec. A ls /boot/firmware/overlays/ ukázal proč: overlay waveshare35a, na kterém stojí půlka internetu, v Debianu 13 prostě není. Kernel ho tiše ignoroval.
Detektivka přes dmesg
Tady AI fungovala skvěle. Já jsem posílal výstupy, Claude je četl a navrhoval další krok:
- Náhradní overlay
pitft35-resistivenahrál ovladač pro úplně jiný čip (HX8357D) a k tomu se pral o GPIO 25 s dotykem. - Generický
fbtftoverlay hlásilMissing info about 'dc' gpio– na Trixie nepřebírá parametry pinů. - Až vlastní overlay s explicitně zadanými piny (reset, data/command, podsvícení) vytvořil framebuffer
/dev/fb0s ovladačemfb_ili9486.
Test pravdy: cat /dev/urandom > /dev/fb0. Na displeji naskočil barevný šum. Jenže jen na dvou třetinách. Spodek zůstal bílý.
Fotka zadní strany vyřešila bílou třetinu
Claude mě několikrát prosil o fotku zadní strany desky a já to odkládal. Chyba. Na fotce byly vidět čtyři posuvné registry, přes které deska převádí SPI na paralelní sběrnici displeje. To znamená, že i příkazy musí chodit jako 16bitová slova, ne po bajtech.
Pár pokusů s buswidth skončilo dvojitým obrazem a hláškou z kernelu, že takovou kombinaci neumí. Fungovalo až tohle:
buswidth = <8>;
regwidth = <16>;Celá plocha, logo Raspberry Pi při bootu, krása. Až na jednu drobnost: všechno bylo zrcadlově.
Zrcadlo, které nešlo otočit
Tady se ladění zaseklo a tady taky AI předvedla svoje slabiny.
Orientaci obrazu u čipu ILI9486 řídí registr 0x36 (MADCTL). Jeden bit otáčí řádky, druhý sloupce, třetí prohazuje osy. Teoreticky stačí najít správnou kombinaci. Zkoušeli jsme hodnoty v inicializační sekvenci, parametr rotate v overlayi, mirror, rotaci přes /sys/class/graphics/fb0/rotate, fbcon=rotate v kernel parametrech. Displej buď zůstal stejný, nebo se otočil, ale zrcadlo zůstalo. Jeden „nápad“ (spi-cpol a spi-cpha) displej úplně odstavil a musel jsem ho vracet.
Co mě vyloženě štvalo:
- AI dvakrát tvrdila, že obraz už je v pořádku. Na fotce jsem viděl „D“ s bříškem na špatné straně, Claude psal „teď je to čitelné správně!“. Zjevně si fotku v „hlavě“ otočil a přečetl text, který zná, místo aby se díval na tvary písmen. Pomohlo až napsat na displej
ABCDEFGHa ASCII šipky – jednoznačný testovací obrazec místo boot logu. - Skákání mezi řešeními. V jedné odpovědi mi přišlo pět různých směrů najednou: fbcp, rekompilace, parametry modulu, jiná hodnota registru… Musel jsem napsat „dej mi jednu věc, vyzkouším ji a dám ti odpověď“. Od té chvíle to šlo výrazně líp.
Řešení: jeden bit ve zdrojáku ovladače
Zlom přišel, když jsme přestali hádat a podívali se do zdrojového kódu ovladače fb_ili9486.c. Je to asi sto řádků C a odpověď byla vidět hned: funkce set_var() při každé změně nastavení zapisuje do registru 0x36 napevno danou hodnotu podle rotace. Všechno, co jsme do registru poslali v inicializaci, ovladač vzápětí přepsal. Proto žádný pokus s konfigurací nemohl fungovat.
Oprava je směšně malá – ke každé hodnotě přepnout bit 0x40 (zrcadlení sloupců):
/* původně: 0x80, 0x20, 0x40, 0xE0 */
case 0: write_reg(par, MIPI_DCS_SET_ADDRESS_MODE, 0xC0 | (par->bgr << 3)); break;
case 90: write_reg(par, MIPI_DCS_SET_ADDRESS_MODE, 0x60 | (par->bgr << 3)); break;
case 180: write_reg(par, MIPI_DCS_SET_ADDRESS_MODE, 0x00 | (par->bgr << 3)); break;
case 270: write_reg(par, MIPI_DCS_SET_ADDRESS_MODE, 0xA0 | (par->bgr << 3)); break;Proč je tenhle konkrétní panel zapojený obráceně, než čeká ovladač, netuším. Ale je.
Zbytek byl rutina: nainstalovat linux-headers-rpi-v8, stáhnout zdroják z repozitáře raspberrypi/linux pro stejnou větev kernelu, zkompilovat modul mimo strom kernelu, zabalit do .ko.xz, nahradit originál a depmod -a. Kompilace prošla napoprvé, reboot a… „yes yes yeeeeeeees!!!!“
Jedna past: aktualizace kernelu modul přepíše zpátky na originál. Takže po každém upgradu znovu kompilovat.
Poslední míle: konzole po startu
Obraz otočený na šířku (rotate = <90>) a správně. Jenže po bootu se na displeji objevil jen konec startovacího výpisu a přihlašovací výzva ne. Mapování konzole na framebuffer (fbcon=map:0 v cmdline.txt) bylo v pořádku, getty běžel – jen se displej nepřekreslil.
Ruční chvt 2 && chvt 1 to spravilo, tak jsem ho zabalil do malé systemd služby, která se spustí po dokončení bootu:
[Unit]
Description=Refresh framebuffer console after boot
After=plymouth-quit-wait.service getty@tty1.service
[Service]
Type=oneshot
ExecStart=/usr/bin/chvt 2
ExecStart=/bin/sleep 1
ExecStart=/usr/bin/chvt 1
RemainAfterExit=yes
[Install]
WantedBy=multi-user.targetTeď Raspberry nastartuje a na displeji čeká login. Přihlašuju se přes SSH, ale ten malý login na stole je jako kontrolka, že stroj žije.
Co si z toho beru pro ladění hardwaru s AI
AI nevidí váš stůl. Nejvíc posunuly ladění surová data: výstup dmesg, výpis overlayů, fotka desky. Dokud jsem popisoval pocity („pořád to nejde“), točili jsme se v kruhu.
Testovací obrazec místo dojmu. Boot log se na posouzení zrcadlení nehodí – AI i člověk si ho v hlavě „opraví“. Text ABCDEFGH a šipky rozhodly během vteřiny.
Když AI začne střílet do tmy, zastavit ji. Pět nápadů v jedné odpovědi je znamení, že neví. Jedna změna, jeden test, jedna odpověď – a hlavně se včas zeptat, kde je pravda. Tady to byl zdroják ovladače, který jsme mohli přečíst hned na začátku a ušetřit si hromadu rebootů.