Reprise du message précédent :
https://forum.manjaro.org/t/please- [...] ault/17323
 
sinon je suis tombé sur ce post pour le decodage video via gpu

Petite faille de sécu un peu fun ^^
 
https://www.youtube.com/watch?v=h-E0tFvXmJE

D'où l'intérêt de ne pas utiliser Unity / GDM.  
KDE Neon est basé sur Ubuntu 20.04 LTS .... mais avec KDE Plasma / SDDM

Ah parce qu'une faille de sécurité est un intérêt pour ne pas utiliser ?

Si on suit ton raisonnement, on ne devrait plus utiliser ce qui se base sur gdm ?
Ça arrive, ça arrivera encore. L'important étant que ça soit patché.
Ça semble facilement exécutable à priori, mais ça implique tout de même un accès physique à la machine avec une session limitée.

Agressif !? (on va dire que c'est à cause du confinement)
 
A la lecture de ton post, on comprend surtout que tu n'as pas capté le message.
La faille n'est qu'un argument supplémentaire pour dire que GDM n'est pas la panacée, ni même le DE de base Ubuntu.
En utilisant des équivalents moins alambiqués et plus stables, ben, on est moins emmerdés.

 
c'est bizarre c'est corrigé depuis un moment. ISO ou pas mis à jour ?

Pas présent sous Fedora ou une Arch avec GDM+Gnome 3.38?

Non aucune agressivité mais je trouve juste réducteur de dire qu'il ne faut pas utiliser gdm pour une faille.

En effet sous fedora la faille n'est pas présente a priori car il semble qu'elle soit due à du code propre a Ubuntu, qui gère le wizard de création de compte de mémoire.

Ce qu'il faut retenir surtout c'est le non-respect de l'esprit Unix opéré par Canonical. Ils contournent des fondamentaux pour nous faire du microsoft-like ... c'est pas bien
 
De base, c'est moyen moins et si en plus ils introduisent des failles de sécurité, à quoi bon continuer de donner du crédit à des détournements techniques.

Bon je me demande ce qui a été poussé comme maj sur la 18.04, mais j'ai des coupures wifi récurrentes. (que je n'ai pas sous windows sur le même pc au même endroit heureusement)
 
Je ne sais pas si c'est la maj kernel qui est passée récemment. Mais c'est vraiment affreux.  
Il faut que je regarde les logs...

Contourner des fondamentaux c'est a dire ?

Unix est construit autour du principe de sécurité UID/GID.

Windows est une application graphique dans laquelle la notion d'utilisateur et de droit n'existait pas. Par la suite, la sécurité Windows a été construite par rapport à l'existant (en gros, montée à la truelle afin de ne pas trop bouleverser les habitudes des clients).

Pour Canonical, ils laissent des outils d'installation (non sécurisés qui plus est) sur une distrib' déployée. Nan, ça ce n'est pas possible. Tu utilises l'outil lors du déploiement, point. Surtout tu ne le laisses pas en place alors qu'il est sensible à des bidouilles de script-kiddies. Donc, le D.E. de base, je ne recommande pas, GDM, je ne recommande pas non plus.

Tu confondrais pas Windows « tout court » (3.x, 9x/ME, qui n’était qu’une simple surcouche à MS-DOS et se prenant elle-même pour un OS) avec Windows NT (OS complet dérivé d’OS/2 et conçu dès le départ sur un modèle multi-utilisateurs avec gestion des droits d’accès), les deux n’ayant aucun lien de parenté direct ?

OS/2 vient d'IBM essentiellement, NT est basé sur un noyau Unix qui a été refaçonné pour tendre vers OpenVMS car l'auteur de NT n'est autre que le concepteur de VMS (on y retrouve les « rights identifiers » et une partie des « system services »).
Ensuite, faut regarder l'histoire. A la sortie de NT4, les « DOS men » ont dégagé l'auteur original et joyeusement dénaturé la structure du noyau pour y intégrer, entre autres, les primitives graphiques. Bref, toute la gestion de droits s'est pris le parpaing de la vision des « DOS men ». Au passage, toute la valeur ajoutée apporté à la base Unix du noyau a été mise de côté. A l'époque, Microsoft a démontré une fois de plus que l'intérêt des clients passe en dernier.
 
Autant tout était logique sur la gestion de droits de NT3.51 (dernière version livrée par l'auteur originel) même avec une interface Win 3.x (que j'ai manipulé sur station Alpha), autant j'avais l'impression d'être revenu à Windows for Workgroups avec NT4.  
 
