Bonjour à tous,

J'ai un problème bizarre depuis un certain temps. Si je ne bouge pas ma souris sans fil durant un moment, de 3 à 5", elle semble se déconnecter.

Il faut la bouger 2 à 3" pour la reconnecter, ce qui est très agaçant.

J'ai essayé de :

- changer le port USB de ma souris (avant ou arrière de ma tour) ;

- de réinstaller le système ;

- d'utiliser une souris filaire : là, c'est encore pire, elle s'éteint.

Bon, ça pourrait aussi être un pb matériel, mais j'en doute un peu.

Merci d'avance de toute piste, c'est agaçant.

Résolu en remettant en jeu à tout hasard le module Hauppauge cx23885, voir CE SUJET.

Maintenant, la raison pour laquelle le fait de bloquer son module joue sur la souris -> ????

A moins que ce ne soit pas uniquement un module pour la TV ? Mais là, je pense que si.

(edit)

Nan, ça a résolu sur le moment, mais après un réinstalltion, le problème est revenu.

Bonjour.

Quel pilote Xorg utilise-il? ceux que je connais sont mouse, evdev et gpmdata (Gpm). Je ne sais pas si tu sais quoi faire pour changer le pilote de la souris d'Xorg, mais il se peut que tu obtiennes de meilleurs résultats en changeant.

Par défaut, sans fichier /etc/X11/xorg.conf ou fichier .conf se rapportant à la souris dans /etc/X11/xorg.conf.d/, Xorg utilise le pilote evdev. Avant de laisser Xorg utiliser sa configuration par défaut, j'ai utilisé sans problème les pilotes mouse et le répétiteur de Gpm, /dev/gpmdata.

Gpm doit être lancé avec l'option -R raw pouvoir utiliser /dev/gpmdata comme fichier de périphérique de la souris avec Xorg, exemple:

gpm -m /dev/input/mice -R raw -t imps2

Ma section se rapportant à la souris dans /etc/x11/xorg.conf:

Section "InputDevice"

Driver "mouse"

Identifier "Souris 0"

Option "Device" "/dev/gpmdata"

# Option "Device" "/dev/input/mice"

# Option "Device" "/dev/psaux"

Option "Protocol" "ImPS/2"

Option "ZAxisMapping" "4 5"

EndSection

Le protocol utilisé autant par Gpm que par Xorg pour la souris peut avoir de l'importance. Par défaut, Xorg utilise ExplorerPS/2 il me semble. Un lien intéressant: All Mouse Buttons Working - ArchWiki .

Bonjour Paul,

Merci de ta réponse.

Actuellement, ça remarche. J'ai installé à neuf à nouveau, mais là, j'ai formaté le /home aussi. Je vois d'ailleurs pas le rapport.

J'avais fait des essais sur les time-outs de powertop liés aux clés USB, mais normalement une réinstallation après formatage du système seul devrait suffire pour les virer, ça me paraît bizarre. Mais ça correspondrait bien, le time-out de déconnexion par défaut étant de 5".

En ce qui concerne le xorg.conf, je n'ai rien dedans concernant la souris. Celles que j'ai sont une Logitech sans fil et une Microsoft filaire (pas jeune du tout) tout à fait basiques.

Je vais regarder dans le dmseg ou le lspci si je les vois.

(edit)

Rien dans le lspci, mais dans le dmesg :

[pat@arch2 ~]$ dmesg | grep -i mouse
[ 2.307602] mousedev: PS/2 mouse device common for all mice
[ 4.355618] generic-usb 0003:046D:C52E.0004: input,hiddev0,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1.2/input1
[ 4.526616] input: Microsoft Microsoft IntelliMouse® Optical as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input4
[ 4.526926] generic-usb 0003:045E:0039.0005: input,hidraw4: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse® Optical] on usb-0000:00:1d.0-1.5/input0

Avec hwinfo, je retrouve les deux, notamment la Logitech :

93: USB 00.1: 10503 USB Mouse
[Created at usb.122]
Unique ID: KS5Q.b0ZOFsTpR64
Parent ID: FKGF.0j9+vWlqL56
SysFS ID: /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.1
SysFS BusID: 2-1.2:1.1
Hardware Class: mouse
Model: "Logitech USB Receiver"
Hotplug: USB
Vendor: usb 0x046d "Logitech, Inc."
Device: usb 0xc52e "USB Receiver"
Revision: "15.00"
Compatible to: int 0x0210 0x0038
Driver: "usbhid"
Driver Modules: "usbhid"
Device File: /dev/input/mice (/dev/input/mouse0)
Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event3, /dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse, /de
v/input/by-id/usb-Logitech_USB_Receiver-if01-event-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.2:1.1-event-mouse, /dev/input/by-id/usb-Logitech_USB_Receiver-if01-mouse, /dev/input/by-id/usb-Logitech_USB_Receiver-mouse, /dev/input/by-path/pci-0000:00:1d.0-usb-0:1.2:1.1-mouse
Device Number: char 13:63 (char 13:32)
Speed: 12 Mbps
Module Alias: "usb:v046DpC52Ed1500dc00dsc00dp00ic03isc01ip02"
Driver Info #0:
Buttons: 8
Wheels: 3
XFree86 Protocol: explorerps/2
GPM Protocol: exps2
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #99 (Hub)

Ils n'indiquent pas par contre le mode de gestion d'alimentation.

En reprenant le chemin du dmesg, plutôt :

cat /sys/devices/pci0000\:00/0000\:00\:1d.0/usb2/2-1/2-1.2/2-1.2\:1.0/input/input2/power/control
auto

auto semble être une mauvaise valeur, car le time-out est armé. Mais le chemin est trop long pour changer ça directement.

usbhid fait partie de initramfs.

Le positionnement de :

options usbhid autosuspend=0 (ou à 1)

est accepté par le mkinitcpio qui suit, mais ça ne change rien dans powertop après redémarrage, donc ce n'est pas lui.