iota a écrit :En effet la réinstallation du driver résoudra le pb mais à chaque update c'est un peu ...
Je pense soit ne plus effectuer de mise à jour (du noyau tout du moins) soit me passer de l'ecran.
Chacun voit midi à sa porte
Le risque de ne plus mettre sa distrib à jour est de laisser des failles de sécurité. Si la machine n'est pas connectée à Internet, ça se discute.
Se passer de l'écran serait dommage en utilisation avec une IHM simplifiée (contrôle de processus, domotique .
Pour ma part, j'ai un petit écran du même style, offert par un de mes fils, et je galère car je dois réaliser l'interface (tel que, il n'est pas compatible Raspberry).
Ça m'a obligé à creuser le fonctionnement (j'ai pas encore terminé). Comme déjà dit, tout ces écrans se ressemblent et sont gérés à peu de choses près de la même manière.
Le Raspberry n'a pas assez de ports GPIO pour les gérer en parallèle. Il faut donc attaquer par une liaison série (port SPI) et transformer de série vers parallèle et gérer quelques signaux. C'est le rôle de la carte qui est soit livrée soit à faire (mon cas).
La bibliothèque wiringPI qui gère le SPI est désormais incluse d'office dans Raspbian (Jessie à ce jour).
La bibliothéque qui gère les écrans TFT est FBTFT, accessible ici:
https://github.com/notro/fbtft/wiki/FBTFT-on-Raspian
Après, c'est une question de paramétrage (activation du SPI, X11 sur framebuffer ...).
Le site est bien fait et intègre un wiki. Il faut bien identifier le matériel sans se laisser abuser par l'étiquette du vendeur (bien observer le circuit imprimé, le chip ...).
On est à la limite du monde de l'embarqué (GPIO, SOC, pas de HD ..) même si certains le vendent comme un mini PC (c'est limite pub mensongère).
Cela veut dire que tout n'est pas "plug and pray" mais qu'il faut mettre les mains dans le cambouis.
Bon courage
Sylvain
