graphic: 0.963
debug: 0.958
performance: 0.935
kernel: 0.859
mistranslation: 0.833
boot: 0.819
architecture: 0.815
device: 0.805
user-level: 0.795
semantic: 0.768
permissions: 0.692
peripherals: 0.666
network: 0.653
VMM: 0.551
register: 0.541
PID: 0.533
socket: 0.532
arm: 0.511
risc-v: 0.504
ppc: 0.503
vnc: 0.471
files: 0.421
TCG: 0.354
hypervisor: 0.329
x86: 0.289
i386: 0.246
assembly: 0.233
KVM: 0.193
virtual: 0.192

Incorrect vertical mouse leaps on qemu-system-sparc
Description of problem:
In openwin (i.e. X) if you turn the scrollwheel on the mouse 1 click the cursor jumps almost all of the way down the screen. Similarly, just pressing the scroll wheel (middle click) multiple times will sometimes produce similar behavior but the cursor doesn't jump as far.
Steps to reproduce:
- Boot Solaris and log in
- capture the mouse by clicking on the screen
- position the mouse cursor near the top of the screen (just so you can see how far it jumps)
- click the scroll wheel up or down one click and observe the cursor jump downward
Additional information:
The issue is independent of which graphic display is used -- sdl, gtk and vnc all do the same thing. Debugging so far suggests that the problem is related to the fact that `sunmouse_event` in `escc.c` is sending a flood of duplicate events in response to the mouse scroll action. My surmise is that this is causing one byte to be dropped from the 5 byte mouse protocol expected by the Solaris kernel and that it is interpreting a sync byte as a vertical motion byte.

`sunmouse_event` should not send events with only `dz` non-zero and no button changes. The Mouse Systems Corp spec for the the Sun mouse says that it never sends duplicate events (i.e. an event is produced only if there is non-zero `dx` or `dy` or there has been a button state change), and the mouse protocol has no support for `dz` events.

I will propose a patch shortly to enforce this (and which has seemingly fixed the problem).