Bonjour à tous et tout d'abord désolé de coller du propriétaire NVIDIA sur une Fedora, mais je n'ai pas de carte de chez AMD sous la main et j'ai besoin de la puissance de calcul de la carte, ce que Nouveau ne m'apporte pas correctement.

Nouveau sur Fedora, mais motivé à y rester après des années à utiliser Ubuntu par facilité ou Debian Sid par masochisme, je me suis lancé dans l'installation sous Fedora 27 de ma nouvelle machine dont voici la configuration :
Carte mère : ASRock AB350M Pro4 (UEFI inside)
Processeur : Ryzen 5 1600
Carte graphique : GTX 970
Pour le reste, de la DDR4 en quantité et des SSD+HDD.

En bon petit novice, j'ai bien pris garde d'avoir la documentation en main et j'ai utilisé la page dédiée aux pilotes propriétaires NVIDIA pour installer ces derniers. Je parts d'ailleurs d'une installation toute fraiche.

J'ai tout d'abord ajouté les dépots RPMFusion, puis suivi la démarche pour les GeForce récentes.

Un petit reboot et retour à l'écran de choix du compte utilisateur.

Ici, premier couac, je rentre et la définition choisie est supérieure à celle que peut accepter mon moniteur. Du 1920x1080 sur un engin taillé pour le 1366x768, certainement une erreur d'interprétation du 1080i disponible et rien de bien grave puisque le moniteur affiche tout de même le bureau (un zoom sur le centre) et je peux donc modifier la chose.

Fait plus grave, tout est excessivement lent. Lancer un terminal me fige la souris bien 10 secondes (pointeur tournant) et toutes les applications réagissent de même. Une fois lancées, je n'ai cependant plus de problème (comme par exemple avec Firefox que j'utilise sur la machine pour écrire ce texte).

J'ai farfouillé pour trouver ce qui pouvait bloquer. J'ai désactivé Wayland sur GDM (comme conseillé ici), sans succès. Je suis retourné dans la documentation pour jeter un oeil aux erreurs connues, mais je sèche. Nouveau n'est pas chargé en même temps, donc pas de conflit. Mon BIOS ne me permet pas d'activer l'IRQ ou de désactiver Plug&Play pour le VGA, xorg-x11-drv-nvidia est bien à la même version que akmod-nvidia et les autres options sont hors de mon domaine de compétence, raison pour laquelle je viens faire appel à la communauté.

J'ai aussi lu que l'UEFI posait problème dans certains cas, est-ce que c'est ce qui m'arrive ? Si c'est le cas, je vais donc devoir suivre ce guide, mais vais-je garder la même souplesse d'utilisation qu'avec akmod qui permet d'automatiquement recompiler à chaque changement de noyau ? Je sais qu'il faut aimer mettre les mains dans le cambouis pour profiter du monde GNU/Linux, mais après quelques temps en Debian Sid, j'ai envie d'un peu de stabilité !

A noter que lors d'une précédente tentative, j'avais réussi à avoir des pilotes fonctionnels, mais les paquets venaient d'un dépôt privé (Negativo) et je préfèrerai utiliser quelque chose de plus sûr.

Merci de m'avoir lu et désolé du dérangement. :roll:
Hello,
et bienvenu parmi nous ! Concernant l'UEFI, ça date du noyau 4.10 et on est au 4.14. J'imagine que le sujet à été résolu depuis. tente de désactiver l'UEFI sans toucher au pilote pour voir ?

Il n'y a pas de différence de comportement entre Wayland et Xorg donc ? Et les lenteurs viennent bien de l'installation du akmod-nvidia ? si tu vires *nvidia* et que tu rebootes, le système tourne sans problème ?
Edouard_le_homard wrote:Hello,
et bienvenu parmi nous ! Concernant l'UEFI, ça date du noyau 4.10 et on est au 4.14. J'imagine que le sujet à été résolu depuis. tente de désactiver l'UEFI sans toucher au pilote pour voir ?

