From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E0yYA-0004J8-OX for qemu-devel@nongnu.org; Fri, 05 Aug 2005 05:31:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E0yY5-0004Gv-Kd for qemu-devel@nongnu.org; Fri, 05 Aug 2005 05:31:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E0yY5-0004BV-0O for qemu-devel@nongnu.org; Fri, 05 Aug 2005 05:31:29 -0400 Received: from [192.76.135.70] (helo=kurt.tools.de) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1E0yWB-00084u-4Q for qemu-devel@nongnu.org; Fri, 05 Aug 2005 05:29:32 -0400 Received: from imap3.tools.intra (imap3.tools.intra [172.20.0.8]) by kurt.tools.de (8.13.3/8.13.3) with ESMTP id j759Fnpp014581 for ; Fri, 5 Aug 2005 11:15:51 +0200 (MEST) Received: from tiger2.tools.intra (tiger2.tools.intra [172.20.0.11]) by imap3.tools.intra (8.13.1+Sun/8.13.1) with SMTP id j759Fl1N003463 for ; Fri, 5 Aug 2005 11:15:49 +0200 (MEST) Message-Id: <200508050915.j759Fl1N003463@imap3.tools.intra> Date: Fri, 5 Aug 2005 11:15:48 +0200 (CEST) From: Juergen Keil Subject: Re: [Qemu-devel] Improper mouse reset handling MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kAOBkK3w+hr6Q/ac2MOYZg== Reply-To: Juergen Keil , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > While tracking down a problem with getting X to work with the VNC > version of Qemu I discovered a problem in the way the Qemu mouse > emulation was handling mouse reset commands. Turns out, the emulation > code is a little over aggressive in dealing with reset commands for the > mouse. Since there are commands that enable and disable the mouse the > emulator, quite properly, provides this control. Unfortunately, the > emulator also interprets either a `reset' or `set to default' command to > also disable the mouse. This is wrong, neither of these commands are > supposed to affect the enabled status of the mouse Huh? Can you provide a pointer to a specification that `reset' or `set to default' must not change the state of "Data Reporting enabled/disabled"? According to , Section "Reset Mode", a `reset' command is supposed to set the "Data Reporting" to its default value, and the default value is "Data Reporting disabled"! That is, qemu's `reset' and `set to default' implementation appears to be perfectly ok, as it is now. > so that, when X sends > a `reset', no futher mouse data is sent, making it look like X is hung. Why does X (the mouse driver?) send mouse resets? Any why doesn't it enable data reporting afterwards? Isn't this a mouse driver problem in your X server? Btw. in my Solaris x86 PS/2 wheel mouse driver I've always sent an "enable" command after sending "reset" commands to the mouse, like this: /* * reset the mouse (restores to the standard ps/2 mouse protocol), * probe for (and enable) the wheel mouse protocol, and enable the * mouse. */ if ((error = psm_reset(softstate)) || (error = psm_protocol(softstate)) || (error = psm_config(softstate)) || (error = psm_enable(softstate, 1))) { qprocsoff(rq); return error; }