la question revient souvent du pb des drivers de cartes vidéos sous Linux.
Et si l'on proposait des kits de cartes vidéos (ou autres) à monter
soi-même à partir de composants électroniques standards, avec bios et
driver libres à télécharger.
Le problème serait enfin résolu. Et du coup, les fabricants de matériel
voyant leur marché leur échapper se mettrait soudainement à diffuser
leurs drivers pour tout type de système.
Certes, au début les perfs ne seraient pas aussi bonnes qu'avec les
cartes commerciales, mais qui c'est, si on cherche à développer des
cartes vidéos à partir de proc pentium (ou autres) en parallèle, si cela
ne donnerait pas des résultats intéressants ?
L'idée c'est de propager la philosophie du libre du monde virtuel vers
le monde réel.
Le Thu, 07 Apr 2011 10:33:59 +0200 Williamhoustra a écrit :
Alexi Dubois a écrit : > la question revient souvent du pb des drivers de cartes vidéos sous > Linux. > Le problème de Linux (et son intérêt) c'est sa richesse en options graphiques diverses. Mais il est sûr que ça ne motive pas les programmeurs de drivers. Par exemple pour Windows il suffit de prévoir l'ancienne version (XP) et la nouvelle (7) laquelle va être déclinée entre version 32 et 64 bits. C'est tout et ça représente 95 % du marché des PC. Pour Linux, soyons optimiste et allons jusqu'à 5 % du marché, mais combien de groupes de distributions nécessitant chacun un driver spécifique ?
Pourquoi le pilote serait spécifique à chaque distribution ? C'est le serveur X qui gère le pilote. C'est vrai que l'interface avec les pilotes change parfois, mais il n'y a pas des centaines de versions non plus.
> Certes, au début les perfs ne seraient pas aussi bonnes qu'avec les > cartes commerciales, mais qui c'est, si on cherche à développer des > cartes vidéos à partir de proc pentium (ou autres) en parallèle, si > cela ne donnerait pas des résultats intéressants ? > > L'idée c'est de propager la philosophie du libre du monde virtuel > vers le monde réel.
Là c'est impossible techniquement ! On en est plus aux cartes qui se contentaient d'un affichage pour la bureautique ! Si les (bonnes) cartes graphiques coûtent plus cher que les cartes mères, ce n'est pas pour rien.
Tout le monde n'a pas besoin d'une carte graphique à la pointe du progès.
Le Thu, 07 Apr 2011 10:33:59 +0200
Williamhoustra <williamhoustra@trapellun.net> a écrit :
Alexi Dubois a écrit :
> la question revient souvent du pb des drivers de cartes vidéos sous
> Linux.
>
Le problème de Linux (et son intérêt) c'est sa richesse en options
graphiques diverses. Mais il est sûr que ça ne motive pas les
programmeurs de drivers. Par exemple pour Windows il suffit de
prévoir l'ancienne version (XP) et la nouvelle (7) laquelle va être
déclinée entre version 32 et 64 bits. C'est tout et ça représente 95
% du marché des PC. Pour Linux, soyons optimiste et allons jusqu'à 5
% du marché, mais combien de groupes de distributions nécessitant
chacun un driver spécifique ?
Pourquoi le pilote serait spécifique à chaque distribution ? C'est le
serveur X qui gère le pilote. C'est vrai que l'interface avec les
pilotes change parfois, mais il n'y a pas des centaines de versions non
plus.
> Certes, au début les perfs ne seraient pas aussi bonnes qu'avec les
> cartes commerciales, mais qui c'est, si on cherche à développer des
> cartes vidéos à partir de proc pentium (ou autres) en parallèle, si
> cela ne donnerait pas des résultats intéressants ?
>
> L'idée c'est de propager la philosophie du libre du monde virtuel
> vers le monde réel.
Là c'est impossible techniquement ! On en est plus aux cartes qui
se contentaient d'un affichage pour la bureautique ! Si les (bonnes)
cartes graphiques coûtent plus cher que les cartes mères, ce n'est
pas pour rien.
Tout le monde n'a pas besoin d'une carte graphique à la pointe du
progès.
Le Thu, 07 Apr 2011 10:33:59 +0200 Williamhoustra a écrit :
Alexi Dubois a écrit : > la question revient souvent du pb des drivers de cartes vidéos sous > Linux. > Le problème de Linux (et son intérêt) c'est sa richesse en options graphiques diverses. Mais il est sûr que ça ne motive pas les programmeurs de drivers. Par exemple pour Windows il suffit de prévoir l'ancienne version (XP) et la nouvelle (7) laquelle va être déclinée entre version 32 et 64 bits. C'est tout et ça représente 95 % du marché des PC. Pour Linux, soyons optimiste et allons jusqu'à 5 % du marché, mais combien de groupes de distributions nécessitant chacun un driver spécifique ?
Pourquoi le pilote serait spécifique à chaque distribution ? C'est le serveur X qui gère le pilote. C'est vrai que l'interface avec les pilotes change parfois, mais il n'y a pas des centaines de versions non plus.
> Certes, au début les perfs ne seraient pas aussi bonnes qu'avec les > cartes commerciales, mais qui c'est, si on cherche à développer des > cartes vidéos à partir de proc pentium (ou autres) en parallèle, si > cela ne donnerait pas des résultats intéressants ? > > L'idée c'est de propager la philosophie du libre du monde virtuel > vers le monde réel.
Là c'est impossible techniquement ! On en est plus aux cartes qui se contentaient d'un affichage pour la bureautique ! Si les (bonnes) cartes graphiques coûtent plus cher que les cartes mères, ce n'est pas pour rien.
Tout le monde n'a pas besoin d'une carte graphique à la pointe du progès.
Pascal Hambourg
Salut,
Baton Rouge a écrit :
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Salut,
Baton Rouge a écrit :
La meilleurs solution, c'est que chaque matos embarque son driver et
que les os communiquent uniquement avec des API fourni par les
constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ?
Apparemment, ça n'a pas marché.
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des workaround dans les pilotes I2O, ce qui fait qu'on revient assez rapidement peu ou prou à la situation un matériel, un pilote.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
La meilleurs solution, c'est que chaque matos embarque son driver et
que les os communiquent uniquement avec des API fourni par les
constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ?
Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des
workaround dans les pilotes I2O, ce qui fait qu'on revient assez
rapidement peu ou prou à la situation un matériel, un pilote.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des workaround dans les pilotes I2O, ce qui fait qu'on revient assez rapidement peu ou prou à la situation un matériel, un pilote.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Baton Rouge
On Fri, 8 Apr 2011 17:29:24 +0000 (UTC), JKB wrote:
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des workaround dans les pilotes I2O, ce qui fait qu'on revient assez rapidement peu ou prou à la situation un matériel, un pilote.
JKB
Mais rien n'empeche la possibilité de flasher le firmware par une mise à jour du constructeur ?
-- Les Américains ont Steve Jobs, nous on a Paul Emploi
La meilleurs solution, c'est que chaque matos embarque son driver et
que les os communiquent uniquement avec des API fourni par les
constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ?
Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des
workaround dans les pilotes I2O, ce qui fait qu'on revient assez
rapidement peu ou prou à la situation un matériel, un pilote.
JKB
Mais rien n'empeche la possibilité de flasher le firmware par une mise
à jour du constructeur ?
--
Les Américains ont Steve Jobs, nous on a Paul Emploi
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des workaround dans les pilotes I2O, ce qui fait qu'on revient assez rapidement peu ou prou à la situation un matériel, un pilote.
JKB
Mais rien n'empeche la possibilité de flasher le firmware par une mise à jour du constructeur ?
-- Les Américains ont Steve Jobs, nous on a Paul Emploi
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des workaround dans les pilotes I2O, ce qui fait qu'on revient assez rapidement peu ou prou à la situation un matériel, un pilote.
JKB
Mais rien n'empeche la possibilité de flasher le firmware par une mise à jour du constructeur ?
Oui ? Encore faut-il que le constructeur en fournisse u qui soit moins buggué...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
La meilleurs solution, c'est que chaque matos embarque son driver et
que les os communiquent uniquement avec des API fourni par les
constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ?
Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des
workaround dans les pilotes I2O, ce qui fait qu'on revient assez
rapidement peu ou prou à la situation un matériel, un pilote.
JKB
Mais rien n'empeche la possibilité de flasher le firmware par une mise
à jour du constructeur ?
Oui ? Encore faut-il que le constructeur en fournisse u qui soit
moins buggué...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
Et pour cause. Lorsque le matériel est buggué, il faut écrire des workaround dans les pilotes I2O, ce qui fait qu'on revient assez rapidement peu ou prou à la situation un matériel, un pilote.
JKB
Mais rien n'empeche la possibilité de flasher le firmware par une mise à jour du constructeur ?
Oui ? Encore faut-il que le constructeur en fournisse u qui soit moins buggué...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Az Sam
"Pascal Hambourg" a écrit dans le message de news:inng9s$20pe$
Salut,
Baton Rouge a écrit :
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
vous êtes tous obligés de reprendre le Xpost mal foutu ?
Pascal, vous ne causez même pas de matériel et on est très très éloigné de la vision de fcmo stricto O/C que tu décrivais il y a quelques semaines.
FU2 positionné.
-- Cordialement, Az Sam.
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news:inng9s$20pe$1@saria.nerim.net...
Salut,
Baton Rouge a écrit :
La meilleurs solution, c'est que chaque matos embarque son driver et
que les os communiquent uniquement avec des API fourni par les
constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ?
Apparemment, ça n'a pas marché.
vous êtes tous obligés de reprendre le Xpost mal foutu ?
Pascal, vous ne causez même pas de matériel et on est très très éloigné de
la vision de fcmo stricto O/C que tu décrivais il y a quelques semaines.
"Pascal Hambourg" a écrit dans le message de news:inng9s$20pe$
Salut,
Baton Rouge a écrit :
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
Ce n'est pas ce que faisait I2O (Intelligent Input/Output) ? Apparemment, ça n'a pas marché.
vous êtes tous obligés de reprendre le Xpost mal foutu ?
Pascal, vous ne causez même pas de matériel et on est très très éloigné de la vision de fcmo stricto O/C que tu décrivais il y a quelques semaines.
FU2 positionné.
-- Cordialement, Az Sam.
Alexi Dubois
Baton Rouge a écrit :
On Wed, 06 Apr 2011 22:03:02 +0200, Alexi Dubois wrote:
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
en fait, il faudrait créer un standard de bios étendu qui définirait toute l'interface nécessaire aux matériels d'aujourd'hui, les drivers étant intégrés dans des roms de chaque composant.
C'est bien à partir d'un standard de base vga, ide, souris ps2 etc... que le pc peut démarrer et lancer le logiciel d'install du système d'exploitation.
La meilleurs solution, c'est que chaque matos embarque son driver et
que les os communiquent uniquement avec des API fourni par les
constructeurs.
en fait, il faudrait créer un standard de bios étendu qui définirait
toute l'interface nécessaire aux matériels d'aujourd'hui, les drivers
étant intégrés dans des roms de chaque composant.
C'est bien à partir d'un standard de base vga, ide, souris ps2 etc...
que le pc peut démarrer et lancer le logiciel d'install du système
d'exploitation.
On Wed, 06 Apr 2011 22:03:02 +0200, Alexi Dubois wrote:
La meilleurs solution, c'est que chaque matos embarque son driver et que les os communiquent uniquement avec des API fourni par les constructeurs.
en fait, il faudrait créer un standard de bios étendu qui définirait toute l'interface nécessaire aux matériels d'aujourd'hui, les drivers étant intégrés dans des roms de chaque composant.
C'est bien à partir d'un standard de base vga, ide, souris ps2 etc... que le pc peut démarrer et lancer le logiciel d'install du système d'exploitation.
Tonton Th
On 04/07/2011 06:06 AM, Yliur wrote:
Le matériel libre est une idée qui existe déjà et il existe déjà des choses, mais pas des cartes vidéo. Ça se construit a priori difficilement à partir de composants standards.
http://wiki.opengraphics.org/tiki-index.php
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 04/07/2011 06:06 AM, Yliur wrote:
Le matériel libre est une idée qui existe déjà et il existe déjà des
choses, mais pas des cartes vidéo. Ça se construit a priori
difficilement à partir de composants standards.
http://wiki.opengraphics.org/tiki-index.php
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Le matériel libre est une idée qui existe déjà et il existe déjà des choses, mais pas des cartes vidéo. Ça se construit a priori difficilement à partir de composants standards.
http://wiki.opengraphics.org/tiki-index.php
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
