From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 30 17:02:28 2008 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52B0916A4A6; Wed, 30 Jan 2008 17:02:28 +0000 (UTC) (envelope-from vojtech@suse.cz) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by mx1.freebsd.org (Postfix) with ESMTP id DCEE013C478; Wed, 30 Jan 2008 17:02:27 +0000 (UTC) (envelope-from vojtech@suse.cz) Received: from shadow.suse.cz (shadow.suse.cz [10.20.1.183]) (Authenticated sender: vojtech) by mail.suse.cz (Postfix) with ESMTP id DCE566280DD; Wed, 30 Jan 2008 17:45:08 +0100 (CET) Received: by shadow.suse.cz (Postfix, from userid 10002) id AA606C5408A; Wed, 30 Jan 2008 17:45:08 +0100 (CET) Date: Wed, 30 Jan 2008 17:45:08 +0100 From: Vojtech Pavlik To: Andriy Gapon Message-ID: <20080130164508.GC6257@suse.cz> References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A097FA.3090303@icyb.net.ua> X-Bounce-Cookie: It's a lemon tree, dear Watson! User-Agent: Mutt/1.5.16 (2007-06-09) Cc: mikeh@FreeBSD.org, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: mouse problems [A4 Tech OP-3D] X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 17:02:28 -0000 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