mouse problems [A4 Tech OP-3D]

Vojtech Pavlik vojtech at suse.cz
Wed Jan 30 09:02:28 PST 2008


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


More information about the freebsd-stable mailing list