From owner-freebsd-hardware@FreeBSD.ORG Wed Jan 30 15:30:06 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 841F216A468; Wed, 30 Jan 2008 15:30:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 046D613C468; Wed, 30 Jan 2008 15:30:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id AD7DE43E073; Wed, 30 Jan 2008 17:30:04 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0aY54i0vPUP; Wed, 30 Jan 2008 17:30:04 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 0C8BB43DDA8; Wed, 30 Jan 2008 17:30:03 +0200 (EET) Message-ID: <47A097FA.3090303@icyb.net.ua> Date: Wed, 30 Jan 2008 17:30:02 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org References: <4799D78F.6000405@icyb.net.ua> In-Reply-To: <4799D78F.6000405@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mikeh@FreeBSD.org, Vojtech Pavlik 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 15:30:06 -0000 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