Reprise du message précédent :

C'est bizarre ça, dans mes souris Logitech sans fil la pile tient largement plus d'un an sans problème  
edit : d'ailleurs que ce soit avec ou sans fil, je ne jure que par Logitech... jamais déçu par cette marque : fiabilité au top

Nan la fiabilité de Logitech c'est du passé, et je dis cela en n'ayant eu que des souris Logitech en plus de 20 ans.

Quant à la longévité de la souris sans recharge, ca dépend de la souris et de la batterie d'accumulateurs dedans... Mon ancienne Logitech survivait des jours (je ne sais plus trop combien, mais c'etait bien long), mon actuel ne fait pas 2 jours, mais elle est bien plus légère et a une connection bien plus rapide...

rien compris, c'est revenu !
il y a une heure : pas de web en partie, ping 9.9.9.9 --> erreur (j'ai pensé au dns aussi, j'utilise quad9)
je vire les dns quad9, je redémarre, toujours pas de web, je boot sur windows 10 --> web ok
je redémarre sur Arch, web ok, je remets les DNS quad9, c'est ok ...
 
Une histoire de cache peut-être.
 

Je n'ai que des modèles basiques, par exemple la M175.
Pour l'instant, aucun souci... je touche du bois !
J'utilise une filaire pour mon PC fixe mais pour le PC portable c'est du sans fil.
edit : et pour recentrer sur Archlinux, ça fonctionne Out of the Box, il n'y a rien à configurer.

Si ton téléphone n'est pas sur le même réseau c'est peut-être ton fournisseur de DNS qui foirait, ou un soucis de cache en effet.

Marrant je faisais l'inverse, avec fil pour portable, et sans fil pour fixe
Et comme je n'ai plus de portable bah que du sans fil maintenant.

J'ai surtout l'impression que les souris (avec ou sans-fils) haut de gamme ont toute leur ergonomie basée sur l'installation d'un logiciel windows pour gérer les paramètres.
Nous on peut se gratter
Donc faut faire attention à ça aussi...
 
Perso j'ai du zowie en ce moment, et la philo est assez sympa, en gros c'est justement pensé pour ne pas dépendre de soft, les réglages se font direct sur la souris ou en maintenant des boutons pendant le branchement. Mais j'ai pas le haut de gamme j'ai une bête FK1.
 
Mais par contre zowie c'est pas mal sur-côté niveau prix...

Avec piper je peux régler tout ce que je veux sur ma G900.
Par contre ca ne vient pas de logitech (ni libratbag bien sur)...

 
Mon PC portable bouge pas mal dans ma maison, donc rapidement j'en ai eu marre de trébucher dans le fil de la souris  

Ah forcement

 
Ma souris sans fil -> 9.99 €  
Ma souris avec fil -> gratos  

Oui enfin y a quand même un niveau de performance et de qualité à prendre en compte. Si t'as pas des besoins spécifiques c'est sur que c'est plus simple.

Oui moi c'est pas pour mon boulot  

Ma souris sans fil est bien une Logitech, mais je serais bien incapable de te dire de quel modèle il s’agit (pas marqué dessus, et Logitech lui-même a oublié son existence dans sa liste)…
 
Cela dit, je venais pas pour ça, mais pour dire qu’en regardant la dernière vidéo (de l’année) de Fred, j’ai eu l’agréable surprise de voir que les nouvelles dispositions de claviers AZERTY et BÉPO normalisées par l’AFNOR sont enfin disponibles sur Arch Linux, en plus des autres !
Bon, je sais pas ce qu’il en est des autres distributions, mais ce sera sûrement intégré dans leurs prochaines versions, au pire.

Il y a un risque d'obsolescence programmée si la batterie n'est pas remplaçable (batterie soudée) ou qu'elle n'est plus disponible sur le commerce, ou pire : batterie vendue plus cher qu'une souris neuve avec batterie  .

Un format de pile rechargeable (LR06, LR03) est préférable, ça donnera de la valeur à la souris lors de la revente ou si on veut la filer à quelqu'un de sa famille.

Pour en revenir au problème de mise en veille de la souris usb sans fil, j'ai approfondi  .

Le problème vient de powertop qui est trop agressif avec les ports usb, mais je le préfère à tlp que j'ai essayé et qui n'est pas aussi performant. Avec powertop le portable consomme souvent moins de 10w et le ventilateur ne se met pas en route, tandis qu'avec tlp c'était pas loin de 20w et le ventilo tourne souvent (avec un cpu i7, 45w).

Hier j'ai blacklisté la souris comme indiqué dans le wiki pour qu'elle ne soit pas concernée par la veille, mais cela ne survit pas au boot, ne me demandez pas pourquoi, mais je l'ai lu plusieurs fois.

Manuellement on peut forcer powertop à ne pas s'occuper de la souris, il suffit de lancer la commande "sudo powertop" d'aller dans l'onglet [Tunables] et de valider pour changer le statut pour la souris :

et on voit quel est le fichier concerné : /sys/bus/usb/devices/1-3/power/control dont le texte passe de "auto" à "on"

Donc a priori la solution est de lancer un script au démarrage : voir ici
comme je ne maitrise pas les scripts j'ai copié :

ensuite il faut donner les droits sur ce fichier pour le lancer au démarrage (j'ai découvert le truc) :

et ajouter à la fin

"toto  ALL=(ALL) NOPASSWD: /home/toto/bin/powertop-fix.sh"

Puis je vais dans les paramètres de plasma, pour ajouter le lancement du script au démarrage.

Voilà, j’arrête, je redémarrai demain et je vous dirai si cela fonctionne, mais si vous voyez un truc n'hésitez pas à me le dire.

Je connais pas plasma, mais à priori, configuré comme ça, je dirais que ça marchera pas, car tu sembles exécuter /home/toto/bin/powertop-fix.sh en tant que simple utilisateur dans ton outil de config graphique.
Il faudrait pas plutôt que tu mettes

comme commande ?

 Cette faille
toto a donc tous les pouvoirs : il a un droit d'execution sans mdp d'un fichier qu'il controle. Dans /home/toto/bin/powertop-fix.sh il remplace le contenu par "exec bash" et le voilà root sur la machine sans avoir rentré de mdp.
C'est trèèèèès sale.
 
Tu le fais où ton powertop --auto-tune ? Mets juste ta desactivation de l'autosuspend juste après cet appel.
Et puisque ce sera vraisemblablement executé en root par le système, le fichier n'a pas de raison de rester chez un user, sinon on en revient à la même faille qu'avec sudo.

Tu veux pas plutôt dire que ça vaut minimum un aller simple pour La Haye, un truc pareil ?  

Ce qu'il est possible de faire pour remédier à ça (sans changer la procédure avec le script), c'est de ne mettre dans /etc/sudoers que la ligne suivante :

Puis de modifier le script ainsi :

Et comme ça, tu n'as plus besoin de rajouter un sudo dans ta commande à lancer au démarrage de la session, et seule l'écriture dans le fichier système utilise les droits root.

Honnêtement pour ce genre de chose je ne vois pas l'intérêt de ne pas en faire un script root mais bon.

Clair, un service c'est quand même nettement plus propre

Pour les boutons un peu exotiques qui sont mal pris en charge c'est possible d'arriver à les configurer avec xbindkeys par exemple.  
Après wai c'est clairement pas aussi clé en main qu'installer l'app Logitech sur Windows (de 400mo    et qui fera sans doute un peu de telemetrie/pistage au passage comme tout le monde )
 
 
Ex d'une conf pour la MX Anywhere 2 :

+1, à la base il s'agit de corriger le comportement d'un périphérique indépendamment de l'utilisateur, donc ça devrait être fait en amont des sessions utilisateur.
Mais bon voilà, disons qu'on peut colmater pas trop mal avec un usage plus fin de /etc/sudoers.

merci de se pencher sur mes petits problemes de souris la nuit !
 

Ok, je comprends c'est risqué en effet et ce n'est pas une méthode élégante.
 
Powertop est un service qui est lancé au démarrage, que j'ai activé avec la commande "sudo systemctl enable powertop.service",
... mais je n'ai pas compris comment passer des paramètres au démarrage, je n'ai même pas compris si cela est possible.
Dans les posts de forum pour un problème similaire au mien je n'ai rien vu dans ce sens, mais je regarde peut-être des posts trop anciens ou des posts de gents aussi noob que moi.
 

et comment tu le lancerai ce script root ?
 
Ça me semblait une bonne idée de modifier juste le petit fichier qui concerne la souris, vu qu'en manuel c'est juste ce qu'il me faut, mais pas tant que ça finalement. De plus, je n'ai pas le résultat attendu : Au démarrage la souris n'a plus l'optimisation, mais il y en a 5 ou 6 autres aussi...    
 

 
Bref, retour à la case départ, je suis largué.
Je vais commencer par enlever ce que j'ai fait hier que je n'avais pas supprimé, puis j'essayerai le script de Kajoux.
 
Il y a peut-être une piste du côté des paramètres de démarrage dans le fichier /etc/systemd/system/powertop.service, comme indiqué dans le wiki powertop, mais je n'ai rien vu dans ce sens.
 
En tout cas merci, c'est instructif !
 

 
Avec un service systemd dédié.
 
Après si tu peux envoyer des paramètres a powertop pour ton soucis, il serait mieux d'utiliser un service override je pense.

Ce service n'existe pas dans le package, tu l'as créé, surement en suivant l'exemple du wiki.
Si t'as suivi ça, IMO le mieux c'est de modifier Le ExecStart :

(Par contre je pense que niveau commande il y a plus pérenne que ceci, qui est hardcodé sur 1-3 et un jour qui risquerait de changer)
Doit y avoir plus propre niveau systemd en jouant avec Type et ExecPost, mais bon je connais pas assez bien.

À priori tu devrais obtenir le même résultat : ce que j'ai proposé est juste un colmatage de la faille dans /etc/sudoers, ça ne change rien au plan fonctionnel.

ExecStartPost me parait plus propre dans ce cas.

Problème de conf je penses sur TLP, je consomme 5.4W sur batterie avec un T480s + undervolt -125mv

A voir si on a la même config, je pense que la mienne est plus grosse  , déjà rien qu'en diagonale.
 
Je n'ai pas trop insister sur tlp, certainement à tort, j'y reviendrai si powertop continu à ne pas faire ce que je veux !

Je ne comprends pas tout  

ça ne fonctionne pas, je vérifiai plus tard si j'ai bien tout fait.
 
A l'année prochaine et encore merci    
 
 

Est-ce que vous arrivez à compiler le paquet "flightgear" disponible sur aur ? (sachant qu'il faut d'abord installer le paquet simgear et ses dépendances comme openscenegraph) :

https://aur.archlinux.org/packages/flightgear/

chez moi ça plante dès le début avec cette erreur de cmake :

j'ai ouvert un rapport de bug sur le site de flightgear, mais j'aimerai être certain que le problème est reproduisible chez tous les utilisateurs d'archlinux,

un moyen de contournement est de créer un lien symbolique "/include" pointant vers "/usr/include".

 
perso, je lance pas powertop autotune, c'est trop risqué suivant la machine (cf ton problème de souris), je préfère activer les options une par une via un fichier tmpfile.d ou via les options des modules :

 
C'est un peu plus fastidieux mais tu as le contrôle précis de ce que tu fais. J'avais écrit un truc sur le sujet :
 
http://mjules.littleboboy.net/carn [...] %A9marrage

Pas mal ton petit billet  

J'utilise pas mal de drones (ardupilot principalement) dans mon metier aujourd'hui, je l'utilise et il compile sans soucis. Pas besoin du symlink

je vais aller lire ton billet.

J'ai enlevé powertop pour mettre tlp, j'ai tout fait proprement, mais c'est exactement comme la première fois où j'avais essayé, la consommation reste élevée et le ventilo tourne constamment, tlp ou rien c'est quasi pareil chez moi. Donc retour avec powertop, va falloir que ça fonctionne

 
c'est bizarre, tu as compilé de quelle manière ?
 
en utilisant makepkg dans un environnement chroot ou dans un environnement normal ?
 
quelle version du paquet simgear utilises-tu ?

Je viens d'essayer de le compiler normalement (en lançant depuis yay et en utilisant le paquet 2019.1.1-1), et aucun souci ...

évite d'utiliser "yay" (ou tout autre surcouche de type yahourt), télécharge à la main le PKGBUILD, et tapes "makepkg -c" (avec ton compte classique, pas de sudo ou d'utilisateur root), perso je n'ai pas utilisé ces surcouches.

Après débogage j'ai peut-être trouvé l'explication :

dans le fichier /usr/lib/cmake/SimGear/SimGearTargets.cmake je remarque à la ligne 66 la présence du chemin "/include" :

si je supprime cette mention "/include" alors tout est ok, je peux compiler,

donc pour ceux qui arrivent à compiler : pouvez-vous me donner le contenu de votre fichier /usr/lib/cmake/SimGear/SimGearTargets.cmake ?
c'est pour savoir si à la ligne 66 vous avez la mention ";/include;" ou pas.

Le passage qui provoque l'erreur :

après correction en supprimant le "/include" :

ce fichier est généré par code lors de la création du paquet simgear (version  2019.1), bizarrement sur ma config ça me rajoute ce répertoire "/include" qui n'existe pas sur mon disque, d'où l'erreur,

le patch :

J'ai utilisé yay également mais je viens de refaire avec makepkg pas de soucis ... Franchement ça change rien, je me demande même pourquoi je l'ai fait ;-)
 
$ pacman -Q simgear
simgear 2019.1.1-3
 
et j'ai bien ça sans rien faire :
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;/usr/include"