# [KERNEL] Plus de souris sur 2.6.19-r1

## lmarcini

Bonjour à tous,

Suite au passage au kernel 2.6.19-r1 (avec make oldconfig de mon 2.6.18-r3 et utilisation de PATA/SATA), j'ai perdu ma bête souris PS/2. Celle-ci reste immobile, autant en console avec gpm que sous X... Je précise que j'ai une CM Asus A7V880 avec un chipset Via 880...

Quelqu'un a-t-il eu ce genre de "blague" ?

----------

## loopx

Lol, pas cool, t'as pas été voir si les chipset ne se serait pas décoché (genre, changement d'endroit de certaine config du kernel ...) ??

Bon, j'aurais essayé ...

----------

## titoucha

Je vois que la configuration du noyau qui c'est mal passé, il ne te reste plus qu'à tout vérifier.

----------

## lmarcini

Après moult vérifications, je ne vois pas ce qui cloche...

----------

## Enlight

zgrep -i ps2 /proc/config.gz dit quoi?

----------

## lmarcini

Ca me donne ceci :

CONFIG_MOUSE_PS2=y

CONFIG_SERIO_PCIPS2=y

CONFIG_SERIO_LIBPS2=y

----------

## Enlight

Mmh étrange, pour ma part j'ai le premier et le dernier et tout marche. Tu as tenté le cat /dev/input/mice? d'ailleurs ton xorg.conf utilise bien /dev/input/mice et non encore /dev/psaux ?

----------

## lmarcini

Le cat /dev/input/mice patine dans la semoule : ça ne donne rien ! Par contre, j'ai ceci dans /dev/input/ :

3063 0 drwxr-xr-x  3 root root    100 dec  9 17:29 .

1350 0 drwxr-xr-x 15 root root  14040 dec  9 17:30 ..

3571 0 drwxr-xr-x  2 root root     60 dec  9 17:29 by-path

3570 0 crw-------  1 root root 13, 64 dec  9 17:29 event0

3064 0 crw-r--r--  1 root root 13, 63 dec  9 17:29 mice

----------

## lmarcini

Je reviens à la charge : un upgrade du bios n'a pas résolu mon problème, de même qu'un changement de souris... Même les incantations n'ont rien donnée. Et je ne parle pas des diverses menaces ou insultes...

----------

## darkangel92

j'ai eut le meme pb que toi rt je suis reste au 2.6.18-r3

----------

## billiob

Désolé, si ça ne sert à rien, mais je n'ai pas pu m'en empêcher : 

 *Linus Torvalds wrote:*   

> It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways.

 

Qui pourrait se traduire comme ceci:

 *Jean-Philippe de linuxfr.org wrote:*   

> C'est un des ces rares noyaux "parfaits". Donc, si vous n'arrivez pas à compiler avec votre config (ou si cela compile, mais ensuite donne lieu à des actes ["non énoncables"] de perversion avec votre teckel), vous pouvez [facilement ?] savoir que c'est entièrement votre faute, et que vous devriez juste corriger vos comportements diabliques.

 

----------

## lmarcini

Bon, je ne suis pas un cas isolé alors (je ne parle pas du teckel, bien entendu !)...   :Twisted Evil: 

P.S. : comme beaucoup de membres éminents de ce forum, j'ai un chat !

----------

## Enlight

Moi vu le event 0 je sentirais bien un conflit entre evdev et le driver classique pour les ps2.

----------

## lmarcini

Il faut enlever le driver PS/2 du noyau alors ? Nota : bien que j'utilise un noyau monolithique, j'ai essayé avec le driver en module mais avec le même résultat...

----------

## Enlight

 *lmarcini wrote:*   

> Il faut enlever le driver PS/2 du noyau alors ? Nota : bien que j'utilise un noyau monolithique, j'ai essayé avec le driver en module mais avec le même résultat...

 

Ben pour ma part je n'utilise pas evdev, mais regarde si input0 est son device, essaye de le cater si c'est bien lui comme avec /dev/input/mice, puis si c'est bon ajuste juste ton xorg.conf

edit : note que le post d'avant  c'était du feeling hein, la seule idée qui me passait par la tête. Pour en savoir plus sur evdev, je crois qu'il y'a un how-to dessus.

----------

## lmarcini

Le truc bizarre, c'est que gpm ne fonctionne plus non plus...

----------

## Enlight

 *lmarcini wrote:*   

> Le truc bizarre, c'est que gpm ne fonctionne plus non plus...

 

Ah parcequ'avant si???? alors que cat /dev/input/mice ne marchait pas ???   :Shocked: 

----------

## lmarcini

Avant, c'était un kernel 2.6.18-r3...

----------

## blasserre

 *Jean-Philippe de linuxfr.org wrote:*   

> C'est un des ces rares noyaux "parfaits". Donc, si vous n'arrivez pas à compiler avec votre config (ou si cela compile, mais ensuite donne lieu à des actes ["non énoncables"] de perversion avec votre teckel), vous pouvez [facilement ?] savoir que c'est entièrement votre faute, et que vous devriez juste corriger vos comportements diabliques.

 

moi je vote pour que le staff kernel recommence à sortir des noyaux pourris   :Confused: 

----------

## kwenspc

idem que blasserre.

moi carrément dans le make menuconfig du 2.6.19, la touche "echap" n'est plus prise en compte. olbigé de jouer avec le bouton "exit". Et la compile à erdé alors que c'est le même .config que mon 2.6.18 d'avant. 

Je suis revenu au 2.6.18. f$#k le 2.6.19

----------

## Enlight

 *kwenspc wrote:*   

> idem que blasserre.
> 
> moi carrément dans le make menuconfig du 2.6.19, la touche "echap" n'est plus prise en compte. olbigé de jouer avec le bouton "exit". Et la compile à erdé alors que c'est le même .config que mon 2.6.18 d'avant. 
> 
> Je suis revenu au 2.6.18. f$#k le 2.6.19

 

oui pour ecape ça m'a fait un choc aussi. Sinon une fois le noyau patché pour éviter le m'éga crash ipv6 tout à l'air de marcher, j'ai juste un soupçon quand à du deadcode dans xfs qui pourrirait les writes (enfin ralentirait quoi) mais à vérifier.

----------

## kwenspc

 *Enlight wrote:*   

>  *kwenspc wrote:*   idem que blasserre.
> 
> moi carrément dans le make menuconfig du 2.6.19, la touche "echap" n'est plus prise en compte. olbigé de jouer avec le bouton "exit". Et la compile à erdé alors que c'est le même .config que mon 2.6.18 d'avant. 
> 
> Je suis revenu au 2.6.18. f$#k le 2.6.19 
> ...

 

hum... vu que je suis sous XFS on va éviter le 2.6.19 donc   :Wink: 

Attendons le 2.6.20!

----------

## Enlight

en fait je sais pas si le bottleneck vient du fait de faire tar -xvjpf /une_partition_d_un_fs_donné/fichier.tar.bz2 -C /autre_partition_avec_le_même_fs ou si c'est un problème lié juste à xfs et au 2.6.19. Donc si quelqu'un ouvait vérifier l'une ou l'autre hyppothèse, je ne reverrais pas mon pc avant ce WE au mieux :/

----------

## lmarcini

Il y a un patch de disponible sur https://bugs.gentoo.org/show_bug.cgi?id=157493 pour corriger les problèmes de souris PS/2. Je teste ce soir...

----------

## Dominique_71

J'ai eu un problème similaire en passant d'un 2.6.16-rt29 à un 2.6.19-rt11. X refusait de se lancer et se plaignait qu'il ne trouvait pas la souris. J'ai résolu ceci en changeant "/dev/input/event1" en "/dev/input/event2" dans /etc/xorg.conf.

----------

## truc

 *Dominique_71 wrote:*   

> J'ai eu un problème similaire en passant d'un 2.6.16-rt29 à un 2.6.19-rt11. X refusait de se lancer et se plaignait qu'il ne trouvait pas la souris. J'ai résolu ceci en changeant "/dev/input/event1" en "/dev/input/event2" dans /etc/xorg.conf.

 

Pour eviter ce genre de désagrément vous pouvez faire des jolies règles udev, et mettre quelques chose du style event11 ou 12 (pas un jolix nom, style /dev/input/raser, car sinon, evdev ne va pas être content :/) en dure, ainsi plus de mauvaise surprise

----------

## Dominique_71

 *truc wrote:*   

>  *Dominique_71 wrote:*   J'ai eu un problème similaire en passant d'un 2.6.16-rt29 à un 2.6.19-rt11. X refusait de se lancer et se plaignait qu'il ne trouvait pas la souris. J'ai résolu ceci en changeant "/dev/input/event1" en "/dev/input/event2" dans /etc/xorg.conf. 
> 
> Pour eviter ce genre de désagrément vous pouvez faire des jolies règles udev, et mettre quelques chose du style event11 ou 12 (pas un jolix nom, style /dev/input/raser, car sinon, evdev ne va pas être content :/) en dure, ainsi plus de mauvaise surprise

 

Merci pour la suggestion, mais je ne suis pas prêt d'essayer une nouvelle fois d'écrire une régle udev. J'ai déjà essayé et cela n'a jamais marché. Vu de mon point de vue d'utilisateur confirmé mais non spécialiste système (J'avais installé linux à l'époque avec succès sur mon deuxième PC, un 286, de même que sur un Amiga 2000.), udev est une saloperie infame (en bon français) qui ne fait que compliquer mon système et ne m'apporte, en terme de fonctionnalité, rien de nouveau.

Par exemple, pour ce cas précis de souris, ma souris fonctionnait tout aussi bien avec les anciens kernels sans udev. De plus, elle était beaucoup plus simple à configurer. Je pourrais aussi parler ici d'udev et alsa, que de workarounds pour rien de plus. Enfin, combien de règles faudrait-il écrire pour être sur de ne pas avoir de mauvaises surprises après un upgrade? Je suppose, que pour être sûr, il faudrait écrire une règle pour chaque hardware présent dans et autour du PC, car si la façon de gérer ma souris dans udev à changé entre deux upgrade, rien n'interdit de penser que la façon de gérer n'importe quel autre hardware peut changer. Donc, pour faire court: stop!

Et parlons de choix. Linux est sensé offrir le choix à l'utilisateur et je n'ai même pas la possibilité de tout simplement supprimer udev de mon système car si je le fait je vais tout casser!

Je suis bien d'accord d'apprendre un soft comme fvwm car celui-ci m'offre une plus grande flexibilité que tous les autres softs équivalents réunis ainsi que des performances inégalées. De plus j'ai le choix de l'installer ou pas. Par contre, ne voyant pas ce qu'udev m'offre mis à part une usine à gaz si compliquée que personne n'a réussit à écrire un GUI pour le configurer (ce qui, soit dit en passant, existe même pour une autre usine à gaz, la base de registres de windows), je ne suis pas prêt de réessayer de m'y mettre car j'ai simplement mieux à faire de mon temps.

Cette situation d'udev dans linux est particulièrement dommage car de manière générale, les versions actuelles de linux sont beaucoup plus faciles à installer et à gérer que celles d'il y a quelques années (en tous cas pour les distributions non commerciales comme gentoo et debian, les autres ont toujours des particularités non documentées...).

Une autre solution serait d'écrire des docs udev accessibles au non spécialiste système, genre udev pour les nuls et référence rapide udev. Mais à voir comme c'est parti, udev sera sans doute obsolète ce jour là.

----------

## truc

salut, je ne voies pas vraiment ce que tu reproches à udev, mais je n'en suis pas expert, donc il y a certainement beaucoup de choses qui m'échappent... 

Cela dit je me permets de redonner ce lien, tu le connais probablement, même si ta remarque quand à l'inexistance de bonne doc utilisateur me fait penser le contraire:

http://www.reactivated.net/writing_udev_rules.html

Si quelque chose n'était toute fois pas claire, on peut peut-être t'aider (même si je n'ai jamais eu d'amiga hein  :Wink:  )

----------

## tmasscool

 *Dominique_71 wrote:*   

>  udev est une saloperie infame ...

 

Non. techniquement udev est nettement mieux que l'ancien devfs.

 *Dominique_71 wrote:*   

> qui ne fait que compliquer mon système et ne m'apporte, en terme de fonctionnalité, rien de nouveau.

 

udev apporte plein de trucs cool par rapport à l'ancien devfs. Souvenez vous le bordel que c'était avec les majors et minor numbers des périphériques qd on voulait rajouter/créer des périphs. udev peut communiquer via dbus, ce qui est utilisé notamment par hal pour voir quels périphériques ont été pluggés, ce qui a sensiblement amélioré/facilité l'automontage des périph. sous linux ces derniers temps.

 *Dominique_71 wrote:*   

> Par contre, ne voyant pas ce qu'udev m'offre

 

je vais t'aider : udev vs devfs

Ceci dit, je comprends tout à fait que ce genre de désagréments sont particulièrements énervant.

----------

## geekounet

 *tmasscool wrote:*   

>  *Dominique_71 wrote:*   qui ne fait que compliquer mon système et ne m'apporte, en terme de fonctionnalité, rien de nouveau. 
> 
> udev apporte plein de trucs cool par rapport à l'ancien devfs. Souvenez vous le bordel que c'était avec les majors et minor numbers des périphériques qd on voulait rajouter/créer des périphs. udev peut communiquer via dbus, ce qui est utilisé notamment par hal pour voir quels périphériques ont été pluggés, ce qui a sensiblement amélioré/facilité l'automontage des périph. sous linux ces derniers temps.

 

Correction : udev envoie des évènements à hal qui ensuite envoie des message via dbus aux applications utilisateurs.  :Smile: 

----------

## tmasscool

ooooooooooooops.

Désolé   :Confused: 

----------

