Godzil (./67) :Ok, admettons... sauf que les PC d'il y a 30 ans avaient des normes assez foutraques et que progressivement, il y a eu des avancées (le Plug'n Play, la fin de l'ISA qui permettait tout et n'importe quoi...). Pourquoi est-ce que ça ne serait pas le cas pour les plateformes ARM ?
Au passage l'enorme difference entre un PC et un machin embarque, c'est que le PC est base sur des NORMES de fabrications: bus PCI(e), IOs standardise, SMBus, espace memoire standard, tables ACPI lourdingues, peripheriques standard et ce bon vieux BIOS qui fourni un poil d'abstraction tout en founissant des services des annees 80 dans des machines de 2010.
flanker (./61) :Comment fonctionne Linux pour ARM, du coup ? Ou Windows pour ARM ? Et pourquoi est-ce que les périphériques USB sont bien détectés ? (questions naïves, hein, c'est vraiment pour savoir).
Mais la plate-forme ARM ne dispose pas d'instructions pour détecter le matériel connecté, contrairement à la plate-forme PC.
Nil (./92) :Justement non! A l'origine les PC etait bien plus standard qu'ils ne le sont maintenant, ils sont tous a la base des clones de l'IBM PC, il y avais pas trouzemilles types de CPU/Carte graphique & co a l'époque.
Ok, admettons... sauf que les PC d'il y a 30 ans avaient des normes assez foutraques et que progressivement, il y a eu des avancées (le Plug'n Play, la fin de l'ISA qui permettait tout et n'importe quoi...). Pourquoi est-ce que ça ne serait pas le cas pour les plateformes ARM ?
Nhut (./98) :Faut venir à Vienne (Autriche) alors, on a toujours les billets en papier ici. Pour les abonnements annuels, on a maintenant du tout neuf: une carte en plastique, type carte de crédit, mais sans carte à puce ni bande magnétique, faite pour la vérification optique comme l'ancienne version en papier laminé, mais avec sur le dos, pour la vérification automatique (qu'on ne m'a jamais faite jusqu'à présent)… un code QR (et encore, c'est peut-être juste une URL informative, j'ai la flemme de scanner et décoder le code…).
Hé bien moi je me plains des cartes NFC pour pointer dans les bus parce que c'était mieux avant avec les cartes en carton à insérer dans les poinçonneuses.
Zerosquare (./99) :Je suis au contraire contre la suppression de fonctionnalités. Je ne supprime jamais de fonctionnalités de mes logiciels. La seule fois dans toute l'histoire de TIGCC qu'on m'a reproché de "supprimer une fonctionnalité", c'était quand j'ai remplacé le support pour VTI par celui pour TiEmu, émulateur qui a strictement toutes les fonctionnalités de VTI et plein d'autres en plus. (Et encore, rien n'empêche de continuer à utiliser VTI, c'est juste l'intégration à l'EDI qui utilise maintenant un émulateur plus adapté.) Justement, j'ai fait très attention à proposer toutes les fonctionnalités de VTI dans TiEmu, c'est pour ça que j'ai mis l'émulation du son tout en haut de la liste de priorités et participé à son codage (elle a été codée par Peter Fernandes (hypersonic) et moi), alors que je m'en serais personnellement très bien passé. Parfois, on m'a au contraire reproché de ne pas supprimer des fonctionnalités, comme la réutilisation de LCD_MEM comme plan de gris sur HW1.
C'est amusant : tu es le premier à vouloir que les logiciels suppriment des features que tu juges "obsolètes", par contre il faudrait que les fabricants n'aient pas le droit de le faire avec le matériel ?
Zerosquare (./95) :Mais ce ne serait pas un atout pour les fabricants que de n'avoir qu'un seul socle à gérer pour tous leurs modèles de smartphones ? En terme de gestion des coûts, de gestion du temps, de gestion de la compétence humaine... ça me paraît tout de même être vachement plus rationnel...
Sauf qu'encore une fois, le PC est une plateforme modulaire et ouverte, pour laquelle les constructeurs de périphériques ont intérêt à ce que leurs clients puissent utiliser facilement leurs produits. Un smartphone est une plateforme monolithique et fermée, et les clients des constructeurs de composants sont les fabricants de portables, pas les utilisateurs directement.
Godzil (./96) :Sauf que 90% des périphériques d'un smartphone est géré par l'USB ou un protocole normalisé, non ? A part l'écran (et éventuellement les 2/3 boutons physiques), tout ce qui est communication, appareil photo, gestion des cartes mémoires peut se faire (se fait ?) via l'USB. Et même rapport à l'écran, Android sur ARM est capable d'en détecter la résolution (au moins depuis Android 5), il suffit de voir ce qu'on peut faire avec le MHL+Andromium OS.
(Et le DeviceTree n'indique pas tout loin de la, et ce n'est pas plug & play.)L'USB est un truc a part.
Nil (./105) :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..Zerosquare (./95) :Mais ce ne serait pas un atout pour les fabricants que de n'avoir qu'un seul socle à gérer pour tous leurs modèles de smartphones ? En terme de gestion des coûts, de gestion du temps, de gestion de la compétence humaine... ça me paraît tout de même être vachement plus rationnel...
Sauf qu'encore une fois, le PC est une plateforme modulaire et ouverte, pour laquelle les constructeurs de périphériques ont intérêt à ce que leurs clients puissent utiliser facilement leurs produits. Un smartphone est une plateforme monolithique et fermée, et les clients des constructeurs de composants sont les fabricants de portables, pas les utilisateurs directement.
Godzil (./96) :Sauf que 90% des périphériques d'un smartphone est géré par l'USB ou un protocole normalisé, non ? A part l'écran (et éventuellement les 2/3 boutons physiques), tout ce qui est communication, appareil photo, gestion des cartes mémoires peut se faire (se fait ?) via l'USB. Et même rapport à l'écran, Android sur ARM est capable d'en détecter la résolution (au moins depuis Android 5), il suffit de voir ce qu'on peut faire avec le MHL+Andromium OS.
(Et le DeviceTree n'indique pas tout loin de la, et ce n'est pas plug & play.)L'USB est un truc a part.
Godzil (./106) :Mais... en quoi est-ce un frein à l'évolution ?!
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..
Godzil (./106) :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...
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".
Nil (./107) :Crayoune, on ne pourrait pas téléphoner en HD 7.1 ?
Mais... en quoi est-ce un frein à l'évolution ?!
Godzil (./112) :l'inverse plutôt, non ?
• Godzil a envie d'installer un lecteur 8" dans son portable
vince (./113) :Godzil (./112) :l'inverse plutôt, non ?
• Godzil a envie d'installer un lecteur 8" dans son portable
Folco (./102) :Euh si, on vous a écoutés, on a réduit le nombre de fenêtres du débogueur ouvertes par défaut au strict minimum (2 dans la version GDB, 1 dans la version no-GDB):
C'est là qu'on voit que t'as jamais écouté les demandes des utilisateurs : c'était pas une question de fonctionnalité, mais d'interface merdique, qui rendait TiEmu pénible à utiliser.
Godzil (./110) :Ok, admettons, même si je reste persuadé que le coût serait compensé par les économies faites, justement par ailleurs.
Parce ce que tu ne vois pas Nil c'est que ta dalle LCD ne parle pas nativement le HDMI ou le DP, il y a des composants entre la dalle et le cable et entre le cable ta carte vidéo. Composants complètement inutiles quand tu peux brancher directement l’écran a la sortie vidéo de ton MCU et ce n'est ni du DisplayPort ni du HDMI. Ce n'est pas qu'une question de performances (même si ça a quand même un impact) mais devoir ajouter 36 composants pour supporter une interface "standard", que le composant soit en interne (sur le die) ou en externe a un cout non négligeable.
Godzil (./110) :Il y a des groupes de travail qui sont capables de définir des standards dans plein de domaines (dont la téléphonie). Ce n'est pas arbitraire, ça dépend surtout de la volonté des constructeurs (et de Google, et de ARM). Je gage que si 3 grands fabricants s'y mettent, tous le feront (à part éventuellement pour l'entrée de gamme).
Et qui va arbitrairement définir le standard? Il sera toujours fait pour avantager X ou Y au détriment de Z.
Godzil (./110) :Bah non, c'est le modèle d'Apple, et ce n'est certainement pas le bon
Autant n'avoir plus qu'un seul fabricant de composant un seul fabricant de smartphone, comme ca, tous les problemes son regle, tout est uniformise, standadise, bref, parfait! Ou pas.
Godzil (./110) :On est sur un smartphone, donc avec des seuils de criticité à relativiser en terme de BP (sinon on partirait sur autre chose qu'un ARM et on aurait plein de copros dédiés à ça ^^). Le problème de la consommation électrique, ok. Mais faudrait-il avoir des chiffres pour argumenter à ce niveau.
Pourquoi un frein? simplement parce qu'une interface universelle qui réponds a TOUS les besoins n'existe pas. Tu auras toujours des limites en terme de bande passante, de consommation ou autre. Si l’idée c'est d'utiliser une interface et de toute de suite la bypasser pour faire autre chose, autant se passer de la dite interface inutile non?