Il n'y a pas de différence de comportement entre Wayland et Xorg donc ? Et les lenteurs viennent bien de l'installation du akmod-nvidia ? si tu vires *nvidia* et que tu rebootes, le système tourne sans problème ?
Salut Edouard et merci pour l'accueil et la réponse !

Là je suis repassé sous Nouveau en supprimant tout ce qui était NVIDIA propriétaire et tout roule. En propriétaire, j'avais un système lent de base et si je modifiais Wayland, plus moyen de me connecter (freeze sur l'écran de fond gris de la page de gestion des comptes).

Tu me proposes de désactiver l'UEFI sans toucher au pilote, comment faire ? Un bricolage dans GRUB en modifiant le boot ?
En effet, Wayland n'est pas encore tout à fait au point...

Qu'est ce qui justifie l'installation du pilote proprio ? Peux tu détailler ?

Pour l'UEFI, tu désactives ça dans le BIOS. Après je viens de me rendre compte que ça risque de ne plus booter... je me demande si ça n'a pas déjà été abordé dans le forum. Tu dois pouvoir t'en sortir en bootant sur un liveUSB et en réinstallant le grub depuis le liveUSB sur la partition /boot de ton disque dur. mais à vérifier.
Je suis joueur et c'est ce qui me lie aux pilotes propriétaires (j'ai abandonné Windows il y a longtemps, mais j'aime toujours jouer !).

Si je renonce à l'UEFI, ça veut donc dire qu'il va falloir partir sur une réinstallation. C'est un peu dommage avec ce genre de matos...
> Je suis joueur et c'est ce qui me lie aux pilotes propriétaires
perso j'ai un petit SSD sur lequel j'ai un windows d'installé, et je joue avec ce seul disque dur. ça évite les dual boot et les emm... en général.

> Si je renonce à l'UEFI, ça veut donc dire qu'il va falloir partir sur une réinstallation.
Je suis convaincu que tu peux juste réinstaller le grub à partir d'un liveUSB. cherche dans le forum, je pense que ça a été déjà abordé par nouvo
Edouard_le_homard wrote:> Je suis joueur et c'est ce qui me lie aux pilotes propriétaires
perso j'ai un petit SSD sur lequel j'ai un windows d'installé, et je joue avec ce seul disque dur. ça évite les dual boot et les emm... en général.
J'aime autant que faire ce peut éviter d'avoir à passer par Windows. Mes jeux fonctionnent sous Wine, pourquoi m'embêter ? 😃
Edouard_le_homard wrote:> Si je renonce à l'UEFI, ça veut donc dire qu'il va falloir partir sur une réinstallation.
Je suis convaincu que tu peux juste réinstaller le grub à partir d'un liveUSB. cherche dans le forum, je pense que ça a été déjà abordé par nouvo
Je vais regarder, merci ! Ça reste cependant un moyen détourné de résoudre le problème et ça a un quelque chose de frustrant :p
Si cela peut jouer dans la résolution de la chose, je me suis rendu compte que lorsque les pilotes NVIDIA RPMFusion sont installés, le moniteur système m'affiche une consommation de 30 à 40% du CPU par gnome-shell. Tous les 6 coeurs et 12 threads de mon petit Ryzen qui moulinent ensemble juste pour afficher le bureau !
Ghiomino wrote:Si cela peut jouer dans la résolution de la chose, je me suis rendu compte que lorsque les pilotes NVIDIA RPMFusion sont installés, le moniteur système m'affiche une consommation de 30 à 40% du CPU par gnome-shell. Tous les 6 coeurs et 12 threads de mon petit Ryzen qui moulinent ensemble juste pour afficher le bureau !
Je pense que là il y a un petit problème quelque part.
KDE et gnome shell sont assez gourmand en ressource, mais prendre 30-40 % en ressource cpu me semble excessif.
Perso je suis avec un core I3, carte nvidia et driver propriétaire et l'affichage du bureau KDE ne me prend que 1 à 2 % d'utilisation cpu.
Edouard_le_homard wrote:As-tu essayé avec un autre environnement de bureau type KDE ?
J'aime beaucoup Gnome 3 et toutes les modifications qu'il permet, du coup non je n'ai pas utilisé d'autre environnement.

