Bonjour,

J'ai apparemment un problème avec l'OpenGL sur mon système (voir ref. carte graphique dans signature). J'utilise le pilote libre radeon et l'exécution de cairo-dock me renvoie des messages d'erreur (voir: http://forums.fedora-fr.org/viewtopic.php?pid=395804#p395804 et message suivant). Cairo-dock fonctionne uniquement sous gnome en mode "sans OpenGL".
Voici mon xorg.conf:
# Xorg configuration created by system-config-display

Section "ServerLayout"
    Identifier     "single head configuration"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"

# keyboard added by rhpxl
    Identifier  "Keyboard0"
    Driver      "kbd"
    Option        "XkbModel" "pc105"
    Option        "XkbLayout" "be"
EndSection

Section "Monitor"
    Identifier   "Monitor0"
    ModelName    "LCD Panel 1440x900"
    HorizSync    31.5 - 56.0
    VertRefresh  56.0 - 65.0
    Option        "dpms"
EndSection

Section "Device"
    Identifier  "Videocard0"
    Driver      "radeon"
    BoardName   "ATI Technologies Inc M56P (Radeon Mobility X1600)"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Videocard0"
    Monitor    "Monitor0"
    DefaultDepth     24
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection

Section "Extensions"
        Option "Composite" "Enable"
EndSection
Et la sortie de la commande glxinfo:
$ glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, 
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_EXT_texture_from_pixmap
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV530 71C5) 20090101  TCL DRI2
OpenGL version string: 1.5 Mesa 7.7-devel
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
    GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, 
    GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_provoking_vertex, 
    GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, 
    GL_ARB_texture_compression, GL_ARB_texture_cube_map, 
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, 
    GL_ARB_vertex_array_bgra, GL_ARB_vertex_buffer_object, 
    GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, 
    GL_EXT_blend_color, GL_EXT_blend_equation_separate, 
    GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, 
    GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_convolution, 
    GL_EXT_copy_texture, GL_EXT_draw_range_elements, 
    GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord, 
    GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, 
    GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, 
    GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_provoking_vertex, 
    GL_EXT_rescale_normal, GL_EXT_secondary_color, 
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, 
    GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, 
    GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, 
    GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 
    GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, 
    GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, 
    GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_APPLE_packed_pixels, 
    GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, 
    GL_ATI_texture_mirror_once, GL_ATI_separate_stencil, 
    GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, 
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, 
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, 
    GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, 
    GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, 
    GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays
Le lancement de compiz-manager me donne:
# compiz-manager
Checking for Xgl: not present. 
xset q doesn't reveal the location of the log file. Using fallback /var/log/Xorg.0.log 
Detected PCI ID for VGA: 01:00.0 0300: 1002:71c5 (prog-if 00 [VGA controller])
Checking for texture_from_pixmap: present. 
Checking for non power of two support: present. 
Checking for Composite extension: present. 
Comparing resolution (1440x900) to maximum 3D texture size (4096): Passed.
Checking for nVidia: not present. 
Checking for FBConfig: present. 
Checking for Xgl: not present. 
/usr/bin/compiz (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
et produit un crash des effets de bureau...
Sous KDE Cairo-dock fonctionne, avec la dernière mise à jours c'est ok.

Par contre avec compiz c'est un peut galère vu qu'actuellement mesa n'apporte que la version 1.5 d'openGL, une prochaine mise à jours devrait apporter au moins opengl 2.0, voir plus...

Sous KDE pour avoir l'effet de transparence il faut activer les effets de bureau de KDE.

Avec la dernière mise à jour pas trop de problèmes, si ce n'est que KDE 4.4 béta 2 plantouille un peut...

Je referais le test avec compiz... Encore une fois il faut le lancer avec fusion-icon... et faire attention à certaines options...
Effectivement, Cairo-dock fonctionne sous KDE à condition de supprimer la config créée sous Gnome...
Bonne année et bonne santé à toutes et à tous!

Aux bonnes nouvelles cette année pour les Atistes (oui je sais, cela fait un peut "secte", mais on est pas chauvin! on pense aussi aux autres!) en pilote libre ("en culotte courte") :
- Arrivés rapide de la prise en charge d'opengl en version 2.0, normalement rapidement suivi par openGL 3.0, voir plus. (que ce soit pour ATI, Intel et sans doute Nvidia avec le pilote nouveau)
- Arrivés rapide de la gestion d'énergie pour les R6xx et +
- Support rapide des R8xx (Evergreen ou HD5xxx)
- Support des shaders programmable
- Sans doute des optimisations pour la performance
Pour les mauvaises nouvelles :
- Toujours pas de pilote propriétaire fonctionnel actuellement
- Sinon...
Ne manque plus que le support de l'openCL qui est prévu, ainsi que l'openVG et OpenGL ES. Mais cela avance vite...
D'un coté vus que les pilotes libre vont devenir pleinement fonctionnel ; le pilote proprio il peut disparaitre.
En fait ce n'est pas prévu comme cela, il faut toujours un support propriétaire dans certains cas, surtout dans le monde professionnel.

Par contre c'est vrai que l'on pourra ne plus se prendre la tête lors des bon en avant du serveur graphique ou du noyau par exemple... Comme c'est le cas actuellement...

Quand je regarde les rapports de développement de mesa, xorg-x11-drv-ati, noyau et de gallium3D (et tout ce qui vas avec...), on se prend un mal de tête souvent... et je ne parle pas du serveur graphique pour pas donner des indigestions...
VINDICATORs wrote:En fait ce n'est pas prévu comme cela, il faut toujours un support propriétaire dans certains cas, surtout dans le monde professionnel.
Ati peut très bien faire un support sur les pilotes libre ?
Ils donnent déjà les docs techniques et pas mal de codes, ce qui est déjà énorme, sans compter que ce n'est pas uniquement pour des générations de gpu qui ne sont plus fabriqué, mais aussi pour la dernière.

Après c'est une histoire de sérieux envers les professionnels au niveau du support et de montrer qu'ils sont toujours présent.

Le pilote proprio fonctionnant avec les distributions "professionnel" style Redhat/centOS, SUSE, etc...

Comme je l'ai déjà dit, fedora, ubuntu, et autres, allant de l'avant plus ou moins ont des besoins qu'ils ne peuvent fournir car cela bouge très très très (j'arrête parce qu'on a pas fini sinon...).... rapidement! Il suffit de lire rien que les notes de version des dernières versions du serveur graphique xorg pour avoir gros mal de crâne... et ce n'est pas fini parce qu'en plus fedora à très souvent une version d'avance sur la version officiel... Et je préfère passer sur les notes de versions du noyau Linux pour pas donner des envies de suicides... et ce n'est toujours pas fini...

Pourquoi c'est plus suivi sous MS windows ou sur les consoles? Parce que les noyaux changent rarement, l'interface graphique aussi, etc...

Et je passe sur l'histoire du nombres de personnes dédié à développer les pilotes sous MS windows, ainsi que pour les api MS windows, qui sont beaucoup plus nombreuses que pour GNU/Linux... A ce niveau seul la communauté est en mesure de tenir le rythme.
6 jours plus tard
Vu que les modérateurs n'ont pas l'air de vouloir épingler ce sujet, je le fais remonter un peut...

Mesa 7.7 ne devrait plus tarder à arriver dans update/updates-testing, il est dispo sur koji. Une mise à jour du pilote "radeon" et de la "libdrm" sont eux aussi disponible chez koji.

Après test :
Blender ne plante plus vraiment, mais bloque sur certains menu et la sélection d'un objet ne se fait pas. Reste à voir si c'est dût au pilote graphique ou autre... Il reste le problème avec les textures, mais cela s'améliore petit à petit (sauf ce problème gênant avec la sélection d'objet avec le clique droit...)

Yo frankie fonctionne, mais il reste toujours le problème avec les textures qui ne sont pas toutes là.
World of padman c'est remis à fonctionner, mais ayant quelques blocages lors du choix du serveur, je ne peux confirmer le bon fonctionnement, mais au moins il se lance ce qui n'était pas le cas avant.
ExtremTuxRacer est un peut plus véloce, ainsi que super tuxkart.
Tremfusion (reprise de Tremulous dont une nouvelle version stable devrait sortir d'ici peut si ce n'est pas déjà le cas) fonctionne toujours aussi bien, avec un peut moins de baisse de performance lorsqu'il y a beaucoup de mouvement, d'objets, etc..., mais ce n'est pas encore parfait même si cela reste très jouable en jouant sur les options.

KDE est encore plus fluide, tant en version 4.4 bêta 2, sur la machine de ma signature, qu'en 4.3.xx sur une autre machine équivalente.

OpenGL reste toujours en version 1.5, normalement la version de Mesa 7.8 devrait apporter la version 2 d'openGL, mais vu que je n'arrive pas à compiler le Mesa du futur Fedora 13 pour F12, cela reste en suspend...

La mise en veille mémoire fonctionne bien, le réveille graphique semble plus rapide avec ces dernières évolutions et ne plante plus.

Je précise aussi que ces avancées du pilote radeon sont aussi dût aux codes rapporté du noyau linux 2.6.32 et 2.6.33 sur le noyau 2.6.31 de fedora 12, donc ces explications ne sont là uniquement sur Fedora 12! Je dit cela pour ceux des autres distributions qui doivent être confirmer au cas par cas, selon comment est construit leurs versions du noyau!
Pour information le noyau 2.6.32 pour Fedora 12 est disponible sur Koji, mais sans plus d'information je déconseille la mise à niveau si l'on n'y connait rien!
Pour le pilote propriétaire, toujours pas de nouvelles pour F12 actuellement. Par contre ATI devrait l'améliorer en ce qui concerne la gestion 2D (enfin...), refonte du panneau de contrôle et sans doute enfin l'arrivé d'opengl 3 et plus... Du moins c'est dans les prévisions... Ce qui m'étonne un peut c'est que c'est aussi une partie de la ligne de conduite des pilotes et librairies libres... Je rappel qu'en 2D les pilotes libre mettent une claque au pilote propriétaire... peut être un échange de code???
VINDICATORs wrote:Ce qui m'étonne un peut c'est que c'est aussi une partie de la ligne de conduite des pilotes et librairies libres... Je rappel qu'en 2D les pilotes libre mettent une claque au pilote propriétaire... peut être un échange de code???
Si une partie du code sur la 3d passe dans le pilote libre ça serait bien :-D

Sinon question plus généraliste, les instructions 2D sont encore utilisé avec compiz ?
Bonne question... normalement oui.

Pour le code 3d il faudrait confirmer avec ce que fourni ATI, mais il y en a déjà des bouts dans les docs... Donc c'est déjà le cas...
Je constat une bug chez moi, au bout de 3 heures j'ai des gros bugs graphiques qui apparaissent. Comme des strilles qui apparaisent aléatoirement sur les plasmoids ainsi que sur les fenêtres puis très vite sur l'écran entier. C'est pas un gros problème en soit, je n'est juste qu'a redémarrer X. Je voulais juste savoir si l'était un cas isolé ou si d'autre personne rencontre ce genre de problème en attendant des MAJ (mesa-7.6-0.18.fc12, xorg-x11-server-1.7.3-5.fc12,xorg-x11-drv-ati-6.13.0-0.15.20091127gita8dbf7c23.fc12)
Ta mis à jours comme décrit dans la doc? sinon peut être une surchauffe de ton gpu, quoi que les 4770 ne doivent pas chauffer beaucoup (perso avec ma 4850 je monte pas à plus de 46°C en pleine charge... voir 51°C en pleine canicule cette été)... Parce que je n'ai vu aucun problème de ce genre depuis,

Je vais mettre à jours la doc, car mesa 7.7 est disponible en version finale sur koji...
je suis parfaitement à jours, je pense pas d'une surchauffe puisque après avoir redémarrer X ça repart pour 3 heures. Sinon comment je peu connaitre le T° avec les pilote libre ?
Oui mais sur koji il y en a eu encore...

Pour la t°C... J'ai une sonde qui est prise en charge par sensor qui à l'air d'être la sonde du gpu, mais je n'en suis pas sûr à 100%. L'affichage externe avec une sonde placé sur le venti/rad du gpu donne à quelques °C près la même température. Mon doigt me confirme que c'est pas chaud du tout, il faut toujours faire confiance à son doigt!
j'ai essayé d'installer le module avec l'installeur ati , mais le module refuse de se charger. ni avec le precedent kernel 2.6.31.6-166 , ni avec celui d'aujourdhuis , a savoir le 2.6.31.9-744 . (je crois me souvenir , tellement de chose a memoriser ... ) un symbole non résolu , le module se décharge.

j'ai bien essaye le module xorg "ati", plantage.=> hard reboot. Ensuite , le modules vesa , pareil. meme pas eu le courage d'essayé le "vga" ... ya rien qui marche quoi .
L'installeur ati ? Tu veux dire le .run dispo sur le site AMD/ATI ?
Toujours lire la documentation avant de tenter quoique ce soit !

Il y est clairement écrit que le .run du site AMD/ATI n'est pas du tout compatible avec Fedora.
Et que nous n'en assurons aucun support par le même coup.

Désinstalle le et retente le module ati du xorg.
Le pilote n'est pas actuellement compatible avec F12, ce n'est pas que le .run n'est pas du tout compatible avec fedora, mais que c'est très souvent le jour et la nuit. Nous n'assurons pas le support de la version .run, mais de sa version préparé par RPMFUSION quand elle est là.

Actuellement on préfèrera le pilote libre "radeon" en installant en plus "mesa-drivers-experimental" pour les gpu R6xx->R7xx (en attente pour les R8xx) ou HD2xxx->HD4xxx si vous préférez. Voir la doc sur les pilotes libre ATI.
Bonjour, j'avais une petite question car je me suis fais plaisir avant noël et voici une partie de ma nouvelle configuration :
CG : ATI RADEON HD 5870
LCD : LG Flatron W2363V-WF

Mon problème est le suivant :
Mon écran qui normalement a une résolution native Full HD (1920x1080) et qui est relié en HDMI à ma carte graphique n'affiche qu'un bureau de 1280x1024.

J'ai essayé plusieurs choses :
- Créer un fichier xorg.conf,
- le modifier,
- Installer les pilotes propriétaires ATI
- Utiliser xrandr pour essayer d'avoir au moins 1920x1080 en résolution, peu importe si j'ai pas encore l'accélération graphique.

Cependant il y a une question qui me travaille :
[anthony@pluton ~]$ xrandr 
Screen 0: minimum 640 x 480, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 0mm x 0mm
   1280x1024       0.0* 
   1280x960        0.0  
   1152x864        0.0  
   1024x768        0.0  
   800x600         0.0  
   640x480         0.0
Le rafraichissement est à 0 car il ne reconnait pas l'écran ou parce qu'il ne reconnait pas la carte graphique?

Normalement d'après les specs de l'écran (fichier pdf sur le CD)
Fréquence horiz.
Analogique, Numérique: 30 - 83 kHz (Automatique)
HDMI: 30 - 83 kHz (Automatique)

Fréquence vertic.
Analogique, Numérique: 56 - 75 Hz (Automatique)
HDMI: 56 - 61 Hz (Automatique)

Forme
Synchro. Séparée, positif/négatif
Numérique (HDCP)

Resolution Maxi : VESA 1920 x 1080 @ 60 Hz
Recommandée : 1920 x 1080 @ 60 Hz
Que dois-je faire?
Ta suivi un peut la doc sur les problèmes et solution pour ajouter une résolution à xrandr?

Tu peux aussi faire la mise à jour (que j'ai du retirer de la doc avant que de me prendre une attaque éclair au Q...) à tes risques et périls (bon là c'est vraiment surfait...) avec la version du pilote "xorg-x11-drv-ati", de "xorg-x11-server", "mesa" et "libdrm" se trouvant sur ce site :-> http://koji.fedoraproject.org/koji/index en prenant les paquets en .fc12.

Pour installer il suffit simplement de télécharger les paquets dont on à besoin et de faire un "yum localinstall nomdu/despaquet(s) --nogpgcheck". Cela résout pas mal de problème mais n'est pas apprécié pour la doc, bien que cela résout plus de problème qu'il n'en crée...