qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Qemu-devel] Improper mouse reset handling


From: Dugger, Donald D
Subject: RE: [Qemu-devel] Improper mouse reset handling
Date: Fri, 5 Aug 2005 08:21:13 -0700

Interesting.  You're right, the protocol explicitly says that both
`reset' and `set to default' are supposed to disable the mouse.  I have
to admit, I was basing my patch on the fact that, in tracing the
commands I received from the X server, I saw a `reset' that was not
followed by an `enable'.  I'll have to go back and find out where the
missing `enable' command got dropped or an unexpected `reset' got added.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
address@hidden
Ph: 303/440-1368 

>-----Original Message-----
>From: address@hidden 
>[mailto:address@hidden
>] On Behalf Of Juergen Keil
>Sent: Friday, August 05, 2005 3:16 AM
>To: address@hidden
>Subject: Re: [Qemu-devel] Improper mouse reset handling
>
>
>> 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
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]