Re: [Qemu-devel] Improper mouse reset handling

[Juergen Keil]

> 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;
    }