Reprise du message précédent :

 
Hop, résolu en créant un fichier /etc/X11/xorg.conf.d/50-mouse-acceleration.conf dans lequel j'ai mis ça (profil d'accélération "flat" pour libinput) :
 

 
cf : https://wiki.archlinux.org/index.php/Mouse_acceleration

En voulant mettre à jour tout à l'heure j'ai eu ces messages :

 
C'est normal que xorg-server veuille remplacer les drivers vidéos ?  

pacman ne remplace rien la, il propose juste d'enlever.
Les pilotes ne sont peut etre plus compatibles avec xorg.
 

Ah oui, au temps pour moi.
Bon je vais les supprimer et espérer que ça ne me casse rien

C'est des pilotes de niche quand même, tu risques pas grand chose si t'as pas un setup trop exotique

Oui c'est même bizarre que tu avais tous ces pilotes d'installés ?

Il est prévoyant.

Je crois que j'ai fait des conneries à l'installation de mon arch, j'ai dû installer un groupe qui contenait tous les drivers au lieu d'en installer un seul  

j'ai eu aussi un :
 

 
est-ce que ça va poser un problème pour utiliser ensuite un joystick usb ?

J'ai eu le même warning hier, j'ai validé la suppression, et la je viens de tester avec une manette de Xbox 360 sans fil + adaptateur USB, ça marche sans problème avec DiRT Showdown

Non ce driver c'est pour émuler un pointeur (souris quoi ) par un joystick.
Ça n'a rien à voir avec le support des joysticks par les applications

Donc ce serait fini l'histoire du curseur qui se casse(en haut de l'écran) quand je branche mon pad? Ce serait bien même si je n'ai plus de jeux nécessitant un pad.

Oui, généralement installer le pilote joystick fait plus de dégâts que ça n'apporte de réelle utilité
N'installez pas ce truc

avez-vous remarqué des problèmes de déchirement d'images dans les vidéos depuis la mise à jour de xorg et/ou kde/plasma?

sur les vidéos je remarque de temps en temps une sorte de tearing que je n'avais pas il y a quelques jours

j'utilise le pilote libre radeon, avec une carte amd radeon HD4650

Discussions en cours (depuis un bon bout de temps maintenant) pour abandonner i686, mais là ça se concrétise
Ce qui a été le sujet d'un poisson d'avril ( ?) devient réalité 5 ou 6 ans plus tard
 
Préparez-vous au shitstorm, ça sera au moins de l'envergure de la révolte contre systemd    
 
good times en perspectives  

J'aurais préféré ajout d'avx au x64 pour rivaliser avec clear... la ca serait plus tendu

go gentoo

c'est un sale coup pour les vieux PC type portable du début des années 2000, pc d'entreprise qui sert pour des petites tâches bureautiques, tous ces PC à base d'athlon XP, pentium 4 ( souvent sous windows XP, et parfois sous linux ),

heureusement qu'il existe des distributions linux spécialisées pour les vieux PC ( avec bureau léger ), ceux là supporteront encore les CPU i686

Ca n'a rien d'un sale coup, tu pourras toujours compiler toi meme tes paquets x86, c'est juste que les mainteneurs officiels ne le feront plus.

A priori la plupart compilaient mais ne testaient pas les paquets x86 donc pas grand chose de perdu.

C'est l'occasion de fair comme pour Arch Linux Arm en gros.

Et pour Gentoo pas besoin, il y a deja clear et solus qui le font.

 
avec ce vieux PC i686 ? ( dans le cas où l'utilisateur n'aurait que des vieux PC chez lui )
 
c'est pas jouable de compiler façon gentoo si on a pas une machine de guerre, le plus simple reste d'utiliser une distribution où tout est déjà compilé,
 
donc cette décision d'écarter les i686 c'est une manière de dire "venez pas nous faire chier, envoyez à la benne votre PC dinosaure ou allez voir ailleurs"  

On sait pas encore trop comment ça va évoluer, ils vont probablement juste proposer les paquets "as-is" compilés automatiquement ou pas testés du tout.
On en saura plus bientôt.

A l'époque ou ton vieux PC est sorti, c'est que les mainteneur utilisaient pour compiler les paquets...

En fait tout est manuel la dedans, je croyais qu'il y avait des serveurs pour mais non, donc ca ne change pas grand chose (bon avant c'était un paquet par machine maintenant tu fais tout toi meme ).

