From owner-freebsd-questions@FreeBSD.ORG Thu Jun 28 18:46:27 2012 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 700C41065673 for ; Thu, 28 Jun 2012 18:46:27 +0000 (UTC) (envelope-from jau@iki.fi) Received: from jau.iki.fi (ip193-64-26-117.cust.eunet.fi [193.64.26.117]) by mx1.freebsd.org (Postfix) with ESMTP id D5E128FC0A for ; Thu, 28 Jun 2012 18:46:26 +0000 (UTC) Received: from [192.168.1.131] (sleipnir.thunderbolt.fi [192.168.1.131]) by jau.iki.fi (8.14.5/8.14.5) with ESMTP id q5SIkCwO077977 for ; Thu, 28 Jun 2012 21:46:19 +0300 (EEST) (envelope-from jau@iki.fi) Message-ID: <4FECA66F.3030602@iki.fi> Date: Thu, 28 Jun 2012 21:46:07 +0300 From: "Jukka A. Ukkonen" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120614 Thunderbird/13.0 MIME-Version: 1.0 To: questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (jau.iki.fi [192.168.1.42]); Thu, 28 Jun 2012 21:46:19 +0300 (EEST) Cc: Subject: Wheel mouse oddity - wheel only reporting button release X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 18:46:27 -0000 Hi, Does anyone have any idea what is going on when a ps/2 mouse with a wheel (actually a trackball) sometimes works just fine and sometimes the wheel reports button release events only? This is happening on an AMD64 system running FreeBSD-9.0. I used truss to trace moused to see how the basic 3 buttons always send "\t\0\0", "\n\0\0", or "\f\0\0" for button press and then "\b\0\0" for button release. The wheel only sends "\b\0\0" for button release. This looks awful lot like moused failed to talk to the device using level 1 or level 2 protocol, decided to fall back to level 0 protocol, and silently went on using 3 byte packets which cannot carry the data for more than 3 buttons. If this is the case and level 1 was explicitly requested, I would expect moused to complain loudly about not being able to use the requested protocol level. Has anyone else seen something similar? Can this behavior be changed using hint.psm.0.flags in /boot/device.hints? Could this be a side effect of a KVM switch getting confused and forcing the protocol to downgrade to level 0? Should I simply replace the KVM switch? --jau