Sto sviluppando un sistema incorporato con un touchscreen. Il touchscreen funziona sia come input che come output, con una tastiera "virtuale" che si sovrappone all'output grafico.
Ho un driver di dispositivo funzionante che legge l'input dal sensore tattile e lo traduce correttamente in tasti premuti, creato con l'aiuto di questa guida su kernel.org . Voglio espandere questo driver per gestire anche l'output delle immagini sullo schermo.
Voglio supportare sia getty che X, con il minor numero di duplicati possibile. Sto eseguendo una variante Debian minima con pacchetti selezionati da Cherry, come X minimo. Nota che non intendo tentare di portare questo driver nella pipeline del repository, anche se potrei scaricarlo su un repository GitHub pubblico.
L'output delle immagini dello schermo viene attualmente eseguito tramite una soluzione alternativa: un'opzione di avvio per forzare il rendering all'hardware grafico incorporato della CPU, nonostante non sia collegato a un display, e un demone che raschia continuamente lo schermo di quel buffer, modifica una manciata di pre pixel definiti per creare la tastiera visiva e la spinge verso lo schermo reale.
Questo funziona come una prova del concetto, dimostrando che capisco correttamente la lingua che il dispositivo dello schermo si aspetta, ma è ovviamente non ottimale.
kernel.org ha anche una guida per i driver di dispositivo "DRM", ma sembra un grave sovraccarico per ciò che il mio hardware è in grado di:
Il livello DRM di Linux contiene codice destinato a supportare le esigenze di dispositivi grafici complessi, generalmente contenenti pipeline programmabili adatte all'accelerazione grafica 3D.
Nessuno dei miei hardware ha qualcosa di simile all'accelerazione 3D, quindi concludo che probabilmente non è quello che voglio.
Quale sottosistema / API dovrei usare? Immagino che un pezzo di terminologia mancante sia ciò che sta trattenendo le mie ricerche, ma ulteriori informazioni su come realizzare ciò sarebbero apprezzate.
Dettagli hardware (probabilmente irrilevanti): la CPU e lo schermo comunicano tramite protocollo parallelo 8080, che la CPU non supporta in modo nativo, quindi lo sto emulando con GPIO (manipolando i registri tramite mmap).
L'invio di un'immagine di schermo completa richiede circa 20 ms, ma ottenere una copia completa dal buffer grafico incorporato richiede ~ 180 ms, quindi saltare quel passaggio è l'obiettivo più importante. L'hardware dello schermo include memoria SGRAM sufficiente per mantenere un intero frame di dati e supporta la scrittura di una sottoregione rettangolare, quindi sarebbe auspicabile un hook per aggiornare solo la parte dello schermo che è stata modificata.
Lo schermo non è particolare riguardo alla tempistica dei dati in arrivo. L'ingresso del sensore tattile è gestito da un IC appositamente progettato che comunica con la CPU tramite I²C , che la CPU supporta. Il driver attuale utilizza l' linux/input-polldev.hinterfaccia. La CPU è un Broadcom BCM2835 , lo schermo è un TFT con un controller Himax HX8357 incorporato , il decodificatore del sensore touchscreen è un ST STMPE610 e c'è un variatore di livello di tensione (Nexperia 74LVCH245A ) in gioco tra l'HX8357 e il BCM2835. Maggiori dettagli sono disponibili su richiesta.