| Summary: | usb mouse often randomly freezes within xorg | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | WiseLYNX <wiselynx.naima> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | netz |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
my X configuration file
/etc/udev/rules.d/10-personal.rules |
||
|
Description
WiseLYNX
2005-09-03 09:04:12 UTC
Created attachment 67563 [details]
my X configuration file
it shouldn't add anything, but here it is the X configuration file I'm using.
devices names within /dev are a bit out of standard thanks to udev, but things
didn't work either before I had udev and I was using standard devices name.
Try using /dev/input/mice rather than /dev/input/usbmouse in fact I used to use /dev/input/mice before passing to udev. but it didn't solve the problem (instead, I passed to udev hoping it would have solved the issue), and using the "multiplexed" device also has the drawback that it can't differentiate between a standard USB mouse and a Wacom graphic tablet (which in X soulh use different drivers.) anyway, I just tried again, and no, it doesn't solve the problem: the mouse still freezes after some minutes of use Created attachment 67646 [details]
/etc/udev/rules.d/10-personal.rules
just to set things clearer, here is the udev rules file that generates devices
names used in my XF86Config
Please reproduce this on the latest kernel, currently 2.6.13 I tried with 2.6.13-r1, and the problem seems to be gone (I can't exclude completely that it just happens more rarely). It's hard to do extensive test however (i.e. all days use) because there are other issues with this kernel (orinoco pcmcia modules non working at all, fbsplah not loading from initramfs, and other minor), but I think the mouse bug can be considered as fixed. Thanks I did some more testing and, yes, the mouse doesn't freeze that often as with previous kernel. but it still sometimes stops working. I fear the problem cannot be considered completely solved yet.. After the mouse frezes, does anything appear in /dmesg ? Does the device drop out of /proc/bus/input/devices ? Does running "cat" on the device node produce any output? Is the usb mouse known to work ok on other setups? see comment #9 Sorry for the long delay, I'm very busy at this time. After the mouse freezes, nothing appears in dmesg, the device doesn't drop out of /proc/bus/input/devices (here is a cut&paste of its section, which is unmodified before and after the freeze) I: Bus=0003 Vendor=046d Product=c506 Version=1600 N: Name="Logitech USB Receiver" P: Phys=usb-0000:00:11.2-1/input0 H: Handlers=mouse0 event2 B: EV=17 B: KEY=ffff0000 0 0 0 0 0 0 0 0 B: REL=103 B: MSC=10 a cat of the device file (both on /dev/input/usbmouse link created by udev and /dev/input/mouse0) doesn't produce anything. the mouse is well tested as working on different other system, including a Win98 host, a Win2k, a WinXP and another Gentoo Linux box. Hello, on my system I experience the same bug, my mouse freezes after some time. Mostly when I haven't used it for a minute, but I seem to recall that it happened once while using it. The problem appears when having plugged in a pl2303 serial converter at the same time. This happens also with the evdev-module, except in this case switching virtual consoles does not help (the one time it happened since switching to evdev). Running a pure ~x86 system Update: since using evdev, not even un- and replugging the mouse helps. It seems to be a kernel bug, since /dev/input/mouse? and /dev/input/event? don't send anything anymore. Replugging helps, but then, somehow, xorg doesn't get it. Any ideas someone? Something I should test? Jan, please open a new bug with the relevant info. I have, see bug #127902 |
