Quel sous-système / API de pilote Linux est utilisé pour un périphérique écran / moniteur simple?


9

Je développe un système embarqué avec un écran tactile. L'écran tactile fonctionne à la fois en entrée et en sortie, avec un clavier "virtuel" recouvrant la sortie graphique.

J'ai un pilote de périphérique qui lit les entrées du capteur tactile et le traduit correctement en appuyant sur les touches, créé à l'aide de ce guide sur kernel.org . Je souhaite étendre ce pilote pour gérer également la sortie d'image vers l'écran.

Je veux soutenir à la fois Getty et X, avec le moins de duplication possible. J'exécute une variante minimale de Debian avec des paquets choisis par cerise, comme minimal X. Notez que je n'ai pas l'intention d'essayer de faire entrer ce pilote dans le pipeline du référentiel, bien que je puisse le vider sur un référentiel GitHub public.

La sortie des images d'écran se fait actuellement via une solution de contournement croustillante: une option de démarrage pour forcer le rendu sur le matériel graphique intégré du CPU, bien qu'il ne soit pas connecté à un écran, et un démon qui scrute en continu ce tampon, modifie une poignée de pré- pixels définis pour créer le visuel du clavier et le pousser vers l'écran réel.

Cela fonctionne comme une preuve de concept, prouvant que je comprends correctement la langue attendue par le périphérique d'écran, mais est évidemment sous-optimale.

kernel.org a également un guide pour les pilotes de périphériques "DRM", mais cela semble être une exagération sérieuse pour ce que mon matériel est capable de:

La couche Linux DRM contient du code destiné à prendre en charge les besoins des périphériques graphiques complexes, contenant généralement des pipelines programmables bien adaptés à l'accélération graphique 3D.

Aucun de mes matériels ne ressemble à une accélération 3D, donc je conclus que ce n'est probablement pas ce que je veux.

Quel sous-système / API dois-je utiliser? Je pense qu'une partie de la terminologie manquante est ce qui freine mes recherches, mais tout renseignement supplémentaire sur la façon d'y parvenir serait apprécié.

Détails du matériel (probablement non pertinents): le CPU et l'écran communiquent via un protocole parallèle 8080, que le CPU ne prend pas en charge nativement, donc je l'émule avec des GPIO (en manipulant des registres via mmap).

L'envoi d'une image d'écran complète prend environ 20 ms, mais l'obtention d'une copie complète à partir du tampon graphique intégré prend ~ 180 ms, donc sauter cette étape est l'objectif le plus important. Le matériel de l'écran comprend suffisamment de mémoire SGRAM pour conserver une valeur de trame entière de données et prend en charge l'écriture d'une sous-région rectangulaire, donc un crochet pour mettre à jour uniquement la partie de l'écran qui a changé serait souhaitable.

L'écran n'est pas particulier sur le timing des données entrantes. L'entrée du capteur tactile est gérée par un circuit intégré spécialement conçu qui communique avec le processeur via I²C , que le processeur prend en charge. Le pilote actuel utilise l' linux/input-polldev.hinterface. Le CPU est un Broadcom BCM2835 , l'écran est un TFT avec un contrôleur Himax HX8357 intégré, le décodeur du capteur à écran tactile est un ST STMPE610 , et il y a un élévateur de niveau de tension (Nexperia 74LVCH245A ) en jeu entre le HX8357 et le BCM2835. Plus de détails sont disponibles sur demande.


Je suis presque sûr que vous êtes atteint du syndrome NIH et que vous avez essentiellement réinventé une roue - généralement, l'écran tactile utilise le protocole HID, qui est plutôt plus que moins pris en charge. Remarque, l'écran tactile est uniquement un périphérique d'entrée.
0andriy

@ 0andriy Réinventer la roue est un peu mon truc tbh, mais il n'y avait pas de pilotes (réels) pour ce périphérique spécifique quand j'ai commencé. Je ne connais aucun protocole standardisé pour les périphériques d'interface humaine, mais s'il y en a un, je suis presque sûr que la superposition tactile que j'utilise ici ne l'utilise pas. Je ne suis pas d'accord sur le fait qu'un «écran tactile n'est qu'un périphérique d'entrée», car le mien produit très certainement des images.
memtha

Vous n'avez simplement pas reconnu deux blocs matériels dans un seul paquet. L'écran tactile, sans tenir compte de son nom, n'est qu'un périphérique d'entrée. Celui de sortie est appelé, par exemple, panneau ou écran TFT.
0andriy

merriam-webster.com/dictionary/touchscreen Oui, il existe deux éléments matériels distincts: une superposition tactile et un écran TFT. Ces deux composants se combinent pour former l'écran tactile. Vous ne pouvez pas me dire que je définis mal l'écran tactile en me disant de "ne pas tenir compte du nom".
memtha

Réponses:


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.