Godzil (./106) :
Non de telles standadisation est souvent un frein a l'evolution. Si de tel "standard" etait mis, il serait obsolete tres rapidement, et on aurais un frein notable a l'evolution. C'est pour ca qu'un projet comme ARA n'est pas viable..

Mais... en quoi est-ce un frein à l'évolution ?!
Pour ARA, il y a d'autres problèmes, je suis d'accord (rien que pour savoir quel composant est maître, pour la gestion de l'espace physique... mais dans un smartphone où tu contrôles le contenu et l'emplacement sur la carte, j'ai du mal à voir en quoi utiliser un protocole normalisé (ne serait-ce qu'en mettant en place un standard d'énumération ou de négociation sur l'I2C, par exemple) serait un frein ou quoi que ce soit...

Godzil (./106) :
La resolution n'est pas plus detecte de nos jours qu'elle ne l'etait avant. Linux est configure avec un framebuffer de la taille X par Y et puis le soft se demerde avec. Oui en HDMI, DVI, DP tu as des infos sur les capacite de l'ecran, quand tu branche directemetn ton ecran a ton CPU via l'interface dedie (et souvent programmatiquement specifique au CPU) ce genre d'info n'existe pas, c'est a toi, développeur du produit de dire au kernel "au fait l’écran il fait 489x647 pixels avec 8.2bits par channel et tu as 5 channel par pixel".

Mais les smartphones peuvent gérer l'affichage en HDMI, pourquoi ne pas l'utiliser en interne ? Et si le souci est le prix de la licence HDMI, le DP est ouvert est libre à ce niveau... je ne comprends pas la nécessité de vouloir réinventer la roue et s'embêter à utiliser des protocoles non souples alors que le matériel supporte les protocoles avancés qui permettraient, justement, d'avoir une base d'OS facilement réutilisable pour tous les modèles... c'est une forme de masochisme...
Autant pour de l'embarqué pur, je le comprends (avec un 68000 ou un vieux 80x86 dans un lave-linge, ok, on utilise des protocoles série de base), autant là, on a quand-même un processeur avancé, qui gère des protocoles d'E/S performants...