Date: Wed, 30 Jan 2008 17:45:08 +0100 From: Vojtech Pavlik <vojtech@suse.cz> To: Andriy Gapon <avg@icyb.net.ua> Cc: mikeh@FreeBSD.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: mouse problems [A4 Tech OP-3D] Message-ID: <20080130164508.GC6257@suse.cz> In-Reply-To: <47A097FA.3090303@icyb.net.ua> References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080130164508.GC6257>