From tom@tomfoo.com  Thu Sep 25 20:18:17 2003
Return-Path: <tom@tomfoo.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 9477816A4B3
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 25 Sep 2003 20:18:17 -0700 (PDT)
Received: from lakemtao01.cox.net (lakemtao01.cox.net [68.1.17.244])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4CC2C44008
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 25 Sep 2003 20:18:16 -0700 (PDT)
	(envelope-from tom@tomfoo.com)
Received: from mail.tomfoo.com ([68.110.226.251]) by lakemtao01.cox.net
          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
          id <20030926031814.TJHO29208.lakemtao01.cox.net@mail.tomfoo.com>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Thu, 25 Sep 2003 23:18:14 -0400
Received: from builder.tomfoo.com (builder.tomfoo.com [192.168.55.8])
	by mail.tomfoo.com (8.12.8p2/8.12.8) with ESMTP id h8Q3IEp6010384
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 25 Sep 2003 23:18:15 -0400 (EDT)
	(envelope-from tom@tomfoo.com)
Received: from builder.tomfoo.com (localhost [127.0.0.1])
	by builder.tomfoo.com (8.12.10/8.12.10) with ESMTP id h8Q3I4hg033069
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 25 Sep 2003 23:18:04 -0400 (EDT)
	(envelope-from tom@builder.tomfoo.com)
Received: (from root@localhost)
	by builder.tomfoo.com (8.12.10/8.12.10/Submit) id h8Q3I48p033068;
	Thu, 25 Sep 2003 23:18:04 -0400 (EDT)
	(envelope-from tom)
Message-Id: <200309260318.h8Q3I48p033068@builder.tomfoo.com>
Date: Thu, 25 Sep 2003 23:18:04 -0400 (EDT)
From: Tom Convery <tpc@tomfoo.com>
Reply-To: Tom Convery <tpc@tomfoo.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [patch] psm(4) incorrectly identifies an IntelliMouse Explorer attached through an Avocent SwitchView KVM
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         57230
>Category:       kern
>Synopsis:       [psm] [patch] psm(4) incorrectly identifies an IntelliMouse Explorer attached through an Avocent SwitchView KVM
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Sep 25 20:20:18 PDT 2003
>Closed-Date:    Sun May 11 15:00:59 UTC 2008
>Last-Modified:  Sun May 11 15:00:59 UTC 2008
>Originator:     Tom Convery <tpc@tomfoo.com>
>Release:        FreeBSD 5.1-CURRENT i386
>Organization:
>Environment:
System: FreeBSD builder.tomfoo.com 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Wed Sep 24 09:48:01 EDT 2003 tom@builder.tomfoo.com:/usr/obj/usr/src/sys/BUILDER i386


	
>Description:
psm(4) identifies an IntelliMouse Explorer (4 buttons + wheel) as a standard
IntelliMouse (2 buttons + wheel) when the Explorer is attached through an
Avocent SwitchView KVM. According to Avocent's documentation, the SwitchView
is compatible with the IntelliMouse Explorer.

As best I can tell, the misidentification happens because psm doesn't probe
the Explorer exactly as described by Microsoft at
http://www.microsoft.com/whdc/hwdev/tech/input/5b_wheel.mspx, and the 
SwitchView needs the exact probe sequence to be happy.
>How-To-Repeat:
Attach an IntelliMouse Explorer through an Avocent SwitchView to a PS/2 
mouse port.
>Fix:
This patch fixes the problem for me. It does not break detection of either
a plain Intellimouse or an Intellimouse Explorer attached directly to the
PS/2 port.

This patch should apply to -STABLE as well.

--- intellimouse.patch begins here ---
--- src/sys/isa/psm.c.orig	Sat Jul 12 14:36:04 2003
+++ src/sys/isa/psm.c	Thu Sep 25 12:49:55 2003
@@ -751,6 +751,28 @@
 	}
     }
 
+    /*
+     * The Avocent SwitchView KVM appears to force an Intellimouse Explorer
+     * to revert to plain Intellimouse protocol whenever the device is
+     * disabled. This hack checks to see if we previously detected an Explorer,
+     * and tests if the device is now reporting a different ID. If this is the 
+     * case, we try to re-enable Explorer functionality.
+     */
+    if ((sc->hw.hwid == PSM_EXPLORER_ID) &&
+            (get_aux_id(sc->kbdc) != PSM_EXPLORER_ID)) {
+        log(LOG_DEBUG, "psm%d: Intellimouse Explorer reverted to lower "
+                       "protocol.\n", sc->unit);
+        enable_msexplorer(sc);
+        if (get_aux_id(sc->kbdc) == PSM_EXPLORER_ID)
+            log(LOG_DEBUG, "psm%d: Restored Intellimouse Explorer protocol.\n",
+                sc->unit);
+        else
+            log(LOG_DEBUG, "psm%d: Could not restore Intellimouse Explorer "
+                           " protocol.\n", sc->unit);
+            /* We shouldn't get here unless someone switched mice out from
+             * underneath us. How and/or should we deal with this? */
+    }
+
     if (get_mouse_status(sc->kbdc, stat, 0, 3) < 3) 
         log(LOG_DEBUG, "psm%d: failed to get status (doopen).\n", sc->unit);
 
@@ -2647,18 +2669,38 @@
 static int
 enable_msexplorer(struct psm_softc *sc)
 {
+    /* IntelliMouse initialization sequence */
     static unsigned char rate0[] = { 200, 100, 80, };
+    /* IntelliMouse Explorer initialization sequence */
     static unsigned char rate1[] = { 200, 200, 80, };
     KBDC kbdc = sc->kbdc;
     int id;
     int i;
 
-    /* the special sequence to enable the extra buttons and the roller. */
+    /*
+     * According to Microsoft's documentation for the IntelliMouse Explorer,
+     * full functionality is activated by first sending the IntelliMouse
+     * initialization sequence, then sending the Explorer initialization
+     * sequence.
+     * Reference: http://www.microsoft.com/whdc/hwdev/tech/input/5b_wheel.mspx
+     */ 
+
+    /* First send the IntelliMouse init sequence */
+    for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) {
+        if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i])
+            return FALSE;
+    }
+    /* If we've got an Explorer, it will claim to be an IntelliMouse here */
+    id = get_aux_id(kbdc);
+    if (id != PSM_INTELLI_ID)
+        return FALSE;
+
+    /* Now send the Explorer init sequence */
     for (i = 0; i < sizeof(rate1)/sizeof(rate1[0]); ++i) {
         if (set_mouse_sampling_rate(kbdc, rate1[i]) != rate1[i])
 	    return FALSE;
     }
-    /* the device will give the genuine ID only after the above sequence */
+    /* If we've got an Explorer, now it will identify itself */
     id = get_aux_id(kbdc);
     if (id != PSM_EXPLORER_ID)
 	return FALSE;
@@ -2676,11 +2718,18 @@
      * sequence; it will make the KVM think the mouse is IntelliMouse
      * when it is in fact IntelliMouse Explorer.
      */
+
+#if 0
+    /*
+     * This breaks IntelliMouse Explorer support with the Avocent
+     * SwitchView, which DOES actually understand the Explorer protocol.
+     */
     for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) {
         if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i])
 	    break;
     }
     id = get_aux_id(kbdc);
+#endif
 
     return TRUE;
 }
--- intellimouse.patch ends here ---


>Release-Note:
>Audit-Trail:

From: Tom Convery <tpc@tomfoo.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/57230: [patch] psm(4) incorrectly identifies an IntelliMouse
 Explorer attached through an Avocent SwitchView KVM
Date: Sat, 20 Dec 2003 23:52:58 -0500

 This is a multi-part message in MIME format.
 --------------030004040903090200060007
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Attached is an update patch that applies cleanly to 5-CURRENT as of 
 mid-December 2003.
 
 --------------030004040903090200060007
 Content-Type: text/plain;
  name="intellimouse.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="intellimouse.patch"
 
 --- psm.c.orig	Sat Dec 20 23:34:43 2003
 +++ psm.c	Sat Dec 20 23:47:52 2003
 @@ -774,6 +774,28 @@
  	}
      }
  
 +    /*
 +     * The Avocent SwitchView KVM appears to force an Intellimouse Explorer
 +     * to revert to plain Intellimouse protocol whenever the device is
 +     * disabled. This hack checks to see if we previously detected an Explorer,
 +     * and tests if the device is now reporting a different ID. If this is the 
 +     * case, we try to re-enable Explorer functionality.
 +     */
 +    if ((sc->hw.hwid == PSM_EXPLORER_ID) &&
 +            (get_aux_id(sc->kbdc) != PSM_EXPLORER_ID)) {
 +        log(LOG_DEBUG, "psm%d: Intellimouse Explorer reverted to lower "
 +                       "protocol.\n", sc->unit);
 +        enable_msexplorer(sc);
 +        if (get_aux_id(sc->kbdc) == PSM_EXPLORER_ID)
 +            log(LOG_DEBUG, "psm%d: Restored Intellimouse Explorer protocol.\n",
 +                sc->unit);
 +        else
 +            log(LOG_DEBUG, "psm%d: Could not restore Intellimouse Explorer "
 +                           " protocol.\n", sc->unit);
 +            /* We shouldn't get here unless someone switched mice out from
 +             * underneath us. How and/or should we deal with this? */
 +    }
 +
      if (get_mouse_status(sc->kbdc, stat, 0, 3) < 3) 
          log(LOG_DEBUG, "psm%d: failed to get status (doopen).\n", sc->unit);
  
 @@ -2768,18 +2790,38 @@
  static int
  enable_msexplorer(struct psm_softc *sc)
  {
 +    /* IntelliMouse initialization sequence */
      static unsigned char rate0[] = { 200, 100, 80, };
 +    /* IntelliMouse Explorer initialization sequence */
      static unsigned char rate1[] = { 200, 200, 80, };
      KBDC kbdc = sc->kbdc;
      int id;
      int i;
  
 -    /* the special sequence to enable the extra buttons and the roller. */
 +    /*
 +     * According to Microsoft's documentation for the IntelliMouse Explorer,
 +     * full functionality is activated by first sending the IntelliMouse
 +     * initialization sequence, then sending the Explorer initialization
 +     * sequence.
 +     * Reference: http://www.microsoft.com/whdc/hwdev/tech/input/5b_wheel.mspx
 +     */ 
 +
 +    /* First send the IntelliMouse init sequence */
 +    for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) {
 +        if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i])
 +            return FALSE;
 +    }
 +    /* If we've got an Explorer, it will claim to be an IntelliMouse here */
 +    id = get_aux_id(kbdc);
 +    if (id != PSM_INTELLI_ID)
 +        return FALSE;
 +
 +    /* Now send the Explorer init sequence */
      for (i = 0; i < sizeof(rate1)/sizeof(rate1[0]); ++i) {
          if (set_mouse_sampling_rate(kbdc, rate1[i]) != rate1[i])
  	    return FALSE;
      }
 -    /* the device will give the genuine ID only after the above sequence */
 +    /* If we've got an Explorer, now it will identify itself */
      id = get_aux_id(kbdc);
      if (id != PSM_EXPLORER_ID)
  	return FALSE;
 @@ -2797,11 +2839,18 @@
       * sequence; it will make the KVM think the mouse is IntelliMouse
       * when it is in fact IntelliMouse Explorer.
       */
 +
 +#if 0
 +    /*
 +     * This breaks IntelliMouse Explorer support with the Avocent
 +     * SwitchView, which DOES actually understand the Explorer protocol.
 +     */
      for (i = 0; i < sizeof(rate0)/sizeof(rate0[0]); ++i) {
          if (set_mouse_sampling_rate(kbdc, rate0[i]) != rate0[i])
  	    break;
      }
      id = get_aux_id(kbdc);
 +#endif
  
      return TRUE;
  }
 
 --------------030004040903090200060007--
 

From: Andriy Gapon <avg@icyb.net.ua>
To: bug-followup@FreeBSD.org, tpc@tomfoo.com
Cc:  
Subject: Re: kern/57230: [psm] [patch] psm(4) incorrectly identifies an IntelliMouse
 Explorer attached through an Avocent SwitchView KVM
Date: Thu, 07 Feb 2008 17:59:03 +0200

 Could you please check if the patch from the following bug helps you?
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118578
 
 It doesn't have any KVM-specific logic though.
 But it has IntelliMouse Explorer probing corrected.
 
 -- 
 Andriy Gapon
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Thu Feb 7 17:11:52 UTC 2008 
State-Changed-Why:  
Note that submitter has been asked for feedback. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=57230 
State-Changed-From-To: feedback->closed 
State-Changed-By: vwe 
State-Changed-When: Sun May 11 15:00:50 UTC 2008 
State-Changed-Why:  

We're sorry to not see any feedback received for quite some time. 
If you think this is still an issue that should be worked on, 
please provide the requested information and we'll be happy to 
re-open this ticket. 
Thank you for bringing this problem to attention! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=57230 
>Unformatted:
