Au menu des nouveautés :
- des puces qui devaient encore utiliser XFree 3.3.6 ont vu leur driver porté ;
- nouvelles cartes supportées : Radeon 7500 (avec la 3D), 8500 et Rage128ProII, Permedia 4, G550, GeForce 3, i830 ;
- de nombreux bugfixes ;
- l'émulation de roulette de souris (comment ça marche ?) ;
- suppression des extensions PEX et XIE ;
- support de *BSD sur UltraSparc, de linux sur m68k, arm, et mips ;
- bien d'autres, lisez le fichier Release Notes.
Note du modérateur : merci aussi à Mathias M. et Daneel qui ont posté la news.
Aller plus loin
- Le FTP (13 clics)
- Releases Notes (4 clics)
# YEEEEEEEAH !!! :)
Posté par Graveen . Évalué à 10.
Bref j'applaudis en core un fois les developpeurs et tous ceux qui gravitent autour de XFree pour leur travail.
...Je suis de plus en plus persuadé que les drivers Radéon 8500 sont moins bugués que ceux de Windows !
[^] # Re: YEEEEEEEAH !!! :)
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Le ChangeLog indique :
"Disable the DRI and print a warning message for Radeon 8500 cards until they are supported (Kevin Martin)."
[^] # Re: YEEEEEEEAH !!! :)
Posté par niclone (site web personnel) . Évalué à 10.
Pas d'acceleration pour la 3D, mais presente pour la 2D. (du moins, c'est ce que j'ai compris)
[^] # Re: YEEEEEEEAH !!! :)
Posté par VACHOR (site web personnel) . Évalué à -2.
De toute façon je fais pas de jeux en 3D sous Linux.
[^] # Acceleration 3D
Posté par FRLinux (site web personnel) . Évalué à 6.
[^] # Re: Acceleration 3D
Posté par darkshun . Évalué à 6.
[^] # si si ...
Posté par FRLinux (site web personnel) . Évalué à 5.
[^] # Re: si si ...
Posté par poseidonk . Évalué à -1.
[^] # Re: si si ... Non non
Posté par darkshun . Évalué à 1.
La 3D marche pour les cartes Radeon, mais pas la 8500. C'est indiqué explicitement sur la page status du projet Gatos: http://gatos.sourceforge.net/supported_cards.php(...)
Ton portable a surement une carte Radeon, mais certainement pas une 8500: Cette carte n'existe pas en version «mobility» : http://www.ati.com/na/pages/technology/hardware/hardware.html#2(...)
Tu dois avoir une 7500.
[^] # Re: YEEEEEEEAH !!! :)
Posté par Thomas RIBO . Évalué à 2.
Disons qu'ils plantent moins... mais il utilisent moins de fonctionnalités de la carte que les drivers Windows.
De toutes façons, ATI fait de bonnes cartes mais pas de bons drivers pour les exploiter...
# bon travail
Posté par - neuro (site web personnel) . Évalué à 10.
Autant je deteste les interfaces graphiques que je trouve une perte de temps et de memoire, autant j'ai ete agreablement surprisde la facilite avec laquelle ca s'installe et ca se configure si besoin est (je parle de la slack 8.0, qui n'a pas l'installation et la configuration de X par defaut).
Linux devient de plus en plus user friendly, et c'est une tres bonne chose pour la popularisation des OS libres.
# 3dfx (experience perso)
Posté par Benjamin . Évalué à 10.
Voilà c'est tout.. c'est juste un commentaire...
# Miroirs
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
[^] # Re: Miroirs
Posté par Dilb . Évalué à 1.
Le but d'une news est avant tout d'informer, non ? Pas de mettre à genou un site...
[^] # Re: Miroirs
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
[^] # Re: Miroirs
Posté par Dilb . Évalué à -10.
[^] # Re: Miroirs
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
# accélaration hardware de la décompression vidéo ?
Posté par Schwarzy . Évalué à 10.
"An i810 XvMC (motion compensation) driver is now available (Linux only)."
Si je lis bien, maintenant Xfree86 va pouvoir offrir une interface commune pour la décompression harware de la vidéo en plus du changement de colorspace harware [je parle de Xv] ?
Mais c'est une bonne nouvelle ça !!!!!
OOOOUUUUUUUAAAAAAAIIIIIII !!!!!!!!
Quelqu'un sait ou on peut trouver plus dinfos ?
[^] # explication ...
Posté par EvilTheCat . Évalué à 8.
[^] # Re: explication ...
Posté par Schwarzy . Évalué à 10.
Les formats MPEG essaient de trouver les déplacements de portions d'images (le "motion") en plus du classique "différence de pixels". Le "motion compensation" c'est la première partie du codage, litéralement c'est la compensation de mouvement.
Dans la réalité marketing, le "motion compensation" n'est souvent que la partie décodage DCT hardware pas le "motion compensation" complet dont je parlais.
Pour info le décodage DCT [Discret Cosinus Transformation] est la transformation depuis un espace fréquentielle des couleurs vers l'espace des pixels (celui affiché par le moniteur). C'est la transformation inverse (avec pertes), la DCT, qui permet d'avoir un flux vidéo aussi compressé.
J'espère avoir été compris. Si c'es pas le cas, dites-le !
[^] # Re: explication ...
Posté par corn . Évalué à 6.
L'inverse de la DCT, ce ne serait pas plutôt l'iDCT ?
[^] # Re: explication ...
Posté par niclone (site web personnel) . Évalué à 10.
Un compresseur utilise en fait meme les deux, mais c'est une autre histoire....
Et bien sur, l'IDCT est la partie la plus groumande en CPU dans le MPEG. C'est pourquoi la prise en charge par la carte graphique change beaucoup de choses. Le 'Motion Compensation' est une étape qui viens juste après l'IDCT, je crois que l'interet principal qu'il soit pris en charge par la carte graphique, c'est d'eviter des allez-retour entre le CPU et la carte graphique:
Dans le cas ou on utilise que l'iDCT, on envois une table a la carte graphique, la carte applique l'iDCT, puis on récupère la table transformé, le CPU fait le 'Motion Compensation' et renvois l'image (en Xv) a la carte.
Dans le cas ou le 'Motion Compensation' est pris en compte par la carte: On envois une table a la carte graphique, la carte graphique applique l'iDCT, puis le 'Motion Compensation' et affiche l'image. Bref, moins d'allez retour gourmand.
[^] # Re: explication ...
Posté par icyfemur . Évalué à 10.
La DCT est une opération conservatrice. Vient ensuite l'étape de quantification qui elle est une opération avec pertes. C'est cette nouvelle matrice quantifiée qui peut etre compressée avec des algorithmes plus ou moins classiques car cette matrice contient bcp de 0.
J'espere ne pas m'etre trompé...
PS : J'ai essayé de trouver quelques explications sur la compression JPEG DCT :
http://www.multimania.com/compressions/jpeg.html(...(...))
http://www.cs.sfu.ca/CourseCentral/365/li/material/notes/Chap4/Chap(...))
mais y a surement des liens bcp plus complets et interessants...
[^] # Re: explication ...
Posté par Schwarzy . Évalué à 10.
En fait sous le nom "DCT" j'ai ramené:
- la transformation pixels->"fréquences" (la iDCT)
- la table de quantification dont tu as parlé qui élimine les informations les moins utiles pour l'oeil. C'est à ce niveau que ce fait la qualité de l'image quand elle sera décompressée.
- réorganisation des données en zig-zag pour préparer l'étape suivante.
- une compression de huffman (optimisation de l'utilisation des bits dans le fichier)
La dernière étape est la compression physique des données. La table de quantification permet de mettre des zeros dans les valeurs fréquentielles pour diminuer la taille du fichier en les supprimant.
Les valeurs fréquentielles incluent souvent les mêmes valeurs. Une compression de huffman se régale de ce type de données et elle est peu gourmande en ressource mémoire et CPU ce qui est intéressant pour de petits systèmes (avec l'aide d'une iDCT hardware toutefois pour les plus petits systèmes comme dans les appareils photos numériques).
Finalement, c'est bien toutes ces précisions comme ça le lecteur comprend ces histoires de compression de façon incrémentale aux travers des commentaires.
# (Hors Sujet) Une Annee qui promet...
Posté par Samuel Pajilewski . Évalué à 0.
2001 a été epouvantable, et pour cause : Le passage du noyau 2.2 -> 2.4 a fait beaucoup de mal, le noyau 2.4 etant (a mon avis) mis sur le marché trop prematurement.
Cette année, les Hacker vont peaufiner le noyau 2.4, les gourous travaillant dans la branche 2.5
Xfree 4.2.0 : Je vais le telecharger pour voir ce qu'il donne, mais le 4.1 etait deja plus que correct.
Maintenant reste aux distribs de faire le reste.
L'annee derniere, quoiqu'on en dise, les distributions etaient loin d'etre parfaitement aboutie, que ce soit SuSE, Redhat ou Mandrake et les autres.
Maintenant, si ils prennent leur temps, ils vont se baser sur un noyau 2.4 nettoyé de ses principaux bugs, sur un Xfree 4.2 qui compte pas mal d'amelioration, sur un KDE beaucoup moins gourmand en ressource et un Gnome plus stable, sur de bons Navigateurs qui n'ont rien a envier a IE (Netscape 6.2.1, Mozilla 0.9.7, Opera 6 TP3, Galeon).
En plus , avec un peu de chance, ils pourront aussi packager Star Office 6 qui est prometteur.
La detection de materiel sera encore plus simplifiée (avec je l'espere une reconnaissance automatique des Webcams, Appareils Photos Numerique, Scanner USB...)
Bref, La prochaine Debian (pour moi) , la SuSE 7.4, Mandrake 8.2, Redhat 7.3 riquent fort bien de plaire aux fans respectifs de ces distribs, et plaire aussi aux autres !
Bref, bonne année en perspective...
(PS : J'aime Bien Windows aussi, surtout 2000, par contre j'ai été tres deçu par Win XP : ils en font un peu de trop je pense...)
-1 car hors sujet !
[^] # Re: (Hors Sujet) Une Annee qui promet...
Posté par dcantin . Évalué à -10.
;)
[^] # Re: (Hors Sujet) Une Annee qui promet...
Posté par - neuro (site web personnel) . Évalué à -7.
[^] # Re: (Hors Sujet) Une Annee qui promet...
Posté par laurent wandrebeck (site web personnel) . Évalué à -2.
voir http://www.slackware.com/changelog/current.php?cpu=i386(...(...))
# A quand une interface grafique aussi rapide en 2D/3D sous linux que sous windows
Posté par Jésus Christ . Évalué à -6.
Pourtant Nvdia fournie des drivers à moitié (...3/4) closed... merde le monde s'écroule, je croyais que les trucs proprios c'était plus mieux que les trucs libres...(nan j'déconnn), alors c'est koi l'expliquation ? XFree est plus lent que l'interface grafique de Kro ?ou alors NV met moins de coeur à développer des drivers pour linux, donc ca se ressent sur la qualitée?
Qu'est que je serais heureux si tout mes jeux marchaient sous linux, plus besoin de cet OS de merde qui plante toutes les 3 heures pcq des fuittes de mémoires empêchent les processus important de se run sans prob... Pourtant je le run pas souvent, mais qu'est ce qu'il me fait chier...
Quelle chiotte...
Si les producteurs de jeux et de hardware, ne font pas attention à moi, je ne ferais pas attention à eux.
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par reno . Évalué à 10.
http://www.theregister.co.uk/content/4/23735.html(...(...))
Les tests de ce type testent surtout la qualité du driver pas de l'OS..
Comme c'est NVidia qui réalise le driver sous les deux OS, ce n'est pas étonnant que les performances soient proches..
Mais ce qui serait vraiment intéréssant serait de comparer la qualité d'un driver libre sous Linux par rapport au driver propriétaire sous Windows.
Cela permettrait de mesurer les progres du driver libre..
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par Pierre Tramo (site web personnel) . Évalué à -4.
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par VACHOR (site web personnel) . Évalué à 10.
Si les logiciels libre prennent une brouette comme XP comme point de comparaison, on va sans arrêt avoir besoin de machines de plus en plus musclées, un peu comme avec le duo M$ - Intel.
Non, il ne faut pas prendre XP comme référence !
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par Pierre Tramo (site web personnel) . Évalué à 0.
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Donc X plus lent que sous win, ce n'est pas toujours le cas.
L'article : http://www.theregister.co.uk/content/4/23735.html(...(...))
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par Beretta_Vexee . Évalué à 10.
L'architecture server de X est certainnement interessante dans bien des cas, mais surment pas pour le desktop, X reste assez lent par rapport a la concurence.
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
L'article de the register montre bien que X peut lui etre superieur.
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par niclone (site web personnel) . Évalué à 10.
Il est possible que le driver de ta carte n'implemente pas toute les accelerations. Parceque globalement, ce genre de trucs est bien supporté par X. Il se peut aussi que ce soit Gimp qui rame dans le réaffichage de l'image, et la, photoshop est très optimisé, mais c'est independant de X.
[^] # j'ai testé
Posté par Anonyme . Évalué à 10.
J'ai fait le teste suivant, avec gimp j'ai créé un image d'environ 20 Mo. Dessus, j'ai fait le script-fu -> rendu -> line nova
Et après, je bouge la fenetre de l'image très rapidement dans tout les sens : le contenu est toujours visible !
Aussi, le processus qui prend le CPU est X, lorsque je bouge cette fenetre, et non pas Gimp.
En conclusion, j'en déduis qu'une fois de plus, on fantasme sur les bienfaits d'un photoshop en offrant à Gimp des défauts que personne n'observe.
[^] # Re: j'ai testé
Posté par Jean-Philippe Martin . Évalué à 6.
Personnellement et avec ma voodoo3, c'est plus agréable de déplacer une fenêtre sous win2k que sous linux XFree 4.1.0.
Sous kde et lorsque je bouge une fenêtre très rapidement, j'ai plus d'accrochage dans le déplacement que sous windows. Sous win2k, ça passe tout seul mais pas sous linux ....
S'il y en a un qui puisse me dire pourquoi ?
Par contre en mode 3D, pas trop de dif sous q3 !
JP
[^] # Re: j'ai testé
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
C'est ca qui fait ramer à mon avis...
[^] # Re: j'ai testé
Posté par Thierry GRAUSS . Évalué à 4.
sur un portable (duron950 avec 384M de RAM
et une S3 savage 1024x768 32bits).
Sous xp, il y avait un driver de base et le
déplacement des fenètres est une horreur
(hyper saccadé même si je configure pour ne
pas afficher le contenu de la fenètre pendant le
déplacement et désactivé tout les trucs graphiques
inutils) alors que sous X avec le driver pour la savage, KDE 2.2.2 et tous les goodies inutils activés et l'affichage est super rapide, les déplacements sans problème (le contenu de la fenètre est affiché pendant les déplacements). Bon, il faut savoir que mes parents ont aussi un pc de bureau (233MHz et 256MB de RAM) avec un win95 et linux. Et avec XP sur le portable, on a l'impression de travailler avec le 233 et win95, alors qu'avec linux sur le portable, la différence
de vitesse est impressionnante.
[^] # Re: j'ai testé
Posté par Anonyme . Évalué à -3.
- "c'est plus agréable de déplacer une fenêtre sous win2k que sous linux XFree 4.1.0"
- "Sous kde et lorsque je bouge une fenêtre très rapidement, j'ai plus d'accrochage dans le déplacement que sous windows"
- "sous X avec le driver pour la savage, KDE 2.2.2 et tous les goodies inutils activés et l'affichage est super rapide, les déplacements sans problème"
Je ne vois pas quel propos est sensé infirmer l'hypothèse que ça soit KDE qui fasse ramer ta machine.
[^] # Re: j'ai testé
Posté par Thierry GRAUSS . Évalué à 3.
machine au contraire, d'ailleur X non plus.
C'est juste pour dire qu'un driver de base
(non optimisé pour la carte donc) est plus
lent qu'un bon driver (que ce soit pour X ou
pour xp).
J'ai d'ailleur précisé que xp n'avait pas le
driver optimisé pour la savage.
Au fait tu as pris des propos qui ne sont
pas de moi (mélange de personne)
[^] # Re: j'ai testé
Posté par Thierry GRAUSS . Évalué à -3.
comparé à d'autre wm (comme windowmaker
ou autre), mais je voulais surtout dire que le
driver joue beaucoup (même si le window
manager joue aussi)
[^] # Vitesse et WM
Posté par Cru Kilu . Évalué à 10.
en effet, c'est le WM qui intercepte TOUS les évènements à destination des "top level windows" (sauf celles qui ont le flag override_redirect) et ensuite décident des évènements qu'elles leur transmettent.
Un WM peut aussi transformer un évenement en une cascade d'évènements synthétiques, selon son "look and feel".
Par exemple, KDE fait un "opaque resize" des fenêtres, et rajoute un évènement Expose après chaque resize (dans un ev ConfigureNotify), ce qui ralenti considérablement l'affichage.
Au niveau du toolkit il y a aussi des différence dans la gestion des suites d'Expose. Pour éviter de bloquer le cpu après un paquet d'Expose, les toolkits essaient de détecter ce cas de figure et de ne faire que le dernier. C'est pas évident car générallement les Expose sont entremélés sur les différents subwindows et les primitives X*Event pour examiner la queue ne sont pas designées pour ça. Par exemple, glut le fait très mal alors que gdk (la couche graphique de gtk) le fait très bien.
Tout ceci dépend beaucoup aussi du contenu des autres fenêtres survolées, du toolkit qui les animent, etc.
Enfin bref la comparaison entre Linux et win est loin d'être simple et parlante, elle dépend d'énormément de paramètres qui n'ont rien à voir avec le driver ni la carte.
[^] # Re: j'ai testé
Posté par Étienne . Évalué à 9.
S'il y en a un qui puisse me dire pourquoi ?
Peut-être que sous Linux, on a compris que l'intérêt d'avoir un affichage sans accrochage lorsqu'on balade sa fenêtre comme un histérique à travers l'écran avait un intérêt somme toute assez limité et que certaines améliorations sont plus prioritaires.
[^] # Re: j'ai testé
Posté par niclone (site web personnel) . Évalué à 7.
D'autre part, le fait que ca rame peut aussi venir de l'image de fond d'écran, et j'avais deja remarqué que KDE etait plutot lent dans ce domaine.
Maintenant, le but n'est pas de troller sur qui est le plus fort entre microsoft et X11, mais simplement de comprendre pourquoi dans certaines situations, X11 peut etre plus lent que microsoft. Ma réponse dans cette situation, c'est que ce n'est probablement pas X11 le responsable, mais plutot le contenu de ce qu'il y a à l'ecran, et donc, leurs applications respective, y compris le fond d'écran.
[^] # je ne comprends pas
Posté par - - . Évalué à 10.
bref, X ne m avait jamais "ramé", (windonws non plus)
et l affichage de gimp est l affaire de X
c est X qui prend la charge cpu pour dessiner a l'écran, gimp ne fait que composer son image et dire a X ce qu il faut faire
(d ailleurs c est aussi un fonctionnement similaire dans windows avec photoshop )
j ai beau comparer les 2 systemes (win 2K + photoshop), X se defend trés bien, voir meme TRES trés bien
franchement les comparaisons windows vs X n ont plus lieu d etre, si c pour se battre pour qq pixels de plus par secondes...
en plus selon le driver Xfree sera plus rapide et des fois ca sera windows.. la belle affaire.
et pourquoi pas de comparer Quartz (macosX) avec Xfree ? hmmm ? :)
il y a une chose sur laquelle X est indeniablement supérieur : c est ses fonctions Reseaux
et elles sont _indispensables_ , meme pour une utilisation desktop (parce qu on peut avoir 2 ordis et c'est trés pratique)
et cela n'empeche pas X d'etre trés rapide.
je note qu'il n y a plus le vieux troll comme quoi X bouffe la ram, surement parcequ on a assez repeté que X ajoutait la ram video son total et le cache des images des softs X et que donc le total montré par TOP etait fallacieux.
je note que Xfree 4.2 concerne surtout macosX (ajout officiel du mode rootless ) et X est pas aussi rapide que sur pc
(X en mode "sans quartz" passe par les drivers apple , il devrait donc etre aussi rapide que l environnement natif de apple, manque encore d'optimisations)
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par GrosBenny . Évalué à 10.
D'ailleurs le commentaire cite doit surement venir de rasterman car il est dit que enlightement e17 va super vite en resize (et c'est pas un flame)
Autrement, moi a ta place, je prendrais un truc bien leger comme icewm ou autre, c'est bien agreable.
[^] # Toolkit client/serveur
Posté par Johann Deneux . Évalué à 10.
Dans l'état actuel des choses, voila ce qui se passe quand on deplace une barre de défilement d'une liste pop-up:
1. Le serveur X detecte un evenement souris et l'envoie au client.
2. Le client X interprète l'événement et demande au serveur X d'effacer de redessiner le contenu de la liste (ce qui demande de nombreuses commandes: il faut effacer redessiner les traits, le texte)
Avec un qt (ou gtk) possédant une couche réseau, tout se passe uniquement sur le "serveur qt (ou gtk)". Les seuls communications qui subisteraient seraient des appels de callbacks définis par l'utilisateur à éxécuter du côté client qt:
1. Le serveur Qt détecte un événement souris. Il regarde le callback associé à cette événement. Le callback est en fait un morce de code de Qt lui-même et peut être éxécuté localement.
2. Le serveur Qt éxécute le callback, qui consiste à redéssiner la liste.
[^] # Re: Toolkit client/serveur -> ça existe: c'est BERLIN.
Posté par Schwarzy . Évalué à 9.
le toolkit se situe du coté du serveur.
http://www.berlin-consortium.org/(...(...))
c'est un projet qui prend son temps [un peu trop à mon gout mais bon ...] mais qui, j'espère, un jour prendra le relais de XFree86.
[^] # L'attente va être longue...
Posté par Julien Olivier . Évalué à 3.
Tout ça pour dire que tant que directfb, ggi ou sdl n'auront pas de support équivalent à XFree au niveau des drivers 2D et 3D, Berlin sera inutilisable pour le commun des mortels. D'autant plus qu'à leur actuelle, seul DirectFB a un semblant d'implémentation 3D software.
Mais bon, un toolkit unifié, se serait le pied, surtout qu'ils prévoient de supporter QT et GTK de manière transparente.
[^] # Re: Toolkit client/serveur
Posté par Marc . Évalué à 3.
A ce propos, est-il possible de faire tourner une application native mac OS X à distance sur une machine linux ? qqun a déjà essayer ?
[^] # X est fondamental
Posté par - - . Évalué à 10.
pourquoi vouloir à tout pris révolutionner la chose ? surtout avec des modèles moins puissants...
X s'occupe de tout ce qui est affichage hardware et de communication avec l'os. et l application est elle independante (en théorie si le programmeur est propre) du syteme d'exploitation/architecture en desssous, de plus l'application ne fait pas de difference entre local ou reseau ou quoique ce soit.
il est faut de croire qu'un tel modèle est condamné a pondre une interface pourrie ou des performances misérables
le fautif de mauvaises performances c'est le GESTIONNAIRE VIDEO
bien des gestionnaires vidéo de XFree ne savent pas exploiter completement le bus pci/agp et les spécificités de la carte vidéo
(tenez quelqu un parlait de la voodoo, voila un bon exemple)
mais prenez le driver radeon ou mieux (si on veut, il est proprietaire...) de nvidia, les performances sont nettement meilleures parce que les programmeurs ont su ou pu avoir accés à toutes les possibilités de ces cartes la. (particulièrement la 2D en fait)
berlin ou n importe quel truc futuriste ne peut rien y changer, on est limité par le fait de vouloir des gestionnaire opensource (et pas de confusion ,je suis _pour_ des gestionnaire opensource et cela vaut l'effort , tant pis pour les constructeurs qui gardent secretement leurs infos)
et le troll recurrent des interfaces graphiques "pourries" à cause de X , ce n'est pas la faute à X, c'est le probleme des environnements comme GNOME , KDE ou GNUSTEP
meme sous windows, GDI ne force pas une interface particulière, ni QUARTZ ne force à faire des boutons BLEU fluos.
si vous pensez que gnome ou kde ne sont pas conviviaux, ne tirez pas sur X, X est une arme pour faire l'interface que vous souhaitez, debarquez plutot dans les projets gnome/kde/gnustep et aidez.
Cela me fait penser au vieux "gag" des copier/coller delirant sous X, ben vi X permet une grande souplesse d utilisation du clipboard, mais bien des applications motifs/xlib/gtk/qt etC. ont fait n'importe quoi avec ,d'ou que maintenant QT3 force un comportement unique et que gnome décrit dans ses papiers comment _bien_ agir avec le presse papier X , on peut esperer que si tous le monde est bien discipliné, quand gnome2 et kde3 seront répandu, un Editer/Couper dans un "abiword2" marchera avec un "Editer/coller" dans un kword3. (faudra aussi ne pas mélanger avec la selection/bouton du milieu de X , erreur courante des developpeurs)
tout cela n'est pas la faute a l architecture de X
,c'est du à des années de NON standardisation d'interface graphiques, exactement ce que cherchent à corriger Gnome ,kde et aussi GNUstep.
oui ,vi, y a TROIS efforts concurrents en même temps, (bien que gnustep soit plus "académique" qu autre chose) , bon on dira que c'est la beauté de l'open source, le choix... néanmoins un minimum de regles fera pas de mal plutot que le chaos que sont les softs xlib/motif/gtk/qt/autres qui font tout et n'importe comment sans se soucier des autres.
ceci n'est pas la faute de X
ensuite X11 est un standard, courant sur tous les unix et couvre de nombreuses applications, cela a pris du temps, beaucoup de temps, c'est un acquis à ne pas gaspiller.(20 hackers suffiront pas pour faire de berlin l'équivalent de X11 sur unix )
de même ne parlez pas d'un QT ou GTK "serveur", le but de ces toolkits est de faire abstraction du systeme graphique en dessous
par exemple QT fonctionne sur windows (et bientot macos X) permettant a une application QT de s'affranchir de savoir si c est GDI ,QUARTZ ou X11 en dessous. TRES important.
pou répondre à l autre question;
macosX (par défaut et toutes les applications voulant profiter de l'environnement cocoa/carbon avec le look "aqua") utilise un systeme graphique nommé QUARTZ
son protocole est radicalement différent de X11
un serveur X est donc pas capable de comprendre ce que veulent les applications QUARTZ
de meme il n'existe pas (pour le moment) de méthode pour "déporter" l'affichage d'un logiciel macosX vers une autre machine.
QUARTZ lui même n'as pas de fonctions réseaux.
etant hérité du Display postscript serveur(DPS) de NeXTstep, on présume que Apple finira par remettre les fonctions réseaux que DPS supportait.
conséquence, non on ne peut pas afficher un soft "macosX" sur un poste linux (ou unix en general, ni meme un autre mac sous macosX)
par contre ,si on installe XFree (ou autre serveur X) sur MacOsX alors on peut faire tout ce que permet X. par contre il faudra utiliser des softs X11 (gimp, quanta, xterm, etc. ) , et non des softs "quartz" (comme omniweb, finder ou office, etc. ) et la adieu la zolie interface Aqua, le PDF et autres alphachannelseries de Quartz.
ouf.
[^] # Re: X est fondamental
Posté par Johann Deneux . Évalué à 2.
par exemple QT fonctionne sur windows (et bientot macos X) permettant a une application QT de s'affranchir de savoir si c est GDI ,QUARTZ ou X11 en dessous. TRES important.
Et alors ??? Je vois pas en quoi l'introduction d'une couche réseau dans un toolkit changerait quoi que ce soit au niveau d'abstraction. Le programmeur n'aurait même pas à s'en préoccuper. Le changement tel que je le vois marcherait avec la totalité des applications existantes sans qu'il soit nécessaire de changer quoi que ce soit.
PS: Quand tu réponds à plusieurs posts, réponds à chaque post individuellement. Une énorme réponse à plusieurs posts est illisible et contient de nombreux morceaux hors-sujet (puisque le sujet est situé ailleurs). Enfin, tu fais comme tu veux, c'est juste une suggestion, hein.
[^] # Re: Toolkit client/serveur
Posté par Johann Deneux . Évalué à 2.
Si une machine ne dispose pas de la version Qt distribuée, rien n'empêche de retomber sur X11.
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par Jean-Philippe Martin . Évalué à -7.
A+
JP
NB : j'aimerai une autre réponse que :
lorsqu'il sera prêt !
Au fait, Rasterman a retrouvé du boulot ?
Vu son talent, je pense que oui mais je n'ai pas vu sur son site !
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par RB . Évalué à 4.
Voilà pourquoi ça va moins vite qu'avant...
[^] # Re: A quand une interface grafique aussi rapide en 2D/3D sous linux que sous win
Posté par kael . Évalué à 0.
sinon pour la 3d ca peut se valoir avec windows vu que le dri comme le nom l'indique donne un acces directe au materiel...
# Quelle carte video pour GNU/Linux ?
Posté par ggl . Évalué à 7.
-du point de vue performance
-mais surtout du point du support (disponibilite des specs, qualites des drivers, politiques de support, etc...)
Autant, du point de vue performances, les nvidia sortent du lot (meme concernant le prix d'achat),
autant sur le support il est difficle de trouver des avis argumenter, et de la documentation. Meme si ca parait hors sujet, ca serait pas mal d'avancer ensemble sur la question.
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Jean . Évalué à 3.
Pour ça, j'utilise les drivers Nvidia. Le problème est que pour la diffusion des specs, ils sont bon derniers. Donc ils font des drivers proprio qui fonctionnent super, mais ils sont pas trop dans l'esprit...
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Johann Deneux . Évalué à 6.
Conclusion: les drivers nVidia pour Linux sont bien si on ne sort pas des sentiers battus.
(*) En utilisant des lunettes à obturateurs, comme les Revelator3D d'ELSA.
[^] # NVidia, c'est bon et pas cher...
Posté par Ano . Évalué à 7.
Quant à l'accélération 2D/3D, Je travaille en 1600x1200 très confortablement et TuxRacer est un plaisir...
Seul problême, et de taille, c'est pas Open-source, et faut se coltiner l'installation des drivers de NVIDIA, bien plus rapides que ceux livrés avec XFree, à la main. Et on reste à la merci d'un changement de politique de NVidia...
[^] # Re: NVidia, c'est bon et pas cher...
Posté par Ludovic Boisseau . Évalué à 1.
Mais la doc ( http://205.158.109.140/XFree86_40/1.0-2313/NVLinuxNotes2313.pdf(...(...)) ), elle, est impécable : on y présente toutes les options de façon détaillée... Un vrai plaisir.
Moralité : je me lève et je confirme : NVidia c'est bon. Par contre, pour le "pas cher", ça dépend si on prend de l'AGP ou du PCI :o(
PS : la doc, version texte : http://205.158.109.140/XFree86_40/1.0-2313/README.txt(...(...))
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Ludovic Boisseau . Évalué à 0.
Merci
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Jean . Évalué à 1.
J'ai utilisé les version « sources x, c'est à dire les paquets .tar.gz. J'ai jamais testé les .rpm (because debian), mais deux #make et c'est installé.
voilà voilà :)
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Jean-Yves B. . Évalué à 10.
L'accélération 2D y est supportée. Xv pas encore mais l'équipe de gatos (http://gatos.sf.net/(...(...))) fait du très bon boulot. Le DRI devra attendre aussi. Elle ne permet pas grand chose pour l'instant mais est très tentante si on est prêt à parier sur la disponibilité prochaîne du support complet.
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Benjamin . Évalué à 1.
- elles sont un peu anciennes, donc vraiment pas chères
- Elles supportent l'accelération hard, XVideo, OpenGL, etc
- 3dfx étaient dans les premiers à liberer leurs specs (glide, était opensource)
- Les performances sont tout à fait acceptables pour une utilisation multimédia quotidienne (sauf pour les quelques jeux commerciaux tres récents)
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par ggl . Évalué à 0.
ps: Il me semble que la voodoo 3 a quelques pb, ainsi que la voodoo 5. Si quelqu'un pouvais confirmer.
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Benjamin . Évalué à 0.
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Jak . Évalué à 1.
Un truc que je comprends pas, dans XFree 4.x, c'est savoir comment s'activent Xv, DRI, DGA (?), enfin, tous ces trucs, c'est-à-dire est-ce que ça se fait tout seul, les binaires sont compilés comme il faut. Parce que j'avais compilé il y a quelque temps un XFree 4.0.99, et superquadrics tournait à environ 22 images par secondes, alors que le XFree 4.1 de la Slackware 8 ne le fait tourner qu'à 15 i/s, le DRI étant activé (section DRI 0666, je crois), avec support DRI tdfx dans le noyau activé à première vue.
Donc je me demande si il y a un truc spécial à faire quand on compile, j'ai un peu regardé les sources du 4.2, mais je vois pas grand'chose.
En fait, j'ai un peu de mal à voir quoi fait quoi dans toutes les extensions (et déjà, qu'est-ce qu'il y a comme extensions? Est-ce que les trucs que je cite en sont toutes?), je ne sais pas où chercher les infos, ce qu'il me faudrait, c'est un schéma récapitulatif pour résumer tout ça :)
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Benjamin . Évalué à 2.
Pour le nom des extensions, le premier tableau de cette page résume bien
http://gatos.sourceforge.net/dri-debug.php(...(...))
(pas spécifique à ATI forcément)
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Jak . Évalué à 2.
D'ailleurs, c'est assez facile, mais je ne sais pas si on peut mettre des options de compilation pour améliorer les performances.
Pour compiler X, il faut récupérer les sources (par exemple sur le ftp de free, ou celui de ovh.net /mirror/ftp.xfree.org/XFree420/sources , je suis plus sûr du chemin), il y a 3 tgz à récupérer, tu les décompactes dans le même répertoire, et tu fais make World, puis make install, puis make install.man.
Sur mon Duron 800, 256 Mo de RAM, ça met environ 1 heure à compiler.
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par Bertrand Mathieu . Évalué à 2.
Donc si tu veux jouer, Xfree 3 et mesa-glide, mais oublie le DRI.
Mais si tu veux les extensions XVideo par ex, ben là pas trop le choix -> XFree 4.
Et apparemment libglide2 n'est pas prête à voir le jour en DRI.3dfx a vraiment coulé là :-(
(j'ai une voodoo3 et Xfree4)
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par ggl . Évalué à 5.
Concernant les Radeon 8500, j'espere qu'Ati ouvrira prochainement les specs. En 2d les performances doivent etre interressantes.
ps: Pour les Voodoo 3, il me semble avoir vu quelques problemes dans la doc de MPlayer, et d'autre applications video, mais je peux me tromper.
[^] # Re: Quelle carte video pour GNU/Linux ?
Posté par tanguy_k (site web personnel) . Évalué à 4.
Moi j'ai une voodoo4 et pour Quake 3 ca tourne nikel, y'a pas de limitation comme avec les anciennes cartes.
Quand j'ai acheté (en juin 2001 je crois) ma voodoo4, 3dfx était déjà en faillite et je l'ai payé 500 F en pci, la version AGP coutait 300 F !!!!
Il y avait aussi des voodoo5 AGP pour 650 F, mais le deuxième proco de cette carte n'est pas supporté par XFree (ca a peut etre changer depuis)
Maintenant je fais du bi-écran avec ma voodoo4 pci et ma TNT2 agp.
Mais attention, en Xinerama il n'y a pas d'accélération DRI et d'après le message au démarrage il semble que ce soit du à DRI / Xinerama et pas à ma voodoo.
Ca fonctionne nikel avec toutes les extensions de XFree pour faire tourner mplayer et pouravoir des fontes anti-aliasées dans KDE.
Quand j'avais que la TNT2, j'avais qd meme quelques petites merdes, genre tu switchs entre XFree et la console en framebuffer -> paf vaudré. m'enfin ca a surement évoluer depuis.
Donc trouver une voodoo4 d'occas à 300 F pour un joueur occasionnel c'est une bonne idée. ca marche bien même sous win2k :)
J'ai un ami qui a la même (mais en AGP) sur un Athlon 1.3 et sous win2k ca avance pas mal (tout les jeux en 1024 minimum), moi sur mon P2 400 c'est du 800x600 en 16bits pour un q3a assez fluide (40 fps).
[^] # NVidia grand gagnant !
Posté par Samuel Pajilewski . Évalué à -10.
Pourquoi : car NVidia supporte reellement Linux, pas comme ATI ou Matrox qui compte sur la communauté Open Source pour developper des Drivers. (En gros : Voici les specs, demerdez vous !)
Pour preuve, quand tu vas au Supermarché Acheter une Carte Video, sur TOUTE les cartes a Chipset Nvidia (a la notable exception de Guillemot), c'est marqué noir sur blanc : Compatible Linux et Drivers Linux.
Dans les boites Matrox ou ATI, c'est Windows et Mac Only !
Voila, et c'est pour cela qu'il faut soutenir massivement Nvidia...
[^] # Re: NVidia grand gagnant !
Posté par Julien Portalier . Évalué à 2.
Mais bon, de l'autre coté, y'a ati, etc. qui filent leurs specs, mais qu se foutent royallement de faire des drivers, c'est dégueux aussi comme attitude, ils pourraient avoir une petite équipe de développeur qui bose à plein temps sur les drivers. Mais ça ferait comme nvidia, ils seraient close-source.
[^] # Re: NVidia grand gagnant !
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
While ATI does not develop Linux or XFree86 drivers for its graphics cards in house, we actively support 3rd party developers that provide driver support for the majority of ATI products with development kits and information.
Donc si tu veux ecrire un driver ils t'aideront, je pense que c'est deja une bonne chose.
Ensuite, tu as "Precision Insight" qui avait été payée par ATI, Intel, Matrox et 3dfx pour faire des drivers Linux compatibles DRI (Je crois que c'était devenu VA Linux ensuite).
Donc ils investissent dans le dev de drivers linux et si tu veux participer ils te donnent les infos dont tu as besoin. Je trouve ca cool et c'est une des raisons qui m'ont fait acheter mon Radeon...
[^] # Re: NVidia grand gagnant !
Posté par kalahann . Évalué à 2.
[^] # Re: NVidia grand gagnant !
Posté par Croweye . Évalué à 1.
je supose que les développeurs de xfree leur ont gentiment demandé les specs de leurs chips (ce que ATI a probablement fait avec plus ou moins de bonté) car ils ne voulait pas avoir des drivers comme nvidia qui font à leur tête en ne repectant pas l architecture directrice de xfree et DRI, en offrant des drivers sont la sources n'est que pour la partie indispensable popur le kernel, le reste étant en binaire, ce qui occaisione quelques difficultés parfois et etc
[^] # NVidia grand gagnant !
Posté par kalahann . Évalué à 10.
Matrox écrit ses propres drivers et les distribue en sources et en binaires. Ainsi que l'utilitaire de configuration Powerdesk
Tiens: http://matrox.com/mga/support/drivers/files/linux_09.cfm(...(...))
Je cite: le readme de powerdesk: Matrox PowerDesk for Linux is released under the GNU General Public License (GPL).
Les drivers doivent pas être GPL (ou pas complètement) mais on a les sources...
Message à tous: soutenons nvidia parce qu'ils mettent des autocollants linux sur leurs boites en carton! Remercions-les de mettre leurs drivers en closed-source, car c'est mieux pour nous! A mort les constructeurs qui développent leurs drivers en GPL!
# et op ...
Posté par EvilTheCat . Évalué à -2.
[^] # et merde et pardon ...
Posté par EvilTheCat . Évalué à 4.
ftp://people.redhat.com/mharris/testing/(...(...))
Faut me pardoner, j'viens de me lever ... et ... c'est dure le matin.
[^] # et merde et pardon ...
Posté par kalahann . Évalué à -1.
ouais, c'est dur le "matin" :)
[^] # Re: et merde et pardon ...
Posté par Marc (site web personnel) . Évalué à -2.
# Licence
Posté par Pierre . Évalué à -10.
Ya bien Berlin, mais il est encore loin d'etre utilisable...
A quand une reelle alternative GNU ?
[^] # Re: Licence
Posté par Yusei (Mastodon) . Évalué à 10.
[^] # Re: Licence
Posté par Pierre . Évalué à -7.
Le probleme : http://www.gnu.org/philosophy/x.html(...(...))
[^] # Re: Licence
Posté par Yusei (Mastodon) . Évalué à 2.
«The XFree86 group does an important job for the community in maintaining these programs, and the benefit of copylefting our changes would be less than the harm done by a fork in development. So it is better to work with the XFree86 group and not copyleft our changes on these programs.»
(L'équipe de XFree86 fait un travail important pour la communauté en maintenant ces programmes, et le bénéfice de mettre un copyleft sur nos changements serait moindre que la perte causée par un fork du développement. Il est donc préférable de travailler avec l'équipe de XFree86 et ne pas mettre de copyleft sur nos changements à ces programmes)
Donc même si on peut regretter cette licence il n'est pas dans l'intérêt du système GNU de faire un fork.
# Bien, bien
Posté par AnAxAgore . Évalué à 2.
;)
# Howto de migration
Posté par Jean-Pierre Heraton . Évalué à 2.
j'ai bien envie de mis mettre ce coup ci à XFree4
[^] # Re: Howto de migration
Posté par Philippe Martin . Évalué à 3.
1) Enlever XFree 3.3.x (par rpm -e XFree, ... ou équivalent),
2) Installer XFree 4.2.0, et pour cela, voir http://www.xfree.org/4.2.0/Install.html(...(...))
Si un grand écran noir avec des caractères seulement ne te fait pas peur, ça devrait bien se passer.
Par contre, n'oublies pas que tu devras recompiler tous les progs X pour qu'ils tournent correctement sous ta nouvelle version de X (KDE, Gnome, ...).
[^] # Re: Howto de migration
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Faux et archi-faux. Le passage de X11R6.5 à X11R6.6 n'a eu quasiment aucune incidence sur les applications.
[^] # Re: Howto de migration
Posté par Olivier Jeannet . Évalué à 1.
Pas obligé.
J'ai déjà testé XFree 4 sans enlever XFree 3 (je ne savais pas si ça marcherait) en renommant les répertoires XF3 (.../X11 et .../X11R6, plus certains fichiers de configs) en ".old" et en installant XF4 à partir des binaires. Ca a bien marché. J'ai pu ensuite remettre XF3 en renommant, tout en gardant XF4 dans un coin.
tu devras recompiler tous les progs X
Absolument pas ! Où as-tu été pêcher cette info ?
[^] # Re: Howto de migration
Posté par Philippe Martin . Évalué à 1.
Absolument pas ! Où as-tu été pêcher cette info ?
OK, m'a trompé. Faites comme si j'avais rien dit.
[^] # Re: Howto de migration
Posté par Jean-Pierre Heraton . Évalué à 1.
# Ouf... j'ai eu chaud
Posté par Rénald Casagraude . Évalué à 1.
Aïe ! Qu'est ce que j'apprend cette nuit : elle ne sera supporter qu'à partir de XFree86 4.2.0 .... Les larme me montent aux yeux... Je passe une bonne partie de la nuit en essayant de trouver une autre solution que celle d'utiliser la branche CVS de XFree86...
Ce matin en me réveillant, forcément j'ai envie de tuer tout le monde !
Mais... C'était sans comtper sur mon linuxfr chérie....
Bon maintenant y'a plus qu'à attendre les .deb's
[^] # Re: Ouf... j'ai eu chaud
Posté par Rénald Casagraude . Évalué à 1.
Aargh !!
[^] # Re: Ouf... j'ai eu chaud
Posté par niclone (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.