Pour l'anecdote, il y a eu des RC de Windows 2000 sous Alpha (AXP). Je serais bien tenté de tester la chose.

 
Je remonte ce soucis, j'ai réinstallé mon système récemment en 20.10, j'ai reconfiguré tout correctement, j'ai le umask 022 dans .profile dans ma ~/ ... Mais à un moment ou un autre, il oublie toujours mon "umask 022".
 
Quelqu'un aurait une explication ? J'ai probablement oublié quelque chose ou fauté quelque part ... Mais j'aimerais bien savoir où (non, pas là) chercher, pour éventuellement remonter le bug s'il y a un bug.
 
Le problème de ce genre de trucs, c'est que les tutoriels ou les pages parlant des umask sont rarement très à jour, donc,je ne trouve pas d'explication cohérente avec mon soucis.

Regarde aussi dans /etc/login.defs (il y a des commentaires explicatifs dedans sur comment ça marche).

Je n'y avais pas touché et c'est pourtant noté "UMASK 022".

C'est peut être pam ?
 

Hello    
 
Je re-teste actuellement Ubuntu en tant qu'OS desktop ( après plusieurs années écoulées depuis ma dernière tentative ), et ... je rencontres toujours pas mal de problèmes  
 

• le power saving pour l'écran est activé après 5mins : seulement, une fois en power saving, impossible de le sortir de cet état ( l'écran détecte un signal, rebascule en no-signal, et ainsi de suite en boucle ) sans faire un hard reboot

• j'utilise un écran 32" UHD, avec le fractional scaling à 150% : problème, plusieurs applis n'y entrave rien et ont des UIs complètement délirantes ( vbox perds les pédales avec la résolution des guest OS, steam est illisible ... )    

• je sors en SPDIF vers un DAC externe pour l'audio : celui-ci dispose de relais qui se déclenchent lorsque le sampling rate doit être adapté ( par ex si la source passe de 48khz/16bits à 96khz/24bits etc. ), et à CHAQUE notification sonore, video, piste son, le DAC change de sampling rate ... infernal   N'y a-t-il pas moyen de figer le sampling rate ? ( comme sous Windows )

NB : Je dispose des derniers pilotes Nvidia officiels
 
