mouse problems [A4 Tech OP-3D]
avg at icyb.net.ua
Wed Jan 30 07:30:06 PST 2008
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=0x3 (note: integer), status='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:
> 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.
More information about the freebsd-stable