After some poking into psm.c code I've got some results. First, for the archives, debug.psm.loglevel tunable is much more useful than a verbose boot for debugging PS/2 mouse issues. A good value is 2. Second, I fiddled with various probe methods to force them to "recognize" my mouse (by loosening their checks) and found out that the mouse works perfectly if it is treated as "IntelliMouse Explorer" (MOUSE_MODEL_EXPLORER). In this case everything is perfect: all buttons work, the wheel works, movements are correctly reported, no spurious packets. Tested both in console and in X. The trick was to change enable_msexplorer() so that in addition to aux id PSM_EXPLORER_ID=4 it also accepts PSM_MOUSE_ID=0. I am not sure if this is a too permissive check that could break things for other mice. Just in case: when I attempted to "hack" enable_groller() and enable_gmouse() I noticed that status returned by mouse_id_proc1() for this mouse was 0x00 0x03 0x64, or in other words status[1]=0x3 (note: integer), status[2]='d' (note: char). I see that Linux driver and FreeBSD driver are (mostly) equivalent in "IntelliMouse Explorer" detection. I wonder if Linux handles this mouse well, and if yes, then how. on 25/01/2008 14:35 Andriy Gapon said the following:> I've recently got a cheap PS/2 mouse A4 Tech OP-3D: > http://www.a4tech.com/EN/product2.asp?CID=114&SCID=115&MNO=OP-3D > > It looks like your regular mouse with a combined > middle-button/scroll-wheel. The only unusual feature is an additional > button for "double-click" - I am not sure if it's simulated within the > mouse itself or if it is reported to controller/driver. > > There is a problem with this mouse though: if I don't do anything > special then this mouse acts very erratically and misbehaves all it can > - movements are ignored or reported as button clicks, button clicks get > reported as movements or clicks of different buttons, etc. > One cure that I initially found was to kill moused, disconnect and > reconnect the mouse and restart moused, after that moused worked well. > Then, I found out that I could achieve the same if I specify 0x200 flag > (no id probing). > Judging from verbose dmesg the mouse is detected as a generic ps/2 mouse > with or without this flag, there is no difference whatsoever. So it > seems that probing for various mouse models somehow hoses this mouse. > > Question #1: maybe some kind of additional mouse reset should be > performed after all probes failed and we settle on generic? > > Well, while flag 0x200 makes the mouse behave reasonably, it seems that > the presence of the wheel is not detected (or mouse is configured to > ignore it?), so I can not use it. > > Question #2: what are the further steps to debug this issue so that this > mouse is properly recognized? I really would like to get the wheel working. > > I can provide any additional information needed. > Thank you. >-- Andriy Gapon
On Wed, Jan 30, 2008 at 05:30:02PM +0200, Andriy Gapon wrote:> > After some poking into psm.c code I've got some results. > > First, for the archives, debug.psm.loglevel tunable is much more useful > than a verbose boot for debugging PS/2 mouse issues. A good value is 2. > > Second, I fiddled with various probe methods to force them to > "recognize" my mouse (by loosening their checks) and found out that the > mouse works perfectly if it is treated as "IntelliMouse Explorer" > (MOUSE_MODEL_EXPLORER). In this case everything is perfect: all buttons > work, the wheel works, movements are correctly reported, no spurious > packets. Tested both in console and in X. > > The trick was to change enable_msexplorer() so that in addition to aux > id PSM_EXPLORER_ID=4 it also accepts PSM_MOUSE_ID=0. > I am not sure if this is a too permissive check that could break things > for other mice.Yes, it is way too permissive: If the test returns 0, this means that it failed.> Just in case: when I attempted to "hack" > enable_groller() and enable_gmouse() I noticed that status returned by > mouse_id_proc1() for this mouse was 0x00 0x03 0x64, or in other words > status[1]=0x3 (note: integer), status[2]='d' (note: char). > > I see that Linux driver and FreeBSD driver are (mostly) equivalent in > "IntelliMouse Explorer" detection. I wonder if Linux handles this mouse > well, and if yes, then how.I don't know, honestly, I never tried this specific mouse. A4-Tech is infamous of producing mice with all kinds of strange quirks and bugs. Vojtech> > on 25/01/2008 14:35 Andriy Gapon said the following: > > I've recently got a cheap PS/2 mouse A4 Tech OP-3D: > > http://www.a4tech.com/EN/product2.asp?CID=114&SCID=115&MNO=OP-3D > > > > It looks like your regular mouse with a combined > > middle-button/scroll-wheel. The only unusual feature is an additional > > button for "double-click" - I am not sure if it's simulated within the > > mouse itself or if it is reported to controller/driver. > > > > There is a problem with this mouse though: if I don't do anything > > special then this mouse acts very erratically and misbehaves all it can > > - movements are ignored or reported as button clicks, button clicks get > > reported as movements or clicks of different buttons, etc. > > One cure that I initially found was to kill moused, disconnect and > > reconnect the mouse and restart moused, after that moused worked well. > > Then, I found out that I could achieve the same if I specify 0x200 flag > > (no id probing). > > Judging from verbose dmesg the mouse is detected as a generic ps/2 mouse > > with or without this flag, there is no difference whatsoever. So it > > seems that probing for various mouse models somehow hoses this mouse. > > > > Question #1: maybe some kind of additional mouse reset should be > > performed after all probes failed and we settle on generic? > > > > Well, while flag 0x200 makes the mouse behave reasonably, it seems that > > the presence of the wheel is not detected (or mouse is configured to > > ignore it?), so I can not use it. > > > > Question #2: what are the further steps to debug this issue so that this > > mouse is properly recognized? I really would like to get the wheel working. > > > > I can provide any additional information needed. > > Thank you. > > > > > -- > Andriy Gapon >-- Vojtech Pavlik Director SuSE Labs
on 30/01/2008 18:45 Vojtech Pavlik said the following:> On Wed, Jan 30, 2008 at 05:30:02PM +0200, Andriy Gapon wrote:[snip]>> I see that Linux driver and FreeBSD driver are (mostly) equivalent in >> "IntelliMouse Explorer" detection. I wonder if Linux handles this mouse >> well, and if yes, then how. > > I don't know, honestly, I never tried this specific mouse. A4-Tech is > infamous of producing mice with all kinds of strange quirks and bugs.But not this time :) I tried to boot Knoppix live CD and it recognized the mouse as having ImExPS/2 protocol which the same as I found by try-and-error. I compared FreeBSD and Linux sources more thoroughly and found the following: http://lxr.linux.no/linux+v2.6.24/drivers/input/mouse/psmouse-base.c#L464 static int im_explorer_detect(struct psmouse *psmouse, int set_properties) { struct ps2dev *ps2dev = &psmouse->ps2dev; unsigned char param[2]; intellimouse_detect(psmouse, 0); I.e., first thing the explorer probe does is massaging a mouse with IntelliMouse magic commands. I did the same in FreeBSD psm.c, i.e., added a call to enable_msintelli() at the very start of enable_msexplorer(). And voil? - everything is perfect, correct ID is returned, probing succeeds, the mouse works great. I think that this change is quite safe to make in FreeBSD, because with Linux user-base we can be 99% percent sure that this change won't break anything.>> on 25/01/2008 14:35 Andriy Gapon said the following: >>> I've recently got a cheap PS/2 mouse A4 Tech OP-3D: >>> http://www.a4tech.com/EN/product2.asp?CID=114&SCID=115&MNO=OP-3D >>> >>> It looks like your regular mouse with a combined >>> middle-button/scroll-wheel. The only unusual feature is an additional >>> button for "double-click" - I am not sure if it's simulated within the >>> mouse itself or if it is reported to controller/driver. >>> >>> There is a problem with this mouse though: if I don't do anything >>> special then this mouse acts very erratically and misbehaves all it can >>> - movements are ignored or reported as button clicks, button clicks get >>> reported as movements or clicks of different buttons, etc. >>> One cure that I initially found was to kill moused, disconnect and >>> reconnect the mouse and restart moused, after that moused worked well. >>> Then, I found out that I could achieve the same if I specify 0x200 flag >>> (no id probing). >>> Judging from verbose dmesg the mouse is detected as a generic ps/2 mouse >>> with or without this flag, there is no difference whatsoever. So it >>> seems that probing for various mouse models somehow hoses this mouse. >>> >>> Question #1: maybe some kind of additional mouse reset should be >>> performed after all probes failed and we settle on generic? >>> >>> Well, while flag 0x200 makes the mouse behave reasonably, it seems that >>> the presence of the wheel is not detected (or mouse is configured to >>> ignore it?), so I can not use it. >>> >>> Question #2: what are the further steps to debug this issue so that this >>> mouse is properly recognized? I really would like to get the wheel working. >>> >>> I can provide any additional information needed. >>> Thank you. >>> >> >> -- >> Andriy Gapon >> >-- Andriy Gapon