Bug 1556856
| Summary: | virtio-input: Windows vioinput guest driver tablet input bug reported upstream (QEMU) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sameeh Jubran <sjubran> |
| Component: | virtio-win | Assignee: | Sameeh Jubran <sjubran> |
| virtio-win sub component: | virtio-win-prewhql | QA Contact: | Peixiu Hou <phou> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | juzhang, lijin, michen, sjubran, vrozenfe |
| Version: | 7.6 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
NO_DOCS
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 16:21:50 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sameeh Jubran
2018-03-15 11:34:43 UTC
How to reprouce: * Run qemu with the device virtio-tablet-pci attached. * Install vioinput driver for the device - build 145 * Open a scrolable document, a webpage for example. * Try to scroll using the mouse wheel -> doesnt work This pull request fixes the issue: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/257 It has been already merged. Hi Sameeh,
I tried to reproduce this issue on win2016 guest, used virtio-win-prewhql-145 build, but cannot reproduce it, the mouse wheel works normally and the left/right button also works normally.
I'm not sure which type mouse you used, here I used a traditional mouse(have left&right button and a wheel) to test.
Could you help to tell which os you tested and which type mouse you used? Or any other I'm not considered info? thanks a lot~
Used qemu command line as follows:
MALLOC_PERTURB_=1 /usr/libexec/qemu-kvm \
-name 'avocado-vt-vm1' \
-sandbox off \
-machine pc \
-nodefaults \
-vga std \
-device pvpanic,ioport=0x505,id=idEkdk5e \
-drive id=drive_image1,if=none,snapshot=on,aio=threads,cache=none,format=raw,file=win2016-64-virtio.raw \
-device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=0x4 \
-drive id=drive_stg,if=none,snapshot=off,aio=threads,cache=none,format=raw,file=data1.raw \
-device virtio-blk-pci,id=stg,drive=drive_stg,bootindex=1,serial=TARGET_DISK0,bus=pci.0,addr=0x5 \
-device virtio-net-pci,mac=9a:d0:d1:d2:d3:d4,id=idvFGgP3,vectors=4,netdev=id5tNwA8,bus=pci.0,addr=0x6 \
-netdev tap,id=id5tNwA8,vhost=on \
-m 4096 \
-smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \
-cpu 'Broadwell',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \
-vnc :0 \
-rtc base=localtime,clock=host,driftfix=slew \
-boot menu=off,strict=off,order=cdn,once=c \
-enable-kvm \
-monitor stdio \
-device virtio-tablet-pci,id=tablet0,serial=virtio-tablet
Used versions:
kernel-3.10.0-836.el7.x86_64
qemu-kvm-rhev-2.10.0-18.el7.x86_64
virtio-win-prewhql-141
seabios-1.10.2-5.el7.x86_64
Best Regards~
Peixiu
(In reply to Peixiu Hou from comment #4) > Hi Sameeh, > > I tried to reproduce this issue on win2016 guest, used > virtio-win-prewhql-145 build, but cannot reproduce it, the mouse wheel works > normally and the left/right button also works normally. > I'm not sure which type mouse you used, here I used a traditional mouse(have > left&right button and a wheel) to test. > > Could you help to tell which os you tested and which type mouse you used? Or > any other I'm not considered info? thanks a lot~ > > Used qemu command line as follows: > MALLOC_PERTURB_=1 /usr/libexec/qemu-kvm \ > -name 'avocado-vt-vm1' \ > -sandbox off \ > -machine pc \ > -nodefaults \ > -vga std \ > -device pvpanic,ioport=0x505,id=idEkdk5e \ > -drive > id=drive_image1,if=none,snapshot=on,aio=threads,cache=none,format=raw, > file=win2016-64-virtio.raw \ > -device > virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=0x4 \ > -drive > id=drive_stg,if=none,snapshot=off,aio=threads,cache=none,format=raw, > file=data1.raw \ > -device > virtio-blk-pci,id=stg,drive=drive_stg,bootindex=1,serial=TARGET_DISK0, > bus=pci.0,addr=0x5 \ > -device > virtio-net-pci,mac=9a:d0:d1:d2:d3:d4,id=idvFGgP3,vectors=4,netdev=id5tNwA8, > bus=pci.0,addr=0x6 \ > -netdev tap,id=id5tNwA8,vhost=on \ > -m 4096 \ > -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \ > -cpu > 'Broadwell',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \ > -vnc :0 \ > -rtc base=localtime,clock=host,driftfix=slew \ > -boot menu=off,strict=off,order=cdn,once=c \ > -enable-kvm \ > -monitor stdio \ > -device virtio-tablet-pci,id=tablet0,serial=virtio-tablet > > Used versions: > kernel-3.10.0-836.el7.x86_64 > qemu-kvm-rhev-2.10.0-18.el7.x86_64 > virtio-win-prewhql-141 > seabios-1.10.2-5.el7.x86_64 > > Best Regards~ > Peixiu I can reproduce easily with build 141 and it should be reproduceable with 145 as well. I am using Windows 7 client and connected through spice to the client. The command line I used: qemu-system-x86_64 \ -netdev tap,id=hostnet6,script=world_bridge_standalone.sh,downscript=no,ifname=cc1_78 \ -device e1000,netdev=hostnet6,mac=56:cc:c1:01:c6:21,bus=pci.0,id=cc1_78 \ -netdev tap,vhost=on,id=hostnet7,script=world_bridge_standalone.sh,downscript=no,ifname=cc1_76,queues=4 \ -device virtio-net,netdev=hostnet7,mac=56:cc:c1:04:26:21,id=cc1_76,vectors=10,mq=on \ -name netkvm \ -enable-kvm \ -m 2G \ -smp 4 \ -drive file=/home/sameeh/images/win7_x64_netdev.qcow2,if=ide,serial=111071,id=drivex \ -global PIIX4_PM.disable_s3=0 \ -global PIIX4_PM.disable_s4=0 \ -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0 \ -spice port=6111,disable-ticketing \ -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \ -chardev spicevmc,name=vdagent,id=vdagent \ -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0 \ -chardev socket,path=/tmp/qga22.sock,server,nowait,id=qga0 \ -device virtio-serial \ -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \ -device virtio-tablet-pci \ -monitor stdio Hi Sameeh, Could you help tell which the qemu version you used? I tried to boot the guest with "qemu-system-x86_64", but it cannot booted; I tried test with "/usr/libexec/qemu-kvm" on win7-32, but cannot reproduce this issue, the boot command line as follows: /usr/libexec/qemu-kvm \ -netdev tap,id=hostnet0,vhost=on,vhostforce=off \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:83:66:77:88:66,bus=pci.0,addr=0x3,status=on \ -name netkvm \ -enable-kvm \ -m 2G \ -smp 4 \ -drive file=/home/function_7.5/vioinput/win7-32-pc.qcow2,if=ide,serial=111071,id=drivex \ -drive file=/home/virtio-win/virtio-win-prewhql-141.iso,media=cdrom,id=cdrom,if=none -device ide-drive,drive=cdrom,bootindex=2 \ -global PIIX4_PM.disable_s3=0 \ -global PIIX4_PM.disable_s4=0 \ -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0 \ -spice port=6111,disable-ticketing \ -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 \ -chardev spicevmc,name=vdagent,id=vdagent \ -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,name=com.redhat.spice.0 \ -chardev socket,path=/tmp/qga22.sock,server,nowait,id=qga0 \ -device virtio-serial \ -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \ -device virtio-tablet-pci \ -monitor stdio Used versions: kernel-3.10.0-836.el7.x86_64 qemu-kvm-rhev-2.10.0-18.el7.x86_64 virtio-win-prewhql-141 seabios-1.10.2-5.el7.x86_64 qxl-0.1-21 Hi Sameeh, For this issue, I also have follows try: Steps as comment#8, for the step1, connect the windows server1 through rdesktop from a linux host. for the step6, connect the windows vm(win7-32 guest) through remote desktop on windows server2. With build 141, Checked the virtio tablet function, on the IE web page, the mouse wheel works normally, on Device manager -> view "Resources by connection" page, the mouse wheel works normally, on "Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings" page, if I don't click any button on this page, the mouse wheel cannot work, if I click one button on this page, the mouse wheel can work normally. Tried with build 145 and 148 and none virtio-table, all hit this situation. Could you help to confirm if it's reproduced this bug? If not, could you help to tell how do you connect you guest from windows server? I use remote desktop here. And also can help to check my test step, if not correct, pls correct me~ Thanks a lot~ I am actually running Windows on the laptop that I'm using and from there connected to a remote desktop and to the vm through spice. I think you should try using a mouse from a physical Windows machine that may be the case. I can reproduce easily with no issues. Maybe this could be the mouse that I used which could exposes a different configuration than yours to the guest. Hi Sameel Jubran, I tried to use a mouse from a physical Windows machine, but it's so sorry, still not reproduced this issue, tried with virtio-win-prewhql-141&145, the same result. I tried test with 3 type mouses, all cannot reproduce this issue. 1. HP, HQ-TRE, 71004 Boeblingen, Germany P/N:672652 2. Lenovo MOGOUO ASM P/N:0A36101 FRU P/N:03x6311 3. Dell M/N: M-UAR DEL7 P/N:XN966 Best Regards~ Peixiu (In reply to Sameeh Jubran from comment #10) > I am actually running Windows on the laptop that I'm using and from there > connected to a remote desktop and to the vm through spice. Hi, I have a question here, what do you mean "to the vm through spice"? if used any tools? I booted vm command line use "-spice port=6111,disable-ticketing", and I used remote desktop to connect to the windows vm from a windows server. Thanks~ >I think you > should try using a mouse from a physical Windows machine that may be the > case. I can reproduce easily with no issues. (In reply to Peixiu Hou from comment #13) > (In reply to Sameeh Jubran from comment #10) > > I am actually running Windows on the laptop that I'm using and from there > > connected to a remote desktop and to the vm through spice. > > Hi, I have a question here, what do you mean "to the vm through spice"? if > used any tools? I booted vm command line use "-spice > port=6111,disable-ticketing", and I used remote desktop to connect to the > windows vm from a windows server. To connect to the VM you MUST use Remote Viewer or any other spice client and not Remote Desktop. I have reproduced the issue again using my Laptop's touchpad so this is 100% reproduce-able for me. > > Thanks~ > > >I think you > > should try using a mouse from a physical Windows machine that may be the > > case. I can reproduce easily with no issues. (In reply to Sameeh Jubran from comment #14) > (In reply to Peixiu Hou from comment #13) > > (In reply to Sameeh Jubran from comment #10) > > > I am actually running Windows on the laptop that I'm using and from there > > > connected to a remote desktop and to the vm through spice. > > > > Hi, I have a question here, what do you mean "to the vm through spice"? if > > used any tools? I booted vm command line use "-spice > > port=6111,disable-ticketing", and I used remote desktop to connect to the > > windows vm from a windows server. > > To connect to the VM you MUST use Remote Viewer or any other spice client > and not Remote Desktop. > > I have reproduced the issue again using my Laptop's touchpad so this is 100% > reproduce-able for me. > Hi, I tried to reproduce this issue many times with Remote Viewer(from windows os), but also cannot reproduce this issue, the step same with you mentioned before. Tried with virtio-win-prewhql-141&145&148, all cannot reproduce this issue. > > > > Thanks~ > > > > >I think you > > > should try using a mouse from a physical Windows machine that may be the > > > case. I can reproduce easily with no issues. Hi Sameeh, As QE can not reproduce this issue, could we set it to verified according to your result? (In reply to lijin from comment #16) > Hi Sameeh, > > As QE can not reproduce this issue, could we set it to verified according to > your result? Yes, let's close it Change status to verified according to comment#16 and comment#17 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3413 |