Je sais, j'en demande beaucoup !
chepioq wrote: Je pense que là il y a un petit problème quelque part.
KDE et gnome shell sont assez gourmand en ressource, mais prendre 30-40 % en ressource cpu me semble excessif.
Perso je suis avec un core I3, carte nvidia et driver propriétaire et l'affichage du bureau ne me prend que 1 à 2 % d'utilisation cpu.
Sous Nouveau, je n'ai qu'une charge de 1 à 4% pour gnome-shell. Je confirme donc que les 30 à 40% sont exagérés ! 😃
Il se peut aussi qu'un service systemd en soit la cause.
que retourne la commande : 
systemd-analyze blame
chepioq wrote:Il se peut aussi qu'un service systemd en soit la cause.
que retourne la commande : 
systemd-analyze blame
Je viens de faire une tentative de retour sous akmod-nvidia RPMFusion et plantage au démarrage. Je repasse sur Nouveau pour la soirée, mais je ne manquerai pas de réitérer l'expérience dès demain ! Merci à toi 🙂

Je teste d'ailleurs cette commande que je découvre, ça me permettra de voir demain sous pilotes proprio ce qui change :
[guillaume@localhost ~]$ systemd-analyze blame
          3.903s plymouth-quit-wait.service
          1.962s NetworkManager-wait-online.service
          1.543s dracut-initqueue.service
          1.040s lvm2-monitor.service
           911ms systemd-udev-settle.service
           738ms fwupd.service
           492ms firewalld.service
           362ms dev-mapper-fedora\x2droot.device
           335ms initrd-switch-root.service
           296ms sssd.service
           199ms libvirtd.service
           171ms udisks2.service
           126ms dracut-pre-pivot.service
           120ms ModemManager.service
           100ms lvm2-pvscan@8:33.service
           100ms lvm2-pvscan@8:3.service
            98ms systemd-vconsole-setup.service
            97ms switcheroo-control.service
            96ms gssproxy.service
            90ms rtkit-daemon.service
            89ms user@42.service
            87ms avahi-daemon.service
            85ms packagekit.service
            84ms abrtd.service
            84ms systemd-journal-flush.service
            77ms user@1000.service
            75ms systemd-udev-trigger.service
            73ms systemd-udevd.service
            68ms upower.service
            65ms chronyd.service
            58ms dracut-cmdline.service
            46ms systemd-tmpfiles-setup-dev.service
            45ms initrd-parse-etc.service
            42ms systemd-tmpfiles-setup.service
            42ms polkit.service
            37ms systemd-binfmt.service
            35ms auditd.service
            35ms NetworkManager.service
            32ms var-lib-nfs-rpc_pipefs.mount
            30ms fedora-readonly.service
            28ms fedora-import-state.service
            28ms systemd-fsck@dev-disk-by\x2duuid-21C4\x2d1573.service
            26ms systemd-fsck@dev-disk-by\x2duuid-6d4fe513\x2deae1\x2d4740\x2d8c
            22ms colord.service
            22ms cups.service
            21ms gdm.service
            20ms systemd-logind.service
            20ms accounts-daemon.service
            18ms proc-sys-fs-binfmt_misc.mount
            17ms geoclue.service
            16ms systemd-fsck-root.service
            16ms systemd-sysctl.service
            16ms boot-efi.mount
            16ms systemd-remount-fs.service
            16ms systemd-journald.service
            15ms dracut-pre-udev.service
            15ms home.mount
            15ms plymouth-read-write.service
            15ms systemd-fsck@dev-mapper-fedora\x2dhome.service
            15ms wpa_supplicant.service
            14ms plymouth-start.service
            13ms dev-mqueue.mount
            12ms plymouth-switch-root.service
            11ms kmod-static-nodes.service
            10ms boot.mount
            10ms dev-mapper-fedora\x2dswap.swap
             9ms nfs-config.service
             8ms systemd-update-utmp-runlevel.service
             8ms sysroot.mount
             8ms sys-kernel-debug.mount
             6ms dev-hugepages.mount
             6ms initrd-cleanup.service
             6ms rpc-statd-notify.service
             6ms sys-fs-fuse-connections.mount
             5ms systemd-user-sessions.service
             5ms systemd-update-utmp.service
             4ms systemd-random-seed.service
             3ms tmp.mount
             3ms initrd-udevadm-cleanup-db.service
             2ms dracut-shutdown.service
             1ms sys-kernel-config.mount