Voici quelque uns des problèmes rencontrés ( problèmes que je n'ai jamais eu sous Win7 ou Win10 avec la même config ), si quelqu'un a des pistes pour résoudre ceux-ci, je suis preneur
 
   

Ubuntu de base ? (Unity / Gnome shell) ... si oui, essaie KDE Plasma (de préférence avec la distrib' KDE Neon). La gestion écran y est bien contrôlable.  
Pilotes nVidia officiels ? ... Essaie une Radeon, c'est plus stable et il n'y a pas besoin de pilotes propriétaires.  

 
Il s'agit d'Ubuntu avec Gnome shell ( je n'aime pas KDE   )
 
( concernant les pilotes utilisés, je l'ai indiqué dans le post )
 
Tu mentionnes un problèmes de stabilité de pilotes, mais ... quel problème listé dans mon post serait lié à une instabilité ?  

Le combo gnome shell / nVidia.  
Ça fonctionne chez beaucoup de gens, mais, pour peu tu es des besoins moins communs, le combo se fera un malin plaisir de ne pas y répondre.  
 
Le plus simple est de « casser » le combo

Pour ce qui est de la partie audio, tu utilises pulseaudio ?
 
Parce que de mémoire, il y a possibilité d'indiquer au démon pulseaudio le sampling rate, et de l'empêcher de resampler ou pas les échantillons des différents clients qui passent par lui pour sortir un son

Essaie Fedora sinon ?

Pour ton ecran qui se rallume pas après la mise en veille, t'as pas une option "Deep sleep" qqchose dans les menus de config de celui-ci ?
 
Si oui, desactive là pour voir

 
Je vais regarder à cela, je ne connais pas du tout pulseaudio ( je n'ai rien trouvé dans les settings GUI, j'imagine qu'il faudra que j'aille éditer la conf du daemon à la mano )
 

 
J'ai essayé, mais ça ne change rien : si je désactive le sleep de l'écran, il reste sous tension mais je vois tout de même toujours un "no signal" tout du long
 
En gros en dirait que lorsque le système coupe le signal de l'affichage ( après que le timeout de 5 mins pour le power saving soit écoulé ), il n'y a plus aucun moyen d'avoir un signal de la part du GPU, à part en passant par un reboot ... ( je suis en HDMI mais je ne pense pas que ça change grand chose )
 
 
 
 
 

C'est le genre de problème courant avec les pilotes nvidia me semble ça, surtout après une mise en veille des pc.

A priori, oui, il faut passer par le fichier daemon.conf ( ~/.config/pulse/daemon.conf plus exactement, chez moi )
tu vérifies le sample rate par défaut ( si pulseaudio doit resampler un échantillon, il le sera à ce sample rate par défaut avant d'être envoyé à la carte son/chipset son ) :

( 48 KHz chez moi par exemple )
 
Enfin, y'a ce paramètre qui indique à pulseaudio s'il doit éviter de resampler ou pas (y'a des conditions pour ça).
Chez moi, je préfère éviter le resampling qd c'est possible, donc j'ai cette ligne là :

 
Vu ton souci, je pense que tu choisiras 'no'
 
Attention
Tout ceci est valable en temps normal SAUF quand on configure Pulseaudio en mode 'Passthrough'
En gros, qd on lit un signal encodé en Dolby Digital (AC), DTS, etc ...
 
Si on a configuré Pulseaudio en mode 'Passthrough' (quand on a coché les cases AC, DTS, etc dans l'UI de config pulseaudio... la case PCM n'active pas le mode 'Passthrough' ),
tous les signaux encodés Dolby Digital, DTS, etc ... sont envoyés tel quel sans aucun resampling, à l'ampli/DAC branché derrière en SPDIF/HDMI
 
Pour mon info, c'est quel modèle ton DAC ?
 

Que donnent comme résultats ces lignes de commande ?
 

 
Dans mon cas j'ai 2 candidats pour le fichier de conf :  
 
- /etc/pulse/daemon.conf
- /snap/gnome-3-28-1804/145/etc/pulse/daemon.conf
 
( Je vais supposer que le 1er est celui de référence )
 
Je vais essayer de désactiver le resampling et voir ce que le DAC en pense   ( c'est un Schiit Bifrost 2 )
 
Concernant le passtrough / bitperfect pour les formats audio proprios, je ne l'utilise pas car je ne dispose pas de décodeur dédié
 
 

bizarre, on dirait que tu as plusieurs versions de pulseaudio installées

Sinon pour ton écran/cg Nvidia, jettes un oeil à cette page
https://strayobject.medium.com/fix- [...] eced577f0a

 
C'est l'installation de base et je n'ai pas touché à quoique ce soit lié à pulseaudio  
 
J'ai parcouru l'article lié à la sortie de veille de l'écran, mais la solution proposée me laisse perplexe : monitorer auth.log à la recherche d'un event unlocked login keyring ... je ne saisis pas le rapport avec l'écran qui passe en mode power save  

C'est surtout le

qui est intéressant, ça force la cg à se reconnecter à l'écran

Faut l'adapter à ton cas et remplacer DP-2 par la référence à ton écran, dans ton système

Pour trouver la liste des écrans connectés à ta cg

Ensuite tu pourrais binder ça (le xrandr -d etc ... ) sur une combinaison de touche pour réveiller l'écran
C'est pas parfait mais ça te permet de diminuer "la nuisance" en attendant que le bug soit résolu/de trouver une meilleure approche

Tu as bien dit que tu étais sous GNOME ?
 
Si oui, tu peux lancer la commande  
 

 
et en donner le résultat ?

 
voici :
 

Décommente (enlève le # quoi) la ligne, sauve le fichier, et redémarre ton système

Je viens de tester cela ... mais j'ai toujours le problème avec l'écran qui refuse de sortir de veille
 
J'ai remarqué que ce phénomène est également présent lorsque je mets tout le système en veille ( suspend ) : pas de signal au re-démarrage
 
NB : J'ai également testé la command xrandr ( avec la sortie HDMI-0, vu que c'est celle que j'utilise ), avec une exécution en boucle toutes les 60s afin de voir si ça permettait de récupérer l'affichage lorsque le screen power save se déclenche, mais ça ne fonctionne  pas ....
 
 
 

une solution radicale consisterait à supprimer le screen saver du système.
c'est ce que j'ai fait avec xfce

toujours pas de paquet Gtk4 dans les dépôts

D'ailleurs, en parlant de veille et de XFCE, c'est pourri depuis quelques versions non ?

Il ne détecte pas quand je regarde une vidéo dans le navigateur (Mozilla Firefox) ni quand je suis dans certains jeux vidéo ...
Du coup, j'ai tendance à me mettre en "Mode présentation" assez souvent pour éviter des problèmes.

ça n'a jamais fonctionné le mode présentation