# [nvidia] le nouveaux choix du libre

## guilc

Héhé oui, je pompe le titre du sujet ATI  :Razz: 

Une pensée pour ce post : http://chithanh.blogspot.com/2010/04/nouveau-on-gentoo.html

Petite mise à jour du post, les choses ont un chouilla évolué  :Wink: 

Tout ce qui faut pour passer à nouveau est maintenant dans portage, en ~arch, pas besoin d'overlay :

noyau 2.6.37 ou supérieur avec le support nouveau DRM activé (dans la section "staging" des drivers [1]). Le 2.6.37 minimum est important car : apporte le support de la gestion d'énergie, et corrige un bug gênant dans le code du DRM qui provoque des corruptions de pixmaps ;

x11-drivers/xf86-video-nouveau ;

mesa  avec les USE gallium et llvm.

il est inutile d'utiliser x11-base/nouveau-drm avec les noyaux récents >= 2.6.34

C'est en l'état actuel très utilisable : 2D parfaite, 3D largement suffisante pour faire bouger un bureau avec compositing sans souci et lenteurs (chez moi kde-4)

Bon, ça doit être très insuffisant pour les jeux, mais pour tous les non gamers comme moi, c'est super. Les effets 3D sont au poil.

De l'importance des USE de mesa : 

- sans "gallium" => nouveau est un driver récent. Il est donc développé au dessus de la nouvelle infrastructure pour le code 3D, donc gallium, et pas mesa classic. Toutes les évolutions se passent dans gallium donc.

Et voila un système qui tourne sans driver proprio, fini les conflits d'ABI de driver sur les MAJ de xorg  :Wink: 

[1] Les options du 2.6.34+ à activer qui ne sont pas utiles pour le driver proprio mais nécessaires pour nouveau et KMS :

```
CONFIG_AGP=y

CONFIG_AGP_INTEL=y (ou le chipset qui va bien à la carte mère)

CONFIG_DRM=y

CONFIG_DRM_KMS_HELPER=y

CONFIG_DRM_TTM=y

CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y

CONFIG_STAGING=y (pour activer les drivers expérimentaux dans la section correspondante)

CONFIG_DRM_NOUVEAU=y

CONFIG_FB_BACKLIGHT=y (le drm ne compile pas sans)
```

Penser à RETIRER :

```
CONFIG_FB_BOOT_VESA_SUPPORT

CONFIG_FB_VESA
```

Ainsi que tout autre driver de frame buffer

Un détail, chez moi, c'est une Quadro NVS290 (chipset NV86), ainsi qu'une 8400GS (NV86 aussi)

N'hésitez pas à rapporter vos expériences sur le sujet !

----------

## Tom_

J'utilise Nouveau depuis quelques mois, et je suis du même avis que toi : ca marche vraiment très bien! Je suis super content d'avoir lâché le pilote proprio. 

Quand j'ai commencé à utiliser Nouveau, ce n'était pas aussi simple qu'aujourd'hui, pourtant j'ai accroché directement!  :Smile: 

J'utilise quasiment que la 2d, et c'est franchement niquel! J'utilise le compositing proposé par Kwin (via Xrender) : c'est du rendu 2D et c'est très rapide!

Pour le 3d, j'ai testé ca il y a quelques temps et je n'avais pas été convaincu. Il faudrait que je reteste.  :Wink: 

Pour info, je possède une Nivida 6800, une "vieillerie" donc.  :Very Happy: 

----------

## guilc

 *Tom_ wrote:*   

> J'utilise le compositing proposé par Kwin (via Xrender) : c'est du rendu 2D et c'est très rapide!

 

Effectivement ça marche pas mal. Mais avec le dernier mesa, le compositing opengl est beaucoup plus fluide et rapide.

Par contre oui, le souci de lag de XV sous certaines conditions n'arrive que en compositing opengl, pas xrender. Mais je ne doute pas que ce genre de petits soucis va être résolu rapidement vu l'avancée (avec mesa-7.8, cela plante simplement dès qu'on fait de la 3D !)

Attention, pour mesa, le USE gallium est masqué par défaut, il faut faire ça :

```
# cat /etc/portage/profile/use.mask 

-gallium
```

----------

## Tom_

Il va falloir que je repasse Mesa en version live alors!!   :Laughing: 

Ce qui serait sympa comme fonction, c'est le décodage matériel des videos mais bon ... il va falloir être patient!   :Sad: 

----------

## xaviermiller

OK chez moi avec l'overlay suntrucmuche, en démasquant le use gallium, la version "testing" de mesa (pas la 9999), le noyau .34.

C'est une GeForce7600. L'affichage est impeccable en 2D, je ne fais pas de 3D.

A plus de blob binaire non-free dans ma gentoo  :Smile: 

----------

## adjaxio

Bonjour,

Une petite question :

Avec plusieurs écrans est ce que ça fonctionne bien ou il vaut mieux continuer à passer pas les drivers propriétaires ?

Merci

----------

## Poussin

Je vais me tater pour tester ça sous peu je crois  :Smile: 

A priori, je suppose que le dual screen passe par xrandr avec ces pilotes et donc aucun problème

----------

## Tom_

J'ai oublié de préciser : j'ai un dual screen et ca marche très bien avec randr.  :Wink:  C'est super facile à mettre en place!

----------

## adjaxio

Merci je ferai le teste alors  :Wink: 

----------

## guilc

 *guilc wrote:*   

> Par contre oui, le souci de lag de XV sous certaines conditions n'arrive que en compositing opengl, pas xrender. Mais je ne doute pas que ce genre de petits soucis va être résolu rapidement vu l'avancée (avec mesa-7.8, cela plante simplement dès qu'on fait de la 3D !)

 

Pour info, ce problème de lag de l'affichage XV avec compositing opengl est complètement résolu.

Je ne sais pas trop si c'est depuis une update de mesa-9999 ou bien depuis la mise à jour du driver 2D (x11-drivers/xf86-video-nouveau) en version 0.0.16_pre20100807, mais en tous cas, c'est maintenant super fluide.

Et la stabilité est plus que jamais au rendez-vous. le driver proprio n'est qu'un mauvais souvenir chez moi  :Smile: 

----------

## k-root

hum .. interessant  :cry:  moi je suis repasse a fglrx ... le driver libre c'etait tres bien , sauf que ca fait pas toutes les fonctions 3D pour causes de "intellectual Property" [1]

si qq'un peux faire un  'glxinfo | grep texture_float' ?

 1 : http://www.opengl.org/registry/specs/ARB/texture_float.txt

----------

## guilc

Y a pas.

Si tu veux faire ton marché, voilà ce que j'ai (sur une NV86, Quadro NVS290) :

```
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_SGIS_multisample, 

    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 

    GLX_INTEL_swap_event

client glx vendor string: Mesa Project and 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_copy_sub_buffer, 

    GLX_MESA_swap_control, 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_INTEL_swap_event

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_control, GLX_OML_swap_method, GLX_OML_sync_control, 

    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, GLX_INTEL_swap_event

OpenGL vendor string: nouveau

OpenGL renderer string: Gallium 0.4 on NV86

OpenGL version string: 2.1 Mesa 7.9-devel

OpenGL shading language version string: 1.20

OpenGL extensions:

    GL_ARB_copy_buffer, GL_ARB_depth_clamp, GL_ARB_depth_texture, 

    GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, 

    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, 

    GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, 

    GL_ARB_framebuffer_object, GL_ARB_map_buffer_range, GL_ARB_multisample, 

    GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 

    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, 

    GL_ARB_shader_objects, GL_ARB_shading_language_100, 

    GL_ARB_shading_language_120, GL_ARB_shadow, 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_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, 

    GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, 

    GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, 

    GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, 

    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_copy_texture, GL_EXT_draw_buffers2, 

    GL_EXT_draw_range_elements, GL_EXT_framebuffer_blit, 

    GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object, 

    GL_EXT_fog_coord, GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays, 

    GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, 

    GL_EXT_pixel_buffer_object, 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_cube_map, 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_APPLE_vertex_array_object, 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_window_pos, 

    GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp, 

    GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, 

    GL_NV_texgen_reflection, GL_NV_texture_env_combine4, 

    GL_NV_texture_rectangle, GL_OES_read_format, GL_SGI_color_matrix, 

    GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, 

    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, 

    GL_OES_EGL_image

```

----------

## d2_racing

Je vais essayer ça prochainement.

Merci pour le petit guide.

----------

## Possum

Histoire de rajouter, chez moi ça marche.

J'ai une 8600 GT noname en 1680x1050, les effets de KDE, nickel.

Côté jeux, j'ai testé NeverWinter Nights et Quake 3 Arena. Pour NWN, lamentable, même en baissant au maximum les effets divers. Pour Quake, en revanche, fullscreen, effets au maximum, 90fps constamment. Donc, jouable !!

J'ai pas essayé des trucs plus gourmands.

Donc, du bon, plus de driver proprio chez moi, vu que le seul jeu auquel je joue, c'est WoW, et que pour ça, je boote sous XP....

Merci bcp  :Smile: 

Ceci dit, vu que j'ai mis l'overlay x11, j'ai eu un comportement bizarre... Je suis en ~amd64. Avec x11-base/xorg-server-1.8.99.906 impossible de démarrer X, comme si il ignorait royalement le driver nouveau. Et pareil en passant tout en version 9999. Une fois cette version masqué, retour à la normale, X démarre correctement.

Enfin, content que ça avance  :Smile: 

----------

## El_Goretto

La prochaine fois que je m'ennuie, je tente  :Smile: 

----------

## guilc

 *Possum wrote:*   

> Ceci dit, vu que j'ai mis l'overlay x11, j'ai eu un comportement bizarre... Je suis en ~amd64. Avec x11-base/xorg-server-1.8.99.906 impossible de démarrer X, comme si il ignorait royalement le driver nouveau. Et pareil en passant tout en version 9999. Une fois cette version masqué, retour à la normale, X démarre correctement.

 

Tiens, j'avais zappé ton message. Mais... Tu as bien sûr pensé à recompiler tous tes drivers après le passage à x11-base/xorg-server-1.8.99.906 ?

Cette nouvelle version introduit une rupture d'ABI, il faut dont recompiler tous les drivers pour que cela fonctionne (recompiler tout ce qui remonte par un qlist -I -C x11-drivers/)

Enfin je dis ça, chez moi ça marche très bien avec cette version RC de xorg après recompilation  :Wink: 

Sinon, je suis quand même un peu étonné du peu de retours (du genre chez moi ça marche, chez moi c'est tout cassé)... J'étais habitué à plus de testeurs/aventuriers sur les forums gentoo. Je n'ose croire qu'il y a si peu de monde tournant avec une nvidia  :Laughing: 

----------

## Possum

 *guilc wrote:*   

> 
> 
> Tiens, j'avais zappé ton message. Mais... Tu as bien sûr pensé à recompiler tous tes drivers après le passage à x11-base/xorg-server-1.8.99.906 ?
> 
> Cette nouvelle version introduit une rupture d'ABI, il faut dont recompiler tous les drivers pour que cela fonctionne (recompiler tout ce qui remonte par un qlist -I -C x11-drivers/)

 

Ouaip. La commande magique étant: emerge -q $(qlist -I -C x11-drivers/)

En fait, ce qui se passait, c'est comme si X ne connaissait plus nouveau. Il essayait de charger les pilotes nv, puis vesa puis fbdev, qui ne sont bien sûr pas installés  :Evil or Very Mad:  Et ce malgré les multiples recompilations, les démasquages sauvages…

 *guilc wrote:*   

> Enfin je dis ça, chez moi ça marche très bien avec cette version RC de xorg après recompilation 
> 
> Sinon, je suis quand même un peu étonné du peu de retours (du genre chez moi ça marche, chez moi c'est tout cassé)... J'étais habitué à plus de testeurs/aventuriers sur les forums gentoo. Je n'ose croire qu'il y a si peu de monde tournant avec une nvidia 

 

Ça viendra, quelques précurseurs qui ouvrent la voie et qui se pètent les dents et le reste va suivre   :Laughing: 

Vu que je suis en train de refaire une install, je vais voir si j'ai le même problème.

Tiens, par contre, bien qu'ayant le bureau composite activé, je n'ai pas la transparence dans Konsole. C'est pareil pour vous ou j'ai merdé ma config moi ?

----------

## k-root

 *guilc wrote:*   

> Y a pas.
> 
> Si tu veux faire ton marché, voilà ce que j'ai (sur une NV86, Quadro NVS290) :
> 
> 

 

 :( 

sinon, est ce que vous pouvez switcher entre les deux implementation sans rebooter ?

----------

## guilc

 *k-root wrote:*   

> sinon, est ce que vous pouvez switcher entre les deux implementation sans rebooter ?

 

Non, les configurations kernel ne sont pas compatibles (KMS & co)

Il y a vaguement quelques bricoles pour trafiquer les consoles en jouant avec les modules, mais c'est pas immédiat du tout, le reboot sera à mon sens plus rapide.

Voir la section "désactivation de KMS" ici par exemple : http://nouveau.freedesktop.org/wiki/KernelModeSetting

Pour un switch facile, demander à nvidia que leur blob binaire supporte KMS   :Laughing: 

----------

## Shayes

Un petit retour de ma part sur nouveau :

KDE 4.5 / X.Org 1.8.2 : L'effet de transparence dans la barre des tâches déconne et plante éventuellement KWin, est-ce parce que je suis sous x.org 1.8.2 ?

Est-ce que ca vaut le coût de faire un test avec une autre version ? je pense pas que ce soit X.Org en faute mais bon...

Le composite opengl marche parfaitement autrement, quelques petits défauts quand on ferme ou l'on ouvre une session mais c'est un ralentissement je pense.

XRANDR : dualscreen quand je bascule une application sur le deuxième écran, arrivé à moins de la moitié la fenêtre devient transparente donc je ne la vois plus sauf si je garde le curseur sur l'application pour faire le déplacement. (sur awesome je ne sais pas si c'est pareil sur kde faut que je test  :Very Happy: )

Voili voilou pour moi

----------

## razer

Je viens de migrer, et tout se passe bien à quelques petits détails près :

Activer composite rend la lecture de vidéos quasi impossibles car il n'y a pas de synchro verticale : à priori xrender est fautif.

Certaines options dans compiz sont ineffectives, comme le shadow des fenêtres

Du coup, je suis revenu à un bureau simple sans eye candys qui finalement ne servent qu'à ralentir l'interface

Côté jeu, bzflag rame bien... Pour ce que je joue de toute façon !

Ce que j'y ai gagné : un joli splash qui exploite enfin la résolution de mon moniteur 16/10, un boot plus rapide avec KMS et sans le gros module binaire nvidia, et surtout une chaine complète desktop open et compilé mano.

----------

## guilc

 *razer wrote:*   

> Activer composite rend la lecture de vidéos quasi impossibles car il n'y a pas de synchro verticale : à priori xrender est fautif.
> 
> Certaines options dans compiz sont ineffectives, comme le shadow des fenêtres

 

Tu utilises bien mesa 9999 le dernier et le driver DDX en ~arch ?

Parce que moi avec ça, les problèmes de lenteur de XV sont complètement réglés, et aucun problème de compositing.

Peut-être est-ce dû à compiz ? j'utilise kwin (en mode vsync)...

----------

## razer

 *guilc wrote:*   

> 
> 
> Tu utilises bien mesa 9999 le dernier et le driver DDX en ~arch ?

 

Oui, tout en arch, x11 overlay, tout démasqué

 *guilc wrote:*   

> Parce que moi avec ça, les problèmes de lenteur de XV sont complètement réglés, et aucun problème de compositing.

 

Je n'ai pas de problèmes de lenteur, mais de tearing (synchronisation verticale)

 *guilc wrote:*   

> 
> 
> Peut-être est-ce dû à compiz ? j'utilise kwin (en mode vsync)...

 

J'utilise principalement le composite via metacity, qui se base sur xrender d'après ce qu'en ai lu. Le problème disparait avec compiz en activant "unredirect fullscreen windows", mais j'ai alors des soucis de focus très chiants. De plus, compiz et ses 10 000 options et bugs me lasse, à force.

Je précise enfin que le problème est aussi présent, à une moindre échelle, avec les drivers proprio nvidia

----------

## jetboo

J'ai fais la migration aussi, ça marche carrément d'enfer. Aucune différence pour moi dans mon utilisation (pas testé les jeux par contre car je ne jou pas) par rapport aux drivers proprios

```
name of display: :0.0

display: :0  screen: 0

direct rendering: Yes

server glx vendor string: SGI

server glx version string: 1.4

client glx vendor string: Mesa Project and SGI

client glx version string: 1.4

GLX version: 1.4

OpenGL vendor string: nouveau

OpenGL renderer string: Gallium 0.4 on NVAC

OpenGL version string: 2.1 Mesa 7.8.2

OpenGL shading language version string: 1.20
```

J'utilise awesome + cairo-doc+ xcompmgr avec les options suivantes : -cCfF -r7 -o.65 -l-10 -t-8 -D7 

Ca permet d'avoir la transparence l'ombrages et d'autre effets kikoo .

"Tout ça" sans aucun ralentissement sur un macbook 5 (geforce 9400M).

Vivement que je puisse aussi me débarrasser des drivers proprio broadcom (BCM4322 pas compatible avec b43  :Sad:  )

----------

## guilc

 *jetboo wrote:*   

> 
> 
> ```
> OpenGL version string: 2.1 Mesa 7.8.2
> ```
> ...

 

Ouah !

Ca tourne avec mesa 7.8 toi ???

Chanceux, obligé d'utiliser la version de dev 7.9 ici. La différence de génération de carte semble changer beaucoup !

----------

## jetboo

Ben en faite ca m'a surpris aussi, je suis resté avec mesa 7.8.2 car hier l'overlay de x11 ne marchait pas (timeout à chaque connection,et meme le site était down)

Je vais reéssayer voir

----------

## xaviermiller

Les overlays Gentoo étaient inacessibles hier soir. C'est rétabli.

----------

## jetboo

Par ailleurs on peut maintenant régler la luminosité directement via X, alors qu'avant les drivers nvidia empêchaient ça et le temps de rétablissement d'un suspend/resume est + rapide.

Par contre il y'a un bug, au retour du suspend (au resume donc ^^) on peut plus régler la luminosité ni sur X, si sur les terminaux tyy [1-12]

edit : en faite si on peut en tapant 

```
echo 400 >> /sys/class/backlight/nv_backlight/brigthness
```

 mais pommed ne prends plus les commandes à moins d'un reboot

```
/etc/init.d/pommed restart
```

 ny fait rien..

Edit 2 : corrigé avec pommed-1.34 de l'overlay keruspe

a tte

----------

## razer

 *jetboo wrote:*   

> Par ailleurs on peut maintenant régler la luminosité directement via X, alors qu'avant les drivers nvidia empêchaient ça et le temps de rétablissement d'un suspend/resume est + rapide.
> 
> 

 

J'ajouterais aussi que nouveau est globalement meilleur que le driver proprio en 2D et composite via xrender. Ainsi, un WM tel que metacity est plus rapide qu'avec les drivers proprios, avec comme sans composite d'activé.

En sus de KMS, de l'installation plus simple, il me parait meilleur pour tout usage hors 3D.

Libre et performant en somme, du tout bon. Reste juste à régler mon petit problème avec la synchro verticale, mais à priori cela ne dépend même pas de nouveau...

----------

## El_Goretto

 *razer wrote:*   

> Je n'ai pas de problèmes de lenteur, mais de tearing (synchronisation verticale)

 

 *http://nouveau.freedesktop.org/wiki/XVideoStatus wrote:*   

> A note about overlays:
> 
>       The overlay support status written below refers to non-KMS setup. In KMS, overlays are disabled until the proper support is added to the DRM. Since Nouveau now requires the use of KMS, overlays are not supported for now. Blitters and texture adapters still work. 

 

Mais ensuite:

 *Quote:*   

> Overlay: No overlay engine. Xv has to be done via the 3D engine (i.e. provide a texture adapter), and we're not quite ready for this yet.
> 
> Xv should be fully functional. 

 

Je ne comprends pas tout. Moi qui croyait que Xv était un overlay, erf. (passé trop de temps à bidouiller fglrx sans comprendre les fondamentaux on dirait).

Bref, pour éviter le tearing de video, il faudrait activer la synchronisation verticale côté rendu 3D (et activer un mode de rendu opengl sous mplayer j'imagine. quoique, mais alors Xv là dedans?).

--

edit: 

migration sous nouveau faite avec succès, DRI ok, vidéo via Xv sans tearing, KDE 4 avec transparence et tout.

Bonheur!

----------

## guilc

 *El_Goretto wrote:*   

> Je ne comprends pas tout. Moi qui croyait que Xv était un overlay, erf. (passé trop de temps à bidouiller fglrx sans comprendre les fondamentaux on dirait).
> 
> Bref, pour éviter le tearing de video, il faudrait activer la synchronisation verticale côté rendu 3D (et activer un mode de rendu opengl sous mplayer j'imagine. quoique, mais alors Xv là dedans?)

 

Ce que j'en ai compris :

xv est une extension vidéo qui permet de déléguer le redimensionnement et la conversion d'espace colorimétrique (YUV, YUYV et compagnie) à la carte graphique, pour éviter que ce soit le CPU qui fasse le boulot.

C'est la différence entre les sorties "xv" et "x11"

Par contre, ce que j'ai compris aussi c'est que quand le compositing est activé, xv n'est plus accessible. La manip se fait maintenant via des appels opengl sur la fenêtre de compositing (un backbuffer dans lequel est calculé ce qui va être affiché à l'écran). Bref, une "autre" manière de déléguer le boulot à la carte graphique.

Par contre, visiblement, c'est le driver qui fait le boulot de conversion, niveau mplayer ça change pas, tu utilises toujours "xv".

Enfin, c'est ce que j'ai compris de ce bazard  :Smile: 

 *Quote:*   

> migration sous nouveau faite avec succès, DRI ok, vidéo via Xv sans tearing, KDE 4 avec transparence et tout.
> 
> Bonheur!

 

Bienvenue au club  :Surprised: )

----------

## geekounet

 *guilc wrote:*   

> Par contre, ce que j'ai compris aussi c'est que quand le compositing est activé, xv n'est plus accessible. La manip se fait maintenant via des appels opengl sur la fenêtre de compositing (un backbuffer dans lequel est calculé ce qui va être affiché à l'écran). Bref, une "autre" manière de déléguer le boulot à la carte graphique.
> 
> Par contre, visiblement, c'est le driver qui fait le boulot de conversion, niveau mplayer ça change pas, tu utilises toujours "xv".

 

C'était le cas avec l'ancienne accelération 2D XAA, mais avec EXA il n'y a plus ce soucis avec XV et le compositing (du moins c'est le cas avec mon Intel et ma Radeon), et nouveau ne gère que l'EXA donc normalement c'est tout bon.  :Wink: 

----------

## razer

 *El_Goretto wrote:*   

> 
> 
> Bref, pour éviter le tearing de video, il faudrait activer la synchronisation verticale côté rendu 3D (et activer un mode de rendu opengl sous mplayer j'imagine. quoique, mais alors Xv là dedans?).
> 
> 

 

Là est bien le problème, car il ne semble pas possible de réaliser une synchro certicale correcte. Les drivers proprio souffrent d'ailleurs du même mal.

Perso, j'ai du tearing partout, composite ou pas : je bouge rapidement une grande fenêtre, et elle part en lamelles...

Le seul cas de figure ou je ne l'ai pas, c'est avec compiz et les drivers proprio sauf... dans les videos (je suis obligé de faire du undirect)

----------

## Fenril

Salut à tous,

Ça y est, moi aussi, j'ai franchi le pas.  :Very Happy:  Par contre j'aimerai apporter des précisions.

* Il y a une autre option du kernel que j'ai été obligé d'activer, sinon nouveau refusait de compiler, c'est le Virtual Frame Buffer support :

```
FB_VIRTUAL=y
```

Apparemment, de ce que j'ai compris, nouveau ne gère pas certaines fonctions d'accélération 2D qui doivent être émulées en utilisant des modules comme CFB_COPYAREA. Une idée ?

* Après, je n'ai pas compris pourquoi, mais même après désinstallation de nvidia-drivers, le module était encore présent, donc obligé de blacklister le module pour faire marcher nouveau.

* Ensuite, côté test : ça paraît effectivement plus fluide que sur les proprios. Cependant, j'ai fait des comparos de tests avec gtkperf entre les 2, les drivers proprios sont près de 2 fois plus rapide. Peut-être à cause de mon thème GTK qui utilise abondamment les pixmaps ? Ça me dérange pas de savoir ça puisque niveau ressenti j'ai l'impression que c'est plus fluide, je voulais juste relever la contradiction.

* En revanche, zéro problème niveau fonctionnement, vidéo, changement de résolution, réglages...

A noter, le lissage des polices est carrément meilleur, maintenant je me dis comment j'ai fait pour ne pas me plaindre avec les proprios tellement c'est horrible  :Exclamation: 

* Côté 3D, j'ai bien pensé à activer gallium, mais comment être sûr qu'il y a accélération des fonctionnalités supportées ? J'aimerai contribuer à l'avancée du support 3D pour nouveau. J'ai testé avec des jeux, quelques-uns marche sans souci, mais c'est lent. Comment être sûr que ce n'est pas le CPU qui se tape tout le boulot ?

Voili voilà.

----------

## guilc

 *Fenril wrote:*   

> * Il y a une autre option du kernel que j'ai été obligé d'activer, sinon nouveau refusait de compiler, c'est le Virtual Frame Buffer support :
> 
> ```
> FB_VIRTUAL=y
> ```
> ...

 

Heu...

```
# grep FB_VIRTUAL /usr/src/linux/.config

# CONFIG_FB_VIRTUAL is not set
```

 *Quote:*   

> * Après, je n'ai pas compris pourquoi, mais même après désinstallation de nvidia-drivers, le module était encore présent, donc obligé de blacklister le module pour faire marcher nouveau.

 

Ménage dans /lib/modules puis depmod -a  :Wink: 

----------

## Fenril

Bin c'est pour ça que je demande des explications du FB_VIRTUAL...  :Confused: 

Je suis le seul à en avoir besoin ? J'ai loupé quelque chose ?

Edit : Bon peut-être parce que je n'utilisais pas les drivers de l'overlay x11... je viens d'y passer (avec llvm d'activé), y a du mieux, principalement en 3D.

----------

## xaviermiller

J'utilise les drivers du kernel, présents dans la partie "staging drivers". Pas vous ?

Tout marche impec avec portage "pur", avec les dernières versions "testing" de Portage.

----------

## guilc

 *XavierMiller wrote:*   

> J'utilise les drivers du kernel, présents dans la partie "staging drivers". Pas vous ?

 

Ouaip, ici aussi, mais ça ça concerne que la 2D, pas la 3D

 *Quote:*   

> Tout marche impec avec portage "pur", avec les dernières versions "testing" de Portage.

 

Heu, la 3D marche, avec mesa 7.8.2 ?

Ici (NV86) la 3D ne marche pas avec cette version (crash de X), il faut passer sur mesa 7.9, et sur gallium/llvm pour améliorer les perfs. Donc overlay X11

----------

## Fenril

C'était effectivement ça, avec les derniers nouveau, pas besoin du FB_VIRTUAL dans mon cas, et un passage sur gtkperf montre que j'ai maintenant des performances 2D supérieures aux drivers propriétaires, héhé. Merci guilc.

Dernières infos, avec mesa 7.9/gallium et llvm, je fais tourner ut2004 avec tous les effets graphiques, c'est juste plus lent (mais jouable). Je dis ça surtout pour ceux qui ne veulent pas franchir le pas à cause de la 3D, si comme moi vous en avez besoin occasionnellement et vous jouez peu, aucun problème. Moi c'est décidé, j'abandonne les drivers nvidia (sauf si problèmes de bug avec les prochains drivers nouveau).

----------

## razer

Nouveau problème dont je viens de me rendre compte : openoffice devient d'une lenteur désespérante dès qu'on insère des images.

Testé avec openoffice-bin, et une compil mano. J'ignore vraiment la raison, étant donné que c'est le seul programme qui pose problème...

----------

## guilc

 *razer wrote:*   

> Je n'ai pas de problèmes de lenteur, mais de tearing (synchronisation verticale)

 

Je sais pas si tu as vu : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/

Les derniers commits devraient t'intéresser. En particulier http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=70f0d2c886ceaa965ca4864788f4dd8e8f757a92

le sync to vblank, qui devrait régler tes soucis de tearing  :Wink: 

----------

## Poussin

Salut,

Je me décide enfin à essayer.

Juste une petite question (parce que pour l'instant j'ai du faire une connerie ^^), je ne suis pas en ~arch et donc toujours en xorg-server 1.7, c'est censé fonctionner?

merci :$

----------

## Poussin

Je me réponds, ça marche  :Very Happy:  En fait j'avais laissé nvidia dans la config opengl (vous savez, avec eselect ^^) Shame on me...

Je suis vrai ravi de ce changement! Fini monpetit problème avec mplayer et compiz. De plus, la prise de controle à distance de gnome fonctionne maintenant meme si le serveur a activé compiz (chose qui foirait totalement avant)

Aucun idée des réelles performances de la choses pour de la 3D, et je pense bien que je m'en balance quand je vois le reste :]

Ravi ravi ravi   :Cool: 

----------

## netfab

Je déterre ce sujet. Je voudrais tester nouveau, mais ayant tout de même besoin régulièrement de la 3D, je me demande si il est possible de préconfigurer le système de façon à ce qu'un simple reboot puisse permettre de passer des drivers nouveau à nvidia et inversement ? Je pense au blacklistage du module nvidia, au choix de la configuration xorg, etc... tout ceci doit se faire en root.

----------

## Fenril

J'y ai pensé aussi. Une idée comme ça : en ayant deux noyaux et/ou en gérant par script de démarrage 2 versions du modules.conf ?

----------

## netfab

Oui, 2 noyaux c'est ce que je comptais faire. Je crois que je vais gérer çà en créant d'autres runlevels, le choix se fera donc avec un paramètre passé au noyau sélectionné. Je pense que çà sera la façon la plus propre d'y arriver.

----------

## guilc

why not.

Le seul truc à changer en plus du kernel c'est le fichier de conf de X. pas besoin de toucher aux modules : il suffit de ne PAS placer le module nvidia dedans : il se charge totu seul automatiquement au lancement de X si X est configuré pour utiliser le driver nvidia (enfin, c'était comme ça à l'époque ou j'utilisais encore le driver propriétaire, ce qui remonte à quelques mois maintenant (début du fil))

----------

## Fenril

Et en installant le paquet xf86-video-nouveau à la place de son activation en dur dans le kernel, ça ne faciliterait-il pas les choses ?

guilc > en conservant le module nvidia au début j'étais obligé de le blacklister sinon X ne voulait pas démarrer avec nouveau.

----------

## guilc

 *Fenril wrote:*   

> Et en installant le paquet xf86-video-nouveau à la place de son activation en dur dans le kernel, ça ne faciliterait-il pas les choses ?

 

Ca n'a rien à voir : xf86-video-nouveau est le driver X. Ce driver a besoin de configuration dans *dans* le kernel (KMS, DRM). Et ce sont ces options là qui ne sont pas compatible avec le driver propriétaire.

D'où le besoin de 2 noyaux avec des configurations différentes

----------

## netfab

Bon, çà fonctionne, enfin tout du moins avec openrc et baselayout2, pas testé avec l'ancien système d'init.

Le script d'initialisation et la méthode ont évolué. Je laisse ce post uniquement pour référence.

Je blackliste le module nvidia, je le charge manuellement si besoin par la suite.

 *Quote:*   

> 
> 
> $ grep nvidia /etc/modprobe.d/blacklist.conf
> 
> blacklist nvidia
> ...

 

J'ai donc compilé 2 noyaux différents, un avec le framebuffer et l'autre avec KMS et nouveau.

```

$ ls -l /boot/ | grep kernel

-rw-r--r-- 1 root root 3312320 18 déc.  17:59 kernel-2.6.36-gentoo-r5-FB_NVIDIA

-rw-r--r-- 1 root root 3551968 23 janv. 14:09 kernel-2.6.36-gentoo-r5-KMS_NOUVEAU

```

Pour xorg je créé 2 fichiers de configuration indépendants. Je vais utiliser par la suite le répertoire xorg.conf.d :

```

$ ls -l /etc/X11 | grep xorg

-rw-r--r-- 1 root root  235 23 janv. 14:53 xorg-nouveau.conf

-rw-r--r-- 1 root root  322 25 janv. 18:51 xorg-nvidia.conf

drwxr-xr-x 2 root root 4096 25 janv. 23:52 xorg.conf.d

```

Dans le fichier xorg-nvidia.conf, en plus de ma configuration habituelle pour le driver propriétaire, j'ai ceci, afin d'éviter le chargement automatique du driver nouveau :

```

Section "Module"

        Disable     "nouveau"

EndSection

```

Le script d'initialisation qui va permettre d'effectuer les modifications necessaires à chaque boot ...

```

#!/sbin/runscript

# Copyright 1999-2011 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

depend() {

   need localmount

   before xdm

}

start() {

   local DRV=${RC_SVCNAME}

   local impl= modules=

   case "${DRV}" in

      nvidia)

         impl="nvidia"

         modules="nvidia"

      ;;

      nouveau)

         impl="xorg-x11"

      ;;

      *)

         eerror "wrong video card driver provided on kernel command line"

      ;;

   esac

   dosym /etc/X11/xorg-${DRV}.conf /etc/X11/xorg.conf.d/videocard.conf || return 1

   for x in $modules; do

      ebegin "Loading module $x"

      eval modprobe -q "$x"

      eend $? "Failed to load $x" || return 1

   done

   ebegin "Switching to ${impl} OpenGL implementation"

   eval eselect opengl set "${impl}" >/dev/null 2>&1

   eend $? "Failed to switch to the correct OpenGL interface" || return 1

   einfo "Setted up environment for $DRV X driver"

   return 0

}

dosym() {

   ebegin "Symlinking $1"

   if [ ! -f "$1" ]; then

      eend 1 "Missing file $1" || return 1

   else

      eval ln -snf "$1" "$2"

      eend $? "Failed to symlink $1" || return 1

   fi

}

```

 ... que je sauvegarde sous le nom nvidia-nouveau-switch dans /etc/init.d, et je créé 2 liens symboliques vers ce fichier.

```

$ ls -l /etc/init.d/ | grep nvidia

lrwxrwxrwx 1 root root    21 23 janv. 17:15 nouveau -> nvidia-nouveau-switch

lrwxrwxrwx 1 root root    21 23 janv. 17:15 nvidia -> nvidia-nouveau-switch

-rwxr-xr-x 1 root root  1030 25 janv. 23:18 nvidia-nouveau-switch

```

Comme expliqué dans le handbook, je créé donc 2 runlevels supplémentaires, qui contiennent exactement les même services que le runlevel default.

J'ajoute le service nvidia au runlevel nvidia, et le service nouveau au runlevel nouveau.

```

# rc-update show default nvidia nouveau

           vixie-cron | nvidia nouveau default

               nvidia | nvidia                

            syslog-ng | nvidia nouveau default

                  nfs | nvidia nouveau default

                 dbus | nvidia nouveau default

       udev-postmount | nvidia nouveau default

                local | nvidia nouveau default

                acpid | nvidia nouveau default

           consolekit | nvidia nouveau default

             net.eth0 | nvidia nouveau default

              nouveau |        nouveau        

                  xdm | nvidia nouveau default

```

Dans ma configuration de grub je n'oublie pas d'ajouter les options softlevel correspondantes aux noyaux :

 *Quote:*   

> 
> 
> $ grep -B 3 softlevel /boot/grub/grub.conf 
> 
> title Gentoo Linux 2.6.36-r5 - Framebuffer et Nvidia
> ...

 

Le boot avec le driver nvidia propriétaire :

```

 * Symlinking /etc/X11/xorg-nvidia.conf ...                 [ ok ]

 * Loading module nvidia ...                                [ ok ]

 * Switching to nvidia OpenGL implementation ...            [ ok ]

 * Setted up environment for nvidia X driver

 * Setting up gdm ...                                       [ ok ]

$ ls -l /etc/X11/xorg.conf.d/ | grep videocard

lrwxrwxrwx 1 root root  25 26 janv. 00:35 videocard.conf -> /etc/X11/xorg-nvidia.conf

$ eselect opengl list

Available OpenGL implementations:

  [1]   nvidia *

  [2]   xorg-x11

```

Le boot avec le driver nouveau :

```

 * Symlinking /etc/X11/xorg-nouveau.conf ...                [ ok ]

 * Switching to xorg-x11 OpenGL implementation ...          [ ok ]

 * Setted up environment for nouveau X driver

 * Setting up gdm ...                                       [ ok ]

$ ls -l /etc/X11/xorg.conf.d/ | grep videocard

lrwxrwxrwx 1 root root  26 25 janv. 23:52 videocard.conf -> /etc/X11/xorg-nouveau.conf

$ eselect opengl list

Available OpenGL implementations:

  [1]   nvidia

  [2]   xorg-x11 *

```

Last edited by netfab on Mon Jan 31, 2011 9:11 am; edited 1 time in total

----------

## Mickael

netfb, ton post mérite d'être dupliqué dans la partie script and Co.

----------

## El_Goretto

+1, ça m'a l'air tout à fait sympathique comme méthode.

----------

## barul

Testé avec le message #1 de guilc, fonctionne très bien, je suis bien heureux d'avoir enfin des TTYs avec une vraie résolution, et pas avec 80 colonnes  :Smile: 

Ma carte est une Nvidia G310M, j'ai testé un film de qualité "normale", ça passe très bien, et idem pour une vidéo en 360p de youtube.

Je pense que le laptop vient d'adopter nouveau  :Very Happy: 

----------

## guilc

Ben tiens, au passage, petite mise à jour du post. Plus besoin d'overlay x11, 2.6.37 conseillé pour les corrections et améliorations qu'il apporte.

----------

## barul

Un petit retour désagréable que j'ai eu : depuis 2 ou 3 jours, mon X faisait des jolis segfaults, plus d'accès aux TTYs, quelque chose de beau. J'ai donc mis à jour libdrm, nouveau et mesa en ~amd64. Pour l'instant, aucun segfault.

Je ne peux pas vous présenter les logs, je les avais mis sur pastebin.com, mais apparement le temps de conservation à expiré. Je me rappelle qu'il parlait de, je cite, "infinite loop", entre autres. Avec les codes bizarres de segfault classiques.

Désolé pour le manque de détails :/

----------

## guilc

Je pense pas ce que soit lié à nouveau.

A un moment (du genre il y a 1 an à 6 mois) j'avais ce genre d'infinite loop sur mon laptop avec une intel GM4500. Ca a cessé au fil des mises à jour, j'ai jamais vraiment su pourquoi...

Par contre, je n'ai jamais eu ça avec nouveau (toujours en ~arch of course)

----------

## jetboo

Vous avez des fois le bug suivant ? : Au retour d'un resume si j'essais de regarder une video de type flash (genre youtube) en plein écran sous firefox, tout l'affichage freeze mais le son continu. Impossible de alt+ctrl+1, plus de souris qui bouge reset oubligatoire

----------

## barul

guilc: Je pense qu'en faisaint la màj tu as du supprimer quelque chose. Pour mesa, il manque le USE llvm.

----------

## guilc

merci remis.

Par contre, si le use gallium est indispensable, llvm ne l'est pas.

A l'époque, c'était nécessaire pour les améliorations notables de perfs (mesa 7.9 rc). Faudrait faire des tests maintenant avec les version courantes de mesa : il se peut que cela n'apporte rien....

----------

## barul

Bin je sais pas si llvm n'est vraiment pas indispensable, parce que j'ai re-suivi ton tuto après une réinstallation complète, et j'avais des problèmes de textures sur fluxbox.

Après avoir fait deux choses, il s'est résolu; malheureusement, je ne pourrais pas dire laquelle ou bien si c'est grâce aux deux. J'ai recompilé mesa avec les deux USE, et j'ai mis à jour nouveau. Étant donné que la première fois que j'ai utilisé nouveau je n'avais pas de problèmes de textures, je pense tout de même à llvm qui manquait; mais je ne suis sûr de rien.

Edit : X vient juste de me re-segfault à l'instant :

```
[  3490.778] [mi] EQ overflowing. The server is probably stuck in an infinite loop.

[  3490.778]

Backtrace:

[  3491.081] 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a1be8]

[  3491.081] 1: /usr/bin/X (mieqEnqueue+0x1eb) [0x4a157b]

[  3491.081] 2: /usr/bin/X (xf86PostButtonEventP+0xca) [0x47e58a]

[  3491.081] 3: /usr/bin/X (xf86PostButtonEvent+0xb9) [0x47e6b9]

[  3491.081] 4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f8bd4282000+0x4301) [0x7f8bd4286301]

[  3491.081] 5: /usr/bin/X (0x400000+0x6ccd7) [0x46ccd7]

[  3491.081] 6: /usr/bin/X (0x400000+0x11a309) [0x51a309]

[  3491.081] 7: /lib/libpthread.so.0 (0x7f8bd91f4000+0xf010) [0x7f8bd9203010]

[  3491.081] 8: /lib/libc.so.6 (ioctl+0x7) [0x7f8bd8493ac7]

[  3491.081] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x28) [0x7f8bd6a44bf8]

[  3491.081] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x1b) [0x7f8bd6a44e7b]

[  3491.081] 11: /usr/lib/libdrm_nouveau.so.1 (0x7f8bd6403000+0x32fd) [0x7f8bd64062fd]

[  3491.081] 12: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xf6) [0x7f8bd64064f6]

[  3491.081] 13: /usr/lib/libdrm_nouveau.so.1 (0x7f8bd6403000+0x24f9) [0x7f8bd64054f9]

[  3491.082] 14: /usr/lib/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x187) [0x7f8bd64058c7]

[  3491.082] 15: /usr/lib64/xorg/modules/libexa.so (0x7f8bd5fc6000+0xa20d) [0x7f8bd5fd020d]

[  3491.082] 16: /usr/lib64/xorg/modules/libexa.so (0x7f8bd5fc6000+0xb439) [0x7f8bd5fd1439]

[  3491.082] 17: /usr/bin/X (0x400000+0xd7c8d) [0x4d7c8d]

[  3491.082] 18: /usr/lib64/xorg/modules/libexa.so (0x7f8bd5fc6000+0xd745) [0x7f8bd5fd3745]

[  3491.082] 19: /usr/bin/X (0x400000+0xd7460) [0x4d7460]

[  3491.082] 20: /usr/bin/X (0x400000+0xd1266) [0x4d1266]

[  3491.082] 21: /usr/bin/X (0x400000+0x2f249) [0x42f249]

[  3491.082] 22: /usr/bin/X (0x400000+0x248fa) [0x4248fa]

[  3491.082] 23: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f8bd83e8bbd]

[  3491.082] 24: /usr/bin/X (0x400000+0x24499) [0x424499]
```

----------

## El_Goretto

Quelqu'un arrive à faire fonctionner nouveau sur un 2.6.37?

Avec les ck-sources et les gentoo-sources, même problème:

```
drivers/built-in.o: In function `acpi_video_bus_put_devices':

video.c:(.text+0x4dbcf): undefined reference to `backlight_device_unregister'

drivers/built-in.o: In function `acpi_video_switch_brightness':

video.c:(.text+0x4e02c): undefined reference to `backlight_force_update'

drivers/built-in.o: In function `acpi_video_bus_add':

video.c:(.text+0x4ed9f): undefined reference to `backlight_device_register'

```

Sur ck-sources, j'ai un peu plus de warning à la config du kernel, mais qui ne me parlent pas des masses:

```
warning: (STUB_POULSBO && HAS_IOMEM && PCI && ACPI || DRM_I915 && <choice> && AGP_INTEL && ACPI || DRM_NOUVEAU && STAGING && !STAGING_EXCLUDE_BUILD && DRM && PCI && ACPI) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL && INPUT)
```

----------

## guilc

Ah oui, j'ai eu ça...

Faut activer le support de backlight, même si tu n'as pas de laptop (et donc pas de support backlight utilisable) : CONFIG_FB_BACKLIGHT

----------

## Tom_

Je n'arrive pas à faire fonctionner la mise en veille avec les drivers Nouveau. Si je désactive KMS (donc plus de drivers Nouveau) la mise en veille fonctionne donc je dirais que le problème est lié à Nouveau/KMS.

Quelqu'un qui a la mise en veille fonctionnelle pourrait copier sa config noyau ici ? 

Mercii

----------

## barul

Actuellement je n'ai plus nouveau, mais la vise en veille fonctionnait parfaitement avec le tuto de guilc.

Mis à part les options listées dans le premier post, je n'ai rien désactivé d'autre.

Actuellement j'utilise le blob nvidia, mais si tu es tout de même intéressé, voilà mon .config : 

http://pastebin.com/75xdm06i

----------

## Katagoto

MerciLast edited by Katagoto on Tue Sep 27, 2011 6:06 pm; edited 1 time in total

----------

## barul

À l'époque à laquelle je m'étais interessé à nouveau pour ma GTX 460 également, la prise en charge était « all sorts of fun », et on dirait que c'est toujours le cas.

cf. http://nouveau.freedesktop.org/wiki/CodeNames (Tout en bas de la page)

----------

## Leander256

 *Cr0k wrote:*   

> À l'époque à laquelle je m'étais interessé à nouveau pour ma GTX 460 également, la prise en charge était « all sorts of fun », et on dirait que c'est toujours le cas.
> 
> cf. http://nouveau.freedesktop.org/wiki/CodeNames (Tout en bas de la page)

 

La description en-dessous du nom de la famille ne concerne pas le support, elle décrit tout simplement les évolutions majeures apportées aux chipsets de la famille...   :Rolling Eyes: 

 C'est le tableau suivant qu'il faut consulter pour savoir où en sont les fonctionnalités de ta carte: http://nouveau.freedesktop.org/wiki/FeatureMatrix

----------

## Katagoto

MerciLast edited by Katagoto on Tue Sep 27, 2011 6:06 pm; edited 1 time in total

----------

## guilc

Heu, support minimum MAIS, tu as noté la petite note "9" ?

Il te faut extraire le firmware : http://nouveau.freedesktop.org/wiki/NVC0_Firmware

----------

## barul

Bon, je viens de compiler nouveau depuis le dernier git, et c'est quand même vachement plus stable depuis le 2.6.39 apparement. Actuellement je suis sous le 3.0-rc2, aucun problème en ce qui concerne la 2D, je n'ai plus de segfault  :Very Happy: 

----------

## Leander256

Pareil pour ma Geforce 310M, je suis repassé à Nouveau depuis le 2.6.39 et c'est bien stable en 2D, par contre le GPU chauffe pas mal (en ce moment 67°C sans rien faire de particulier), j'ai bien peur que son voltage soit constant. Si quelqu'un a des pistes à ce sujet ça m'intéresse j'essayerai de voir ça ce week-end.

----------

## guilc

 *Leander256 wrote:*   

> Pareil pour ma Geforce 310M, je suis repassé à Nouveau depuis le 2.6.39 et c'est bien stable en 2D, par contre le GPU chauffe pas mal (en ce moment 67°C sans rien faire de particulier), j'ai bien peur que son voltage soit constant. Si quelqu'un a des pistes à ce sujet ça m'intéresse j'essayerai de voir ça ce week-end.

 

A ce propos, c'est assez variable. Je ne me l'explique pas trop. J'ai 2 configs assez similaires : chez moi, G86 (Quadro NVS290), en passif. Je suis à 66° de moyenne. Chez mes parents, même CPU G86 (une 8400GS), refroidissement passif pareil, elle est autour de 40°... Les deux avec les mêmes versions de soft (gentoo ~amd64, 2.6.39.1).

Le driver est sensé gérer les modes d'économie d'énergie maintenant. Mais il y a peut-être des soucis suivant les cartes...

Je note que la mienne n'a que 2 paliers :

```
# cat /sys/class/hwmon/hwmon0/device/performance_level_0

0: memory 100MHz core 208MHz shader 416MHz fanspeed 100%

# cat /sys/class/hwmon/hwmon0/device/performance_level_1

1: memory 400MHz core 459MHz shader 918MHz fanspeed 100%

```

Je ne peux pas vérifier sur la machine des mes parents, le PC est éteint, mais il y a peut-être plus de paliers, ce qui pourrait avoir un impact la dessus...

----------

## Leander256

Voilà ce que j'ai au démarrage sur un 2.6.39.2 vanilla:

```
Jun 24 23:56:18 localhost kernel: [drm] nouveau 0000:01:00.0: 3 available performance level(s)

Jun 24 23:56:18 localhost kernel: [drm] nouveau 0000:01:00.0: 0: memory 135MHz core 135MHz shader 270MHz voltage 850mV

Jun 24 23:56:18 localhost kernel: [drm] nouveau 0000:01:00.0: 1: memory 405MHz core 405MHz shader 810MHz voltage 850mV

Jun 24 23:56:18 localhost kernel: [drm] nouveau 0000:01:00.0: 3: memory 790MHz core 625MHz shader 1530MHz voltage 1030mV

Jun 24 23:56:18 localhost kernel: [drm] nouveau 0000:01:00.0: c: memory 950MHz core 550MHz shader 200MHz voltage 1030mV
```

Mais étrangement ce niveau "c" n'apparaît pas dans la liste des périphériques dans /sys, même si il est reporté en tant que niveau de démarrage:

```
# cat /sys/class/hwmon/hwmon0/device/performance_level

setting: boot

c: memory 950MHz core 550MHz shader 200MHz voltage 1030mV

# cat /sys/class/hwmon/hwmon0/device/performance_level_*

0: memory 135MHz core 135MHz shader 270MHz voltage 850mV

1: memory 405MHz core 405MHz shader 810MHz voltage 850mV

3: memory 790MHz core 625MHz shader 1530MHz voltage 1030mV
```

J'ai essayé avec nvclock mais il ne reconnaît pas mon GPU.

----------

## guilc

Bon ben vu sur PC de mes parents : un seul niveau : a fond. C'est donc pas ça qui peut expliquer la différence...

Peut-être que cela dépend-t-il simplement du modèle de carte ?

----------

## Chr0nos

a quand la vdpau sur nouveau xD (probablement jamais hélas...)

et je ne parle meme pas de cuda ^^ snif

----------

## geekounet

VDPAU n'est pas standard, osef.  :Wink:  Par contre VA-API devrait être implémenté rapidement si ce n'est déjà fait.

----------

## Poussin

Sur une machine où tout roulait, réinstallation pour cause de changement de disque dur, c'est moins drôle. Petits freezes de quelques secondes «aléatoires» accompagnés de:

```

[ 1799.843343] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 1801.799361] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2179.156591] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2181.081300] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2562.534877] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2564.483110] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2703.561781] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2705.486255] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2707.416860] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2709.332281] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2711.250543] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

[ 2713.224524] [drm] nouveau 0000:01:00.0: vm flush timeout: 0x00000032

```

Je pense que je vais repasser à un kernel < 2.6.39

----------

## Leander256

Bon après un nouveau plantage du pilote nvidia j'ai décidé de consacrer un peu de temps à ce pilote nouveau qui chauffe trop. J'ai récupéré la dernière version du noyau et la dernière version du pilote par git (tout est expliqué ici), ça chauffait toujours autant. Je me suis dit que puisque le pilote était capable de trouver les valeurs correctes pour les différents niveaux d'énergie, il y avait peut-être moyen d'en choisir un. Il s'avère que c'est possible, mais si certains GPUs sont gérés automatiquement, le mien doit être considéré comme pas assez testé, donc j'ai un peu bidouillé le code source pour forcer le passage à un niveau donné. Ça donne ça:

```
[drm] nouveau 0000:01:00.0: 3 available performance level(s)

[drm] nouveau 0000:01:00.0: 0: memory 135MHz core 135MHz shader 270MHz voltage 850mV timing 2

[drm] nouveau 0000:01:00.0: 1: memory 405MHz core 405MHz shader 810MHz voltage 850mV timing 1

[drm] nouveau 0000:01:00.0: 3: memory 790MHz core 625MHz shader 1530MHz voltage 1030mV timing 0

[drm] nouveau 0000:01:00.0: c: memory 405MHz core 405MHz shader 810MHz voltage 1030mV

[drm] nouveau 0000:01:00.0: setting performance level: 0

[drm] nouveau 0000:01:00.0: c:memory 135MHz core 135MHz shader 270MHz voltage 850mV
```

Au passage le "c" signifie "current", donc actuel. Je n'arrive pas encore à une température aussi basse qu'avec le pilote proprio, environ 54°C au lieu de 48°C en idle, mais c'est bien mieux que les 70°C sans bidouille. Je n'ai plus peur de faire un emerge qui utilise tous les cores de la machine! Forcément niveau performances 3D c'est pas génial, mais pour de la bureautique rien à redire.

A noter la présence de ces deux fichiers:

```
 $ ls -l /sys/module/nouveau/parameters/perflvl*

-r-------- 1 root root 4096 Aug 27 04:24 /sys/module/nouveau/parameters/perflvl

-r-------- 1 root root 4096 Aug 27 04:24 /sys/module/nouveau/parameters/perflvl_wr

```

Mettre perflvl_wr à 1 permet de modifier perflvl, mais malheureusement ils sont en lecture seule chez moi (et, je pense, chez tout le monde).

----------