Et je ne crois pas que ca soit aussi méchant que tu le vois, juste que pour des gens non payés, ils définissent leur priorité par rapport a eux et au 95% de la communauté restante (Arch aujourd'hui ne supporte pas les 486 non plus...), mais je pense qu'ils accepteront, si ca demande peu de travail, d'aider de nouveaux mainteneurs pour x86. Je dis cela car pas mal des devs sur la ML disent être pour laisser tomber x86, mais sans changer le système de compilation pour que seul x64 soit possible, afin de laisser cela ouvert à d'autres, ou à une future architecture post x64.

Pas testés c'est déjà la cas majoritairement.
Pour le côté automatique ca sera un problème quand il faudra un patch en x86 et pas en x64, ce qui ne rend pas la vie des devs tellement plus simple au final.

l'utilisateur lambda n'acceptera pas cet argument, pas la même patience qu'un mainteneur, sur un pentium 4 2.4 Ghz mono-core 512 Mo de ram ça prend vraiment des plombes pour compiler un noyau ou un gros logiciel type libreoffice, ça va pas le faire au quotidien de compiler à chaque mise à jour de logiciel,

et entretemps les logiciels ont pris de l'embonpoint entre 2003 et 2017, ça doit jouer sur le temps de compilation,

à mon avis la sanction sera simple : pas de paquets précompilés pour i686 = les utilisateurs de vieux PC vont devoir changer de distribution, peut-être un dérivée d'archlinux spécialisé pour les vieux PC

edit : peut-être archbang :

https://en.wikipedia.org/wiki/ArchBang

sinon il  y a lubuntu, puppy,

ça me concerne car j'ai un vieux portable de 2003 ( pentium 4 2.4 Ghz ) et j'ai pas envie de passer en mode gentoo

Tu veux dire compiler "le" noyau arch avec tous les drivers du monde ? Oui c'est sur
Je vois que le spectacle commence déjà ici    

Le temps gagné à la compile aura été perdu à fouiner dans les options du noyau.
En fait, il faudrait un script qui serait capable de configurer correctement les options du noyau.

Ca existe deja...

Je preconise Modprobed-db avec.

P'naise!
En plus, cela correspond à ce que je pensais.  
 
Edit:Après vérif, je me rends compte que c'est apparu plus ou moins à la période ou j'ai arrêté de faire des noyaux à ma sauce.  

localmodconfig nécessite tout de meme un utilisateur qui comprend un peu comment ca fonctionne, sinon il va vite avoir des surprises. (et hop plus possible de monter des ISO ou une manette qui ne connecte plus, etc).

Et puis même, dans la pratique c'est jamais parfait je trouve ces targets magiques.
On s'en sort bien mieux à la main je trouve.

On se revoit l'année prochaine, quand tu auras trouvé toutes les bonnes options

 
 
C'est pas parce qu'il y a beaucoup d'options que c'est difficile de n'activer que ce qui t'intéresse, surtout que tout est bien rangé dans le menuconfig.
Tu désactives les trucs inutiles (genre radio, réseaux exotiques, certaines marques de chipsets en sous-menus) et t'as déjà 90% des options que tu verras jamais de ta vie hein.
C'est vraiment très bas comme argument, et juste donner le nombre de lignes c'est simplement malhonnête (Surtout qu'il y a des commentaires et des lignes vides )
 
Je compile mes kernels sur ma debian à la main, je suis parti du git de linus 100% vide, je vois pas ce qui est insurmontable.  
Trial & error, en quelques essais tu as un truc qui marche
C'est pas forcément hyper intuitif mais loin d'être aussi infaisable que tu essaies de le faire croire.

Hey, touches pas a Keren, tu ne la connais pas comme moi

Comment sais tu ce qui est utile ou non sans tout regarder?
Bon c'est vrai que certaines options dependent d'autres donc l'arbre trie un peu pour toi.

Il n'y a rien de malhonnête, j'ai juste mis le résultat d'une commande, tu y lis ce que tu veux.

Je n'ai jamais dit que c'était insurmontab' ou infaisab'  

Ah et un second pour ne pas avoir compris que ce poste était du sous-entendu:

(le dernier c'est juste parce que jamais 2 sans 3, tu me comprends).

Et ben si tu le dis, je te la laisse hein puisque ça a l'air de te tenir à cœur.  
Chien mange pas chien.

Ben tu as des catégories entières de périphériques pour lesquels tu sais si tu les as ou pas... donc tu désactives tout d'un coup
 

Le comble de la malhonnêteté c'est quand même répondre à une accusation de mauvaise foi par un autre argument malhonnête
 

Si, tu as exactement sous-entendu ça "ça va prendre un an"
Le " " a bon dos comme toujours.

 
En même temps, il y a plus d'utilisateurs d'archlinux sur ARM que sur x86 32 bits. Quasiment tous les CPU depuis 12 ans sont compatibles x86_64...
 

 
Mouais, je pense pas, c'est facile de recompiler les dépots entièrement pour x86 si besoin, de la même façon qu'il y a des dépots arm non officiels...

J'ai l'impression que tu veux jouer avec mes sentiments.
J'espere que non, tu me comprends.

Et concrètement, on gagne quoi au final à part avoir un noyau de 800kO sur un DD de 1To?

 
En général, quand tu compiles ton noyau, c'est pour activer des options spéciales à la compilation. Ou alors pour faire un noyau aux petits oignons sur de l'embarqué.
Sinon c'est très formateur et intéressant

Tu gagnes du temps a la compilation, du temps quand le noyau est mis en mémoire et de la mémoire aussi. Le 1er étant le plus intéressant.

Apres comme dit BlockDevice, tu peux aussi choisir des options non-génériques pour ton materiel et ton usage, et optimiser un peu tout cela:

Par exemple:
CONFIG_PREEMPT_NONE ou CONFIG_PREEMPT_VOLUNTARY ou CONFIG_PREEMPT.

CONFIG_HZ_100 ou CONFIG_HZ_250 ou CONFIG_HZ_300 ou CONFIG_HZ_1000 (300 est par defaut sur Arch, mais il y a parfois des soucis avec sur du CPU Intel)

etc.

Sinon aucun rapport mais pour ceux que ca intéresse, on vient de me montrer une extension GNOME pour pacman qui peut vous paraître sympathique:

https://extensions.gnome.org/extens [...] indicator/

Octopi fait aussi bien. Bon, s'il n'y avait pas les conflits entre les différentes versions de qt-notifier.

Si je cherche octopi je tombe sur un truc pour imprimantes.
Es-tu sur du nom?