Lance un akmods en root pourverifier si le pilote a bien été compilé
chepioq wrote:Il se peut aussi qu'un service systemd en soit la cause.
que retourne la commande : 
systemd-analyze blame
Me revoilà sous pilotes proprios, toujours le même problème de lenteur, mais la définition n'a pas sauté cette fois ! Gnome Shell pompe toujours 30 à 40% sur tous les coeurs de mon CPU.

Voici du coup la réponse à la commande demandée :
[guillaume@localhost ~]$ systemd-analyze blame
          4.568s plymouth-quit-wait.service
          2.030s NetworkManager-wait-online.service
          1.303s lvm2-monitor.service
          1.173s systemd-udev-settle.service
           734ms fwupd.service
           506ms firewalld.service
           347ms dev-mapper-fedora\x2droot.device
           333ms dracut-initqueue.service
           326ms initrd-switch-root.service
           307ms sssd.service
           285ms akmods.service
           192ms libvirtd.service
           164ms udisks2.service
           136ms chronyd.service
           136ms auditd.service
           125ms dracut-pre-pivot.service
           110ms user@1000.service
           100ms user@42.service
            96ms packagekit.service
            96ms lvm2-pvscan@8:33.service
            96ms gssproxy.service
            96ms systemd-vconsole-setup.service
            94ms lvm2-pvscan@8:3.service
            86ms systemd-journal-flush.service
            79ms ModemManager.service
            78ms abrtd.service
            78ms systemd-udevd.service
            78ms avahi-daemon.service
            76ms rtkit-daemon.service
            73ms systemd-udev-trigger.service
            67ms upower.service
            62ms dracut-cmdline.service
            47ms initrd-parse-etc.service
            47ms systemd-tmpfiles-setup-dev.service
            42ms polkit.service
            41ms systemd-tmpfiles-setup.service
            40ms cups.service
            36ms NetworkManager.service
            33ms var-lib-nfs-rpc_pipefs.mount
            33ms fedora-readonly.service
            28ms fedora-import-state.service
            28ms systemd-fsck@dev-disk-by\x2duuid-6d4fe513\x2deae1\x2d4740\x2d8c
            28ms systemd-binfmt.service
            25ms gdm.service
            23ms systemd-fsck@dev-disk-by\x2duuid-21C4\x2d1573.service
            23ms geoclue.service
            19ms colord.service
            18ms realmd.service
            17ms proc-sys-fs-binfmt_misc.mount
            17ms boot-efi.mount
            17ms systemd-sysctl.service
            16ms systemd-journald.service
            16ms systemd-fsck-root.service
            16ms dracut-pre-udev.service
            15ms accounts-daemon.service
            15ms systemd-fsck@dev-mapper-fedora\x2dhome.service
            15ms plymouth-start.service
            14ms plymouth-read-write.service
            14ms systemd-logind.service
            14ms home.mount
            14ms dev-mapper-fedora\x2dswap.swap
            13ms sys-kernel-debug.mount
            13ms wpa_supplicant.service
            13ms kmod-static-nodes.service
            12ms plymouth-switch-root.service
            11ms dev-hugepages.mount
            10ms dev-mqueue.mount
             9ms systemd-update-utmp-runlevel.service
             9ms systemd-update-utmp.service
             9ms systemd-remount-fs.service
             8ms switcheroo-control.service
             8ms sysroot.mount
             7ms boot.mount
             7ms systemd-user-sessions.service
             7ms nfs-config.service
             6ms rpc-statd-notify.service
             6ms initrd-cleanup.service
             6ms tmp.mount
             4ms sys-fs-fuse-connections.mount
             4ms systemd-random-seed.service
             3ms initrd-udevadm-cleanup-db.service
             1ms dracut-shutdown.service
             1ms sys-kernel-config.mount
