Pour le défaut niveau driver et ta remarque sur HTC, je ne peux que raler:
-La quasi-totalité des drivers sont libres.
À ma connaissance, sur les systèmes récents (snapdragon), seule la 3D et la communication radio (au sens propre, pas au sens processeur radio) est fermée, et encore c'est des simples commandes AT relativement banales, je crois bien que le projet Replicant a une RIL (cette interface de communication.) qui marche. Concernant cette dernière, je pense même qu'ils peuvent avoir des problèmes de secret "défense" derrière: J'ai découvert à ma grande surprise que la possibilité de faire de requêtes GPS à distance est gérée par cette RIL.
Et concernant la 3D, la partie noyau du driver a été libérée y a quelques mois, je ne sais pas trop s'ils prévoient quoique ce soit concernant la partie utilisateur. (qui est amha d'un intérêt extrêmement limité)
-Et même mieux que la liberté (parce qu'avec android y a des fois des sueurs froides de ce point de vue):
À l'heure actuelle, la quasi totalité des drivers permettent d'utiliser des APIs linux propres !
Drivers ALSA pour le son, V4L2 pour les caméra, framebuffer pour la vidéo, driver Xorg accéléré, avec gestion 3D (proprio quand même la partie 3D). Il n'y a guère que l'accélération de décodage vidéo qui n'utilise pas d'API propre, étant donné qu'il n'y en a pas. Mais là ils se basent quand même sur un produit déjà existant, OpenCore, et qui peut tout à fait être utilisé sur un GNU/Linux normal.
Mais tout ce travail ne vient PAS de Google ni de HTC.
Il vient de Qualcomm. C'est une société qui vend du hard, et point barre. Elle fournit des drivers pour ce qu'on lui demande, et le fait (amha) bien, même s'ils pourraient essayer de pousser un peu plus fort en mainline.
Maintenant que j'ai dit du bien des noyaux qualcomm, je vais pouvoir taper sur Google/HTC.
J'ai dit précedement que qualcomm fournit des APIs Linux standard, sauf qu'en fait, Android HTC ne les utilise pas du tout.
Par exemple, la gestion sonore ou de la camera se fait à travers des périphériques /dev/msm_*, la gestion de la mémoire "physique" (nécessaire car la mémoire est partagée entre tous les "coeurs" du SoC, 3D, DSP, etc) se fait par un périphérique créé pour l'occasion (pmem). Qualcomm tend à se débarrasser de cette dépendance, Google eux ne font rien pour.
Mais tout ça tient un peu de l'historique, car je suppose que ce sont des contournements par flemme qu'avaient fait Qualcomm au début de ses noyaux. Maintenant on va parler de l'actuel, après différentes évolutions
Donc la gestion sonore sur les plate-formes qualcomm reste globalement complétement dans le noyau, la seule chose qui change par rapport à de l'ALSA est l'API complétement différente. Pour le son, un truc qui peut toujours servir est un amplificateur, pour sortir sur un haut parleur (rien de bien méchant, 3/4 commandes sur I2C et c'est réglé). Et bien ce que Google et HTC ont fait (aussi bien sur le Desire que le Nexus One), est de faire un driver I2C idiot, qui ne fait que transmettre les commandes entre l'espace utilisateur et le noyau. Ainsi donc, c'est à l'espace utilisateur de s'adapter au hard. (Autant utiliser un micro noyau non ?). Mais les commandes I2C sont quand même sous formes d'ioctl explicite genre SET_AGC_VALUE ou ce genre de choses. Mais toujours chez HTC(y compris N1), on trouve un petit device dans /dev, au doux nom de htc_acoustic. Ce périphérique est juste là pour mettre à l'espace utilisateur d'accéder à la mémoire physique de la gestion sonore (en fait il s'agit de calibrer les CAN/CNA de ce que j'ai pu voir). Ainsi donc on a un noyau complètement libre, pourtant on reste avec du son complètement inutilisable chez HTC, alors qu'avec d'autres fournisseurs ça juste marche. Bon après, écrire un driver pour remplacer cette saleté de htc_acoustic n'est pas spécialement compliqué non plus à faire.
Enfin, histoire de râler encore un peu plus, Qualcomm propose des driver GPS libres. Google/HTC préfèrent utiliser une version précedente (encore un héritage en fait) propriétaire.
[^] # Re: ça me rappelle symbian
Posté par Ph Husson (site web personnel) . En réponse au journal [HS] Probablement le plus gros foutage de gueule de l'année ? la lettre d'Apple. Évalué à 7.
-La quasi-totalité des drivers sont libres.
À ma connaissance, sur les systèmes récents (snapdragon), seule la 3D et la communication radio (au sens propre, pas au sens processeur radio) est fermée, et encore c'est des simples commandes AT relativement banales, je crois bien que le projet Replicant a une RIL (cette interface de communication.) qui marche. Concernant cette dernière, je pense même qu'ils peuvent avoir des problèmes de secret "défense" derrière: J'ai découvert à ma grande surprise que la possibilité de faire de requêtes GPS à distance est gérée par cette RIL.
Et concernant la 3D, la partie noyau du driver a été libérée y a quelques mois, je ne sais pas trop s'ils prévoient quoique ce soit concernant la partie utilisateur. (qui est amha d'un intérêt extrêmement limité)
-Et même mieux que la liberté (parce qu'avec android y a des fois des sueurs froides de ce point de vue):
À l'heure actuelle, la quasi totalité des drivers permettent d'utiliser des APIs linux propres !
Drivers ALSA pour le son, V4L2 pour les caméra, framebuffer pour la vidéo, driver Xorg accéléré, avec gestion 3D (proprio quand même la partie 3D). Il n'y a guère que l'accélération de décodage vidéo qui n'utilise pas d'API propre, étant donné qu'il n'y en a pas. Mais là ils se basent quand même sur un produit déjà existant, OpenCore, et qui peut tout à fait être utilisé sur un GNU/Linux normal.
Mais tout ce travail ne vient PAS de Google ni de HTC.
Il vient de Qualcomm. C'est une société qui vend du hard, et point barre. Elle fournit des drivers pour ce qu'on lui demande, et le fait (amha) bien, même s'ils pourraient essayer de pousser un peu plus fort en mainline.
Maintenant que j'ai dit du bien des noyaux qualcomm, je vais pouvoir taper sur Google/HTC.
J'ai dit précedement que qualcomm fournit des APIs Linux standard, sauf qu'en fait, Android HTC ne les utilise pas du tout.
Par exemple, la gestion sonore ou de la camera se fait à travers des périphériques /dev/msm_*, la gestion de la mémoire "physique" (nécessaire car la mémoire est partagée entre tous les "coeurs" du SoC, 3D, DSP, etc) se fait par un périphérique créé pour l'occasion (pmem). Qualcomm tend à se débarrasser de cette dépendance, Google eux ne font rien pour.
Mais tout ça tient un peu de l'historique, car je suppose que ce sont des contournements par flemme qu'avaient fait Qualcomm au début de ses noyaux. Maintenant on va parler de l'actuel, après différentes évolutions
Donc la gestion sonore sur les plate-formes qualcomm reste globalement complétement dans le noyau, la seule chose qui change par rapport à de l'ALSA est l'API complétement différente. Pour le son, un truc qui peut toujours servir est un amplificateur, pour sortir sur un haut parleur (rien de bien méchant, 3/4 commandes sur I2C et c'est réglé). Et bien ce que Google et HTC ont fait (aussi bien sur le Desire que le Nexus One), est de faire un driver I2C idiot, qui ne fait que transmettre les commandes entre l'espace utilisateur et le noyau. Ainsi donc, c'est à l'espace utilisateur de s'adapter au hard. (Autant utiliser un micro noyau non ?). Mais les commandes I2C sont quand même sous formes d'ioctl explicite genre SET_AGC_VALUE ou ce genre de choses. Mais toujours chez HTC(y compris N1), on trouve un petit device dans /dev, au doux nom de htc_acoustic. Ce périphérique est juste là pour mettre à l'espace utilisateur d'accéder à la mémoire physique de la gestion sonore (en fait il s'agit de calibrer les CAN/CNA de ce que j'ai pu voir). Ainsi donc on a un noyau complètement libre, pourtant on reste avec du son complètement inutilisable chez HTC, alors qu'avec d'autres fournisseurs ça juste marche. Bon après, écrire un driver pour remplacer cette saleté de htc_acoustic n'est pas spécialement compliqué non plus à faire.
Enfin, histoire de râler encore un peu plus, Qualcomm propose des driver GPS libres. Google/HTC préfèrent utiliser une version précedente (encore un héritage en fait) propriétaire.