Le motif me semble clair : The kernel maintainers simply do not want to allow any kind of hook or function or mechanism, specifically written to make it possible to load a binary-module.
Les mainteneurs du noyeau en ont un peut marre qu'on viole la GPL à tour de bras. Aujourd'hui il n'autorisent les modules proprio à titre exceptionnel et derogatoire qu'en passant par un sous ensemble de l'API, et le gas avait écrit un truc dans le driver libre spécialement concu pour charger son module proprio.
Du coup le type il rebelle parce que ca fait 3 ans qu'il avait fait ca. Mais je ne crois pas que y a 3 ans il y avait deja cette histoire de sous ensemble d'API pour les drivers proprios.
Maintenant la question est de savoir si il y a les specs complete de la cam et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
Si ya pas les specs complete et publique, franchement, personne ne peut prétendre ne pas avoir été prévenu du risque de perte partielle de performance... Avec tout ce qui a été expliqué mainte et mainte fois sur le sujet... Et j'en remet une couche : qu'en on utilise un driver proprio qui implement des fonctionnalités non documenté d'un matériel, on s'expose au risque qu'il disparaisse. C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique... Si on commence a autoriser que chaque driver libre ait un hook pour implenter un driver proprio qui gerera les fonctions interressante du materiel, on se retrouve vite avec une grosse bouse.
Si y a les specs completes et publique alors un driver libre complet renaitra surrement, ce qui est une bonne chose.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
Les mainteneurs du noyeau en ont un peut marre qu'on viole la GPL à tour de bras. Aujourd'hui il n'autorisent les modules proprio à titre exceptionnel et derogatoire qu'en passant par un sous ensemble de l'API, et le gas avait écrit un truc dans le driver libre spécialement concu pour charger son module proprio.
Du coup le type il rebelle parce que ca fait 3 ans qu'il avait fait ca. Mais je ne crois pas que y a 3 ans il y avait deja cette histoire de sous ensemble d'API pour les drivers proprios.
Maintenant la question est de savoir si il y a les specs complete de la cam et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
Si ya pas les specs complete et publique, franchement, personne ne peut prétendre ne pas avoir été prévenu du risque de perte partielle de performance... Avec tout ce qui a été expliqué mainte et mainte fois sur le sujet... Et j'en remet une couche : qu'en on utilise un driver proprio qui implement des fonctionnalités non documenté d'un matériel, on s'expose au risque qu'il disparaisse. C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique... Si on commence a autoriser que chaque driver libre ait un hook pour implenter un driver proprio qui gerera les fonctions interressante du materiel, on se retrouve vite avec une grosse bouse.
Si y a les specs completes et publique alors un driver libre complet renaitra surrement, ce qui est une bonne chose.