J'ajoute qu'à l'extinction de la machine (pour le reboot après installation des pilotes), j'ai vu une ligne parlant de "Kernel" mais trop rapidement pour savoir ce qui allait derrière. C'est quelque chose que je peux retrouver grâce à une commande du type journalctl ? J'ai testé, mais j'avoue ne pas avoir le niveau pour comprendre la moitié de ce qui s'affiche.
Edouard_le_homard wrote:Lance un akmods en root pourverifier si le pilote a bien été compilé
J'ai testé et en voici la réponse :
[root@localhost guillaume]# akmods
Checking kmods exist for 4.14.14-300.fc27.x86_64           [  OK  ]
Et le pilote en question est celui-ci :
[root@localhost guillaume]# dnf info akmod-nvidia
Dernière vérification de l’expiration des métadonnées effectuée il y a 0:26:36 le sam. 27 janv. 2018 20:42:41 CET.
Paquets installés
Nom          : akmod-nvidia
Époque       : 2
Version      : 387.34
Révision     : 1.fc27
Architecture : x86_64
Taille       : 61 k
Source       : nvidia-kmod-387.34-1.fc27.src.rpm
Dépôt        : @System
Depuis le dé : rpmfusion-nonfree-updates
Résumé       : Akmod package for nvidia kernel module(s)
URL          : http://www.nvidia.com/
Licence      : Redistributable, no modification permitted
Description  : This package provides the akmod package for the nvidia kernel
             : modules.
D'après la fiche de description du pilote, mon GPU est pris en charge.
Si ça peut faire avancer le schmilblick, je me suis rendu compte que l'installation des pilotes proprio via RPMFusion ne me donne pas accès à nvidia-settings. Le soft est installé, mais n'apparait pas dans le menu des applications et je ne peux pas le lancer en ligne de commande.
[root@localhost guillaume]# dnf install nvidia-settings
Dernière vérification de l’expiration des métadonnées effectuée il y a 0:32:23 le sam. 27 janv. 2018 20:42:41 CET.
Le paquet nvidia-settings-387.34-1.fc27.x86_64 est déjà installé, ignorer
Dépendances résolues.
Rien à faire.
Terminé !
[root@localhost guillaume]# nvidia-settings
No protocol specified

** (nvidia-settings:3479): WARNING **: Could not open X display

ERROR: Unable to find display on any available system
Et sur mon compte utilisateur :
[guillaume@localhost ~]$ nvidia-settings

ERROR: Unable to find display on any available system
C'est embêtant, parce que mon moniteur est bien là ! (bon, c'est une vieille TV HDReady, mais elle fait le taf !)

A noter que nvidia-settings fonctionne avec les pilotes Negativo.
Je seche la... Tu utilises bien Xorg et pas Wayland ?

Au moins tu as une solution de repli avec negativo
Edouard_le_homard wrote:Je seche la... Tu utilises bien Xorg et pas Wayland ?

Au moins tu as une solution de reppli avec negativo
Pas habitué à Wayland, ta question m'a intrigué et j'ai donc cherché une solution de ce côté, ce que j'ai trouvé !

En m'intéressant à la documentation des pilotes proprio NVIDIA sur RPMFusion, il se trouve qu'il est noté qu'il faut une version particulière de Mutter pour obtenir une compatibilité EGLstream sous Wayland, les quelques lignes qui suivent m'ont du coup permis de lancer une session Gnome/Wayland de manière pleinement fonctionnelle, même si nvidia-setting refuse toujours de montrer le bout de son nez.
dnf copr enable mati865/mutter-eglstream
dnf --disablerepo="*" --enablerepo="mati865-mutter-eglstream" reinstall mutter
Maintenant je me pose cependant la question de ce qui va arriver à la prochaine mise à jour de Mutter ? Faudra-t-il que je garde sous le coude ces lignes pour réitérer la chose au besoin ? Je vais réactiver mes autres repositories pour la suite, en espérant que ce bidouillage sur repo copr ne me foute pas trop le bordel sur la machine !