Ph Husson a écrit 2699 commentaires

Faut attendre le vendredi pour mentir ? (Nan parce que bon tout le monde sait que le meilleur shell au monde c'est powershell)

Les GPUs nvidia récents ont une option de conformité IEEE-754, j'ai plus trop les détails en tête. D'après wikipedia, la précision double est parfaitement conforme, la précision simple moins.
En ce qui concerne le prix, y avait un tableau assez complet à ce propos qui faisait des benchmark se basant sur Folding@home, et rajoutant la consommation comme facteur(qui est important en ce qui concerne le prix quand même..), mais j'arrive pas à remettre la main dessus.
Pour information, ma carte actuelle, une 9600gso aka 8800gs aka encore un autre nom que j'ai pas retenu, qui est dans les 100€, fait d'après Folding@Home dans les 60GFlops, qui explose à peu près complètement (bon un rapport ~ 5 de mémoire) mon CPU, Core 2 Q6600, qui a couté plus du double.
Bon après comme dit au dessus, évidement ca dépend fortement de l'algorithme.

Il me semble que sur les Geforce 8000 et supérieur, la mise en veille sur RAM devrait marcher systématiquement du moment qu'on fait un vbetool post (et plus aléatoirement comme c'était le cas avant.)

Protocole proprio flash pour le moment :/ (Mais ils ont annoncé qu'ils l'ouvriraient quand même)

Sachant que l'OpenGL est accessible en DirectFB ce que tu dis me semble passablement idiot.

C'est quand même pas de pot, une raison de virer le driver kbd et de passer à evdev c'était de pouvoir mettre 2 serveurs X en parallele pour mettre plusieurs utilisateurs par ordinateur en même temps /o\

Donc, c'est cassé depuis un bail (~1,5 ans, je crois), et pour encore au moins un autre... reste DMX : pour avoir plus d'écrans, ayons plus de machines

Tu peux lancer plusieurs serveurs en parallèle, avec un par carte graphique, et y mettre DMX derrière je penses.
(En ce qui concerne le framebuffer, j'en sais trop rien mais ca m'étonnerait qu'ils gérent ca)

Et quand cette solution framebuffer apportera
- la transparence réseau,
- les drivers accélérés,
- le multi-écrans entre une carte Intel, une Nvidia et une Ati,
- la gestion des différents périphériques d'entrée (souris, écran tactile, tablette graphique avancée, ...),
- le côté asynchrone...

Pourquoi parler au futur ? Tout ca est déjà supporté, sauf peut être le multiécran multicarte (qui soit dit en passant, marche assez mal sous Xorg....) et le côté asynchrone dont je sais pas du tout vu que ca rentre pas dans ce que j'utilisais.

Enfin, lorsque les toolkits (puis les applications) auront été portés vers cette nouvelle solution, qu'y aura-t-on gagné au final ? Une nouvelle couche supplémentaire (parce qu'il faut bien un niveau d'abstraction pour que ça fonctionne sous les différents OS), qui s'appellera autrement que X11.

Parce que un standard existe déjà, il ne faut pas chercher à le remplacer, alors qu'il est considéré comme mal foutu pour l'utilisation actuelle ?

pas grand chose, sauf peut-être pour des petites configs
Petites config ?
Tu peux me dire où j'ai dit ca ? Peut êtrre que tu fais réference au terme de "semi-embarqué" ? Si c'est ca faut que tu révise ta définition d'embarqué, parce qu'une freebox HD c'est de l'embarqué pur et dur, ca l'empeche pas de lire les mains dans les poches un flux H264 qui dépasse la norme la plus dure.

Il n'en reste pas moins que je penses pas que DirectFB ait un avenir glorieux, mais c'est pas une raison pour les descendre sur des raisons complétement fausses et infondées.

* c'était quoi le driver frame-buffer dans les années 80 (début de X), quelles étaient les architectures et l'utilisation qui en était faite, quel coût?

Heureusement qu'on se base pas sur l'age d'une solution pour juger de son utilité, sinon on serait encore sur MS-DOS à coder en basic ... (ou autre pour les plus vieux)

* ton driver DirectFB, il gère toutes les capacités de ta carte graphique (3D & Co compris)?
Il sait le faire, faut "juste" coder les drivers avec.

* tu fais comment niveau développement pour faire une appli qui puisse *aussi* s'afficher sur un poste distant, éventuellement d'un autre OS, de façon transparente (si si, c'est utilisé)?
Il le gère déjà, l'option s'appelle voodoo de mémoire. (Et porte mal son nom ;)

* est ce-qu'il n'y aurais pas dans X11 des choses qui le rendent plus costaud/sympa que le frame buffer - surtout dans les technos récentes de direct rendering, de librairies asynchrones, etc...
Je veux pas dire, mais ces technos ca compte, amha, pas, c'est des technos très récentes qui ont été surajoutées, donc quitte à prendre du temps pour refaire quelque chose, autant le refaire proprement.

* combien de temps ça prendrais de recoder les nombreuses applications qui fonctionnent via X11, avec combien de nouveaux bugs?
Pour la plupart des applis, ils utilisent des toolkits graphiques qui sont indépendants de la couche supérieur, et qui peuvent tourner derrière sur DirectFB sans trop de probleme si ledit toolkit est porté dessus, en l'occurence Gtk est déjà porté, mais certaines applis Gtk sont bizarres et ont quand même un bout de X11 dans leur code j'ai pas trop compris pourquoi. De même SDL a été porté dessus, donc y a pas mal de choses qui peuvent tourner dessus.

Bon après, ca n'empèche que X11R7 est franchement pas mal. Ce que font les mecs de DirectFB est bien, mais rien n'empeche de faire exactement la même chose sur un X11 normal. Je pense que DirectFB a sa place dans le semi-embarqué (type HTPC), plutot que dans le desktop, mais bon il fait partie de la diversité qui fait la force du libre (amha.)

Petite précision : Le composite ne fonctionne plus, adieu Compiz et Echelle son seul et unique plugin utile :-(
Oui c'est la conséquence logiquqe d'utiliser plusieurs "X screen", les drivers nvidia(cartes carrement?) n'aiment pas du tout ca, et doivent presque tout désactiver pour le supporter.
Bon sinon j'ai cherché, et je confirme ce que je dis il suffit d'être en twinview + xinerama pour faire ce que tu veux, MAIS, car il y a un gros mais, il faut que ton window manager gere le xinerama, en pratique je sais pas trop ou ca en est .

Effectivement cette CSS a rien à voir avec celles de d'habitude, celle là est utilisable, je la trouve pas trop moche (dans le style WMaker quoi), et particulièrement agréable aux yeux (même si y a des choix de couleur bizarre, les liens vert sur boite verte, même si c'est pas le même vert c'est moyen.)
En vrai je crois que je risque de la garder. (Bon euh dommage que la fenêtre de post de commentaires soit blanches elle...)

2. J'aurais préféré me passer d'une gui (nvidia-settings) pour configurer l'interface graphique qui la supporte... ça ne me parait pas logique. Mais je vais essayer.

Oui bon dit comme ca ca peut paraitre idiot, mais c'est juste un outil d'appoint à l'autodétection du driver qui se débrouille bien tout seul, et bon c'était juste un conseil, pas sur que ca change grand chose non plus de tout supprimer.

3. Xinerama : il me semble qu'en l'utilisant et lorsqu'on maximise les fenêtres, celles-ci se mettent sur les deux écrans. Et ça j'en veux pas. Mais je peux me tromper ou m'être induit en erreur à cause d'une mauvaise conf.
Oui et non. Xinerama c'est deux choses, c'est quelque chose au niveau de driver et autre chose au niveau des applis. Si seule la partie au niveau des drivers est appliqué et que les applis ont pas de communication pour le connaitre, alors effectivement ca se mettera sur deux écrans. Mais de toutes facons le TwinView nVidia fait déjà ce travail, donc (dés)activer le Xinerama sur un Xorg avec driver nvidia tout ce que ca change c'est la signalisation aux applis. Par contre si tu dis ca, ca doit être que t'as déjà essayé, donc doit y avoir un truc tres bizaarre dans ta configuration qui m'échappe ...

4. Option "TwinViewXineramaInfoOrder" "DFP-1" ==> Permet d'avoir l'écran "DFP-1" (l'écran externe dans mon cas) en primaire afin que par exemple l'invite de connexion s'affiche sur celui-ci, que les panneaux (xfce) se place dessus etc..
Bon j'ai pas la doc nvidia sous le coude, mais je penses que ca serait plus logique de mettre DFP-1, DFP-0.

5. Petite précision : Je viens de m'apercevoir que je peux paramétrer les jeux à la résolution des deux écrans 3600x1080 ((1920+1680)x1080) et que je ne peux plus sortir de ce mode. J'ai le jeux en plein écran sur deux écran et ça c'est mal (c'est mal au yeux surtout)

Je penses (mais j'affirme pas), qu'en dynamictwinview (config par défaut quand c'est pas hardcodé dans la config il me semble), que t'aura la liste des modes possibles (apres ca depend de ce qu'utilise ton jeu pour connaitre les résolutions)

Bon déjà 2 choses d'aspect général:
1.Pour une carte aussi récente vaut mieux prendre un driver récent type 180.29
2.Je te conseillerais bien de virer toute ta config, vu que rien ne sert là dedans, et laisser faire l'autodétection+nvidia-settings/

Sauf que pour ton problème tu fais presque tout ce qu'il faut pour être sur que ca marche pas.
Je connais pas les détails au niveau de l'implémentation nvidia qui est un peu tordue mais voilà: pour "déclarer" le multiécran aux applications, la seule norme c'est le xinerama, sauf que 1.Tu le désactive dans les server flags, donc déjà c'est mal barré, et 2.Pourquoi tu mets dans le TwinViewXineramaInfoOrder, que le DFP-1 et pas le DFP-0 ? Là encore je connais pas très bien les options nvidia, mais il me semble que ca veut dire que même s'il déclarait le xinerama (ce qui ne semble déjà pas être le cas...), il ne déclarerait qu'un écran, donc bon les applis vont être un peu à la ramasse après c'est normal.

Un flux h264 Main@2.1 avec une résolution merdique à la youtube, tu peux meme les voir sur les petits téléphones qu'on pas flash. C'est y pas beau, sans te prendre la tete avec la compatibilité entre les différentes applications.
Je te parles là encore de la réalité, d'aujourd'hui du concrêt

Euh .. Tu m'expliques ? Il te dit que même un pauvre téléphone "bas" de gamme (faut pas pousser trop loin non plus) lit du h264, ce qui est bassement concretement je trouve, et tu lui réponds par un "faut faire les API", et tu dis que t'es plus concret ?
Faut m'expliquer là.
Ah et sinon, bon il parle que de vlc, mais en fait y a surtout quicktime comme lecteur h264, et flash (bon lui il va être compliqué à intégré au schmiliblickli il faudra rajouté 10 lignes de JS en plus), et tu dis que c'est purement théorique la capacité supérieure de pénétration du h264 sur le flv ?

Certaines personnes téléchargent depuis Deezer juste en sauvant une session TCP en .mp3 depuis Wireshark (oulà Albanel va faire interdire ça :)
Et bah ces personnes là se cassent la tête pour rien vache ...
Suffit d'avoir deezer lancé et de faire un petit tour dans /tmp pour s'en rendre compte :)

Le cryptage non plus avec ça, il y a toujours d'autres moyen pour qui veut vraiment.
Certes, comme pour tout DRM (euh et oui c'est bien de DRM qu'il s'agit)

seulement la croyance des ayant-droits qu'il permettent d'éviter le téléchargement (ce qui est faux)

En vrai il en est effectivement capable, mais à ma connaissance pas beaucoup d'outils ne l'utilisent, et si le soft est mal codé (90% des cas que j'ai rencontré), il apparait gentillement en clair dans /tmp.

C'est déjà bien, mais comment on fait sous AROS, AmigaOS, BeOS, Haiku, QNX... ?

De la même manière que sous Linux: plugin mozilla/mplayer (ou si tu prefere vlc le plugin qui va avec.).

reconnu, mais la calibration via les outils KDE ne fonctionne pas

Hein y a des outils de calibration d'écran sur KDE ? Euh... quelle version et où ?!?
Bon sinon, la méthode normale pour calibrer, c'est wacomcpl 'fin si la tablette est du Wacom, mais bon c'est le cas en général.

Euh ... Pourquoi dire GNU/GNOME/Linux ? T'aime bien les pléonasmes ?

alors si en plus il n'est pas abonné chez un FAI grand public

Pas besoin de ne pas être chez un FAI grand public pour ne pas utiliser de *box....

Ca prend du CPU au niveau de l'encodage, sauf si l'option entrelacement est passée au codec, dans ce cas c'est à la lecture. (Mais en général c'est à l'encodage). Mais bon après ca dépend des filtres utilisés la consommation CPU, comme je l'ai dit, un desentrelaceur cubique ffmpeg consomme beaucoup (au moins divisé par 10 si ce n'est 100) moins que du yadif, mais avec une qualité un peu moindre (quand même relativement bonne).
Bon par contre comme t'as de bons résultats faudra que je revois theora...

Arriver à lancer un serveur sur le port 80 en étant juste www-data c'est fortiche.

C'est peut être idiot comme remarque mais un petit deinterlacing améliore notablement le résultat.

Euh oui effectivement, il faut surtout pas oublier ce "détail", par contre un deinterlacing potable est en général pas vraiment petit, ca bouffe pas mal de CPU. Bon après les désentrelacement basiques, tels que ceux de ffmpeg marchent quand même pas mal, même si yadif+kerndeint montrent de meilleurs résultats.

Ou alors Fichier -> convertir sur les versions "récentes" de VLC.
Mais après y a toujours aucune option derrière facilement accessible. En tout cas personnellement je conseillerais plutot du X264 plutot que du theora, mais bon ca pompe pas mal de CPU (sur un quad core avec x264 en 8 threads, je peine à atteindre une vitesse temps réel en SD). Le theora est un codec plutôt mauvais de ce que j'ai pu tester. (du niveau du MPEG2 made in ffmpeg je dirais à vue de nez, en nettement plus lent).
En ce qui concerne le multipass, même si le gain est réel, il n'est pas non plus mirobolant, si le résultat semble ne pas correspondre aux attentes de loin, il faut déjà régler correctement les autres réglages, et seulement après activer le multipass.

La plupart du temps il est même pas placé en RAM, il est lu tel quel sur le disque d'origine. Apres la plupart des distribs ont une option pour passer en RAM pour avoir un système plus réactif, mais je n'ai jamais vu ce comportement par défaut sauf chez damn small linux ('fin c'est ce qu'ils disent j'ai pas vérifié)