> 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 <URL:http://www.computer-engineering.org/ps2mouse/>, 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; } _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
