Most recent kernel where this bug did not occur: Kernel 2.4.x series Distribution: Slackware Hardware Environment: vcom ps/2 optical mouse, Athlon XP 2400+, 1gb ram, Asus motherboard (Sis 5513 chipset). Software Environment: Slackware 10.2 distro. Problem Description: When the psmouse module is loaded, the mouse light that reads the surface and makes it move is turned off. Only powering off the computer again or re-pluging the device will turn them on again. If the Linux distro is still with the module loaded, it needs to be unloaded so the lights will turn on. When the module turns off the mouse lights, the mouse won't work even under other OS (here windows XP), unless you re-plug it before the other OS boots/ power down the computer. Steps to reproduce: 1. Get any ps/2 mouse that uses this protocol. Mine is a vcom C328. 2. Load psmouse. 3. Now the lights will be turned off and only the buttons will work (under Linux). Notice that I've researched on Google and there have been several people with this problem. Check: http://www.google.com.br/search?hl=pt-BR&q=imexps%2F2&btnG=Pesquisa+Google&meta= Also notice that this mouse works fine under 2.4.x series. I'm using it right now. I haven't noticed any problems with ps/2 or imps/2 mice up to now. Thanks.
Could you possibly open the mouse and check what chips are inside? Your step #1 isn't right - I have a large number of mice for testing, and none of them shows the behavior you describe. I know there is a number of lesser known mouse brands (mainly cheap mice), like your vcom, that turn the light off, but I need to find out which mouse to buy to be able to reproduce this on my machine. I know that Agilent's optical sensor (ADNS2000, ADNS2020, ...) mice don't have this problem.
Unfortunately I can't open my mouse and I have poor knowledge about hardware, so even if I opened it I probably wouldn't be able to help you. But you can try these models: 1) My own mouse, Vcom C328. 2) GE optical ps/2 mouse. http://www.mepis.org/node/7881 -> check the "my mouse doesn't work too" comment. 3) Nexxtech NXX200 PS/2 Optical Wheel Mouse. http://www.forumsforyou.com/p/linux.kernel/ImExPS_2_status_720.html I'll see if I can find a few more of those problematic mice around.
Vojtech, wasn't you working under a similar problem a while ago, regarding imexps/2 detection? I saw some links about this. By the way, Piter Punk, from the Linux Kernel Mailing List, describes the same problem. If I'm not helpful enough about opening my mice and describing its physical components, maybe he could be. http://lkml.org/lkml/2005/9/15/322
I'm sorry. For now I couldn't find any additional models. Only wheel problems with some Logitech mice regarding this module. https://internal.lboro.ac.uk/mail/public/lulu/2003-05/msg00034.html Any progress so far?
Dear Vojtech Pavlik, I found a temporary workaround lurking at google. Please read this until the end. First, two mice that won't work too. * Some Logitech ps/2 mice were reported at some discussion lists. * AMI Mouse 250 S. References: http://forums.gentoo.org/viewtopic-t-350831-postdays-0-postorder-asc-start-0.html I found those references on google: http://www.google.com.br/search?hl=pt-BR&q=imexps%2F2+laser&btnG=Pesquisa+Google&meta= One of the posters, Matteo Azzali, created a workaround patch: http://forums.gentoo.org/viewtopic-t-350831-postdays-0-postorder-asc-start-75.html # Patch starts --- linux/drivers/input/mouse/psmouse-base.c.orig 2005-09-18 22:06:45.000000000 +0000 +++ linux/drivers/input/mouse/psmouse-base.c 2005-09-29 12:53:14.000000000 +0000 @@ -490,7 +490,7 @@ * Try ALPS TouchPad */ if (max_proto > PSMOUSE_IMEX) { - ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); + /*ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);*/ if (alps_detect(psmouse, set_properties) == 0) { if (!set_properties || alps_init(psmouse) == 0) return PSMOUSE_ALPS; @@ -511,7 +511,7 @@ * Reset to defaults in case the device got confused by extended * protocol probes. */ - ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); + /*ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);*/ if (max_proto >= PSMOUSE_IMEX && im_explorer_detect(psmouse, set_properties) == 0) return PSMOUSE_IMEX; @@ -533,7 +533,7 @@ * extensions. */ psmouse_reset(psmouse); - ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); + /*ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);*/ } return PSMOUSE_PS2; @@ -664,8 +664,8 @@ * Then we reset and disable the mouse so that it doesn't generate events. */ - if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_DIS)) - printk(KERN_WARNING "psmouse.c: Failed to reset mouse on %s\n", ps2dev->serio->phys); + /*if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_DIS))*/ + /*printk(KERN_WARNING "psmouse.c: Failed to reset mouse on %s\n", ps2dev->serio->phys);*/ return 0; } #Patch ends I got the latest vanilla kernel and it just didn't work. The patch was rejected. But since it was reported to work, I gave it a shot assuming the file had changed and created a new patch based on the old one. #Patch starts --- linux/drivers/input/mouse/psmouse-base.c.orig 2005-09-18 22:06:45.000000000 +0000 +++ linux/drivers/input/mouse/psmouse-base.c 2005-09-29 12:53:14.000000000 +0000 @@ -490,7 +490,7 @@ * Try ALPS TouchPad */ if (max_proto > PSMOUSE_IMEX) { - ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); + /*ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);*/ if (alps_detect(psmouse, set_properties) == 0) { if (!set_properties || alps_init(psmouse) == 0) return PSMOUSE_ALPS; @@ -511,7 +511,7 @@ * Reset to defaults in case the device got confused by extended * protocol probes. */ - ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); + /*ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);*/ if (max_proto >= PSMOUSE_IMEX && im_explorer_detect(psmouse, set_properties) == 0) return PSMOUSE_IMEX; @@ -533,7 +533,7 @@ * extensions. */ psmouse_reset(psmouse); - ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); + /*ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);*/ } return PSMOUSE_PS2; @@ -664,8 +664,8 @@ * Then we reset and disable the mouse so that it doesn't generate events. */ - if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_DIS)) - printk(KERN_WARNING "psmouse.c: Failed to reset mouse on %s\n", ps2dev->serio->phys); + /*if (ps2_command(ps2dev, NULL, PSMOUSE_CMD_RESET_DIS))*/ + /*printk(KERN_WARNING "psmouse.c: Failed to reset mouse on %s\n", ps2dev->serio->phys);*/ return 0; } #Patch ends I've rebuilt my modules, rebooted my computer and to my surprise, it did work. However, since this is said to be a workaround by the original author (and due to my lack of knowledge to the kernel API) I really hope this get fixed soon. Thanks in advance, Carlos A. R. de Souza. P.S: Isn't ps2_command very suspicious? It may be a great spot to start debugging from.
You can try replacing PSMOUSE_CMD_RESET_DIS with PSMOUSE_CMD_RESET_BAT instead of commenting them out. That may make the mouse work, too, and would be almost possible to merge upstream. The problem with just removing those lines is that the mouse will not be initialized properly in many other cases.
Dear Vojtech, I did what you told me to, then to make sure the module would in fact be overwritten I removed the /lib/modules/<kernel-version> and made a make modules_install. The module seemed to be recompiled and my mouse is in fact working. But I have a few questions. 1) What are PSMOUSE_CMD_RESET_DIS and PSMOUSE_CMD_RESET_BAT? 2) Do you think this fix will be merged into vanilla? Thanks, Carlos.
They are two variants of a Reset command the PS/2 protocol defines. RESET_DIS should just reload the mouse settings to default values and disable the mouse. The mouse is then enabled by the ENABLE command. RESET_BAT is a complete reset, including selftest. It can take quite a long time, and that's why the driver uses RESET_DIS - it's much quicker. Unfortunately recently mice started appearing that take RESET_DIS as a powerdown command, and don't become enabled on a subsequent ENABLE. Yours is one of these unusual mice - I believe they all share the same PS/2 chip. That's why the fix works, but it has the nasty side effect in causing the mouse init to take longer. This used to be very bad in the past, when we used polling to do PS/2 commands. Now we do them asynchronously, and thus don't block the CPU while the commands are being executed. I guess applying the patch to change RESET_DIS to RESET_BAT is doable. Dmitry, what do you think?
Created attachment 6855 [details] Patch to do full reset before probing for intellimouse I don't know if we want to change all PSMOUSE_RESET_DIS to PSMOUSE_RESET_BAT, there are just too many of them. But what about using PSMOUSE_RESET_BAT right before we start probing for intellimouse and explorer protocols? Hopefully full reset will wake up mice put to sleep by earlier PSMOUSE_RESET_BAT... Could you please try the attached patch? Thanks!
Your patch looks very good, Dmitry. I hope it works. :)
Dear Dmitry and Vojtech I'm sorry I took so long to answer. I deleted my kernel source tree to apply it into a fresh one. But then I noticed some files refused to be deleted. Then I suspected filesystem corruption. I use reiserfs, so I've used my rescue cd with the command reiserfsck --rebuild-tree -S and it indeed reported lots of corruptions. Meanwhile it fixed my whole metadata, I noticed that most of my filesystem was corrupted somehow. reiserfsck reported files being stored at the wrong place and so on. Then I saw the directory I deleted back, and re-erased it. In fact, in lost+found, I saw files I deleted AGES ago! The weird part is that badblocks -b 4096 didn't report any corrupted blocks in that partition. I also had (actually, still have) this problem under a different disk running under windows xp. It won't erase a file I copied with Yareg (reads reiserfs) from windows. Any clue of what this could be? By the way, my mouse now is detected as imps/2. Look: input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 and plugging and unplugging it now won't show this message in /var/log/messages. Only if I load and unload the module again. Anyway, all is smooth regarding the mouse. Will this patch go mainstream? Peace.
Carlos, Thank you for your testing and help in resolving the problem. I got another confirmation that the patch cures mouse light problem but we would need more testing before getting the fix into the kernel. I am going to port the patch on the kernel mailing list, let's see if we can get some testers... Unfortunately I have no idea what happened to your filesystem sorry. Vojtech, your idea about using full reset is great. If it indeed works for all these mice a lot of people will be very happy :)
This patch, if correct, might even help with some KVMs. We could even try to use the RESET_DIS for powersaving PS/2 optical mice. I believe many of them will turn the light off in disabled state (while only few do not turn it on when ENABLE is sent). The only thing that worries me is the change of detection result - from ImExPS/2 to 'just' ImPS/2 after the patch. Do you have any explanation for it? What will happen on real ImExPS/2 mice that need the extended protocol for extra buttons?
Regarding the drive corruption, this looks like it happens somewhere between the controller and the CPU. The drive itself seems OK (badblocks doesn't say anything), the drive bus (I assume IDE, but the same would apply to SCSI, SATA or SAS) doesn't complain about CRC errors, so it must be either the controller itself (unlikely), PCI bus (unlikely), chipset (quite probable), RAM (very likely), CPU (possible) or the kernel itself (unlikely, usually kernel bugs are seen on heavily loaded servers and not home machines).
I really hope this patch is thesolution. Indeed a LOT of people would be happy and more willing to use Linux. Quick comment about my personal catastrophe: this isn't the first time I get these results. I got these on other two 120gb drivers of different brands: a Maxtor Diamond Plus and a Seagate. My motherboard is an Asus A7S333 (Sis 5513 chipset), and though I really don't *want* it to be the motherboard, since it is supposed to be at least decent, it could very well be it. About the ImExps/2 -> imps/2: maybbe the kernel was detecting the mouse wrongly? My mouse only has two buttons and a wheel (which also works like a third button, needless to say). :) Maybe we could check it out with people that use "more-than-confirmed" ExplorerPs/2 mice. Peace, Carlos. P.S: I have a friend that has a wheel mouse (regular), but his wheel wouldn't work under X, even with the "ZAxisMapping" option. His mice was USB. Is this a module issue too?
Created attachment 6865 [details] Do a full reset and issue GETID I am not sure if before the mouse was confused and the protocol was mis-detected or if it indeed responds to explorer probe. I wonder if we add GETID command right after reset (thus restoring "classic" or "reference" detection sequence) the results will be different. Carlos, could you please try this patch instead of the fisrt one to see if your mouse will stay as imps2 or will revert back to exps2? As far as USB micce go - that's a different driver. Your friend may want to use 'evbug' module to verify if the mouse generates correct events when he uses its wheel. If so the problem is somewhere in userspace.
Dmitry, Even after your second patch, my mouse is still detected as imps/2. And yes, it works perfectly. Peace.
*** Bug 5754 has been marked as a duplicate of this bug. ***
*** Bug 5332 has been marked as a duplicate of this bug. ***
Just a note. I had this exact issue and Dmitry patch #1 solved for me, as Dmitry already knows. There's more.I bought this "bugged" mouse to replace my previous one, a trust ami mouse 250s optical, and I was surprised when, opening the box, I found that the new version (the buggy one for what this report is for) has just 3 buttons (one of which is wheel), while the old version with same name had 2 more buttons on the sides (needless to say, old mouse is broken). So I suppose (IMHO) that this feature is delivered by a chip that can't handle more than 3 buttons, or the real protocol is imPS2 instead of imEXPS2. Just my 2 cents though, but's kinda strange that the name of the model is exaclty the same.
So, guys? How's the testing going? Got any bugs so far with the patch or is it all smooth?
Here is all smooth even if I'm using the first Dmitry patch. To make wheel working in xorg 7.0 I had to remove protocol "auto" (common issue) and change it to protocol "IMPS/2" in xorg.conf .
Dmitry, we should take a look at the (simplistic) im/ex/ps/2 emulation in mousedev.c, to see why the autodetection of protocol in X.org 7.0 fails.
Do you know if "auto" worked with previous versions of X.org? Also, do you have "AutoSoft" option in your xorg.conf by any chance?
xorg-6.8.2 worked even with "auto" in my xorg.conf,I never had "Autosoft" in it, and the issue of the auto protocol is not a consequence of dmitry patch as stated here: http://forums.gentoo.org/viewtopic-t-377400-highlight-modular.html and here: http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt is a "general" issue (mouse wheel don't work with auto protocol).
First of all, I'm glad we got here this far. Two patches and both work! But a question comes to my mind: should the kernel module be specifically reviewed because of X.org 7.0? Isn't this more like a userland issue? I can confirm what Matteo said about all my mice working when I set my protocol to auto under X.org 6.2.
Since "auto" protocol stops working only after upgrading to Xorg 7.0 I am inclined to say that it's Xorg regression. Curiously, I searched their bugzilla but found nothing. Matteo, do you think you could submit a bug for them to get this issue going?
Done: https://bugs.freedesktop.org/show_bug.cgi?id=5442
So, how are the test results? Is a patch ready to enter the kernel branch yet? :)
The mouse protocol emulation in mousedev.c is far from perfect, so this is not necessarily a bug in the new X. It may just be probing more thoroughly than before.
@Carlos: I think Dmitry wants more test before the submission of the kernel patch, I tried to submit it to some friends (even with different mouse, to be safe from regressions) but no one reported till now. The X bug instead isn't specific to this kind of mouses,and should be considered as unrelated / not considered in this report. I tested Dmitry patch #2 since 10 days and is still here, working fine.
Hey. I've downloaded kernel 2.6.15 and saw the bugfix wasn't there. (My mouse didn't work, lights were turned off as usual...) Don't you think this is time to put this patch *at least* in the -mm series. That's the testing branch anyway, and we'll get good reports wether the patch does work or not. Besides, we've had very good results so far. Sitting here and waiting people actually test the patches is a moot point. Besides we all want to use the newest 2.6 kernels, don't we?
It has been merged in mainline and will be in 2.6.16. There is no way I'd add it to 2.6.15 close to release. And I might even jumped the gun almost skipping - mm.