diff options
Diffstat (limited to 'results/classifier/105/network/894037')
| -rw-r--r-- | results/classifier/105/network/894037 | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/results/classifier/105/network/894037 b/results/classifier/105/network/894037 new file mode 100644 index 000000000..f05ab96db --- /dev/null +++ b/results/classifier/105/network/894037 @@ -0,0 +1,125 @@ +semantic: 0.928 +network: 0.928 +graphic: 0.918 +other: 0.916 +device: 0.910 +assembly: 0.907 +boot: 0.897 +vnc: 0.890 +instruction: 0.889 +mistranslation: 0.851 +socket: 0.851 +KVM: 0.843 + +With VNC, "-usbdevice tablet" no longer makes mouse pointers line up + +I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. + +Here's how I'm booting WinXP: + +qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & + +The Windows install hasn't changed, only qemu. + +I'm running this version of QEMU: + +QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard + +I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. + +Also observed on Fedora 16, qemu-kvm-0.15.1-3.fc16.x86_64 +https://bugzilla.redhat.com/show_bug.cgi?id=754149 + + +Also observed on Ubuntu, extra/qemu-kvm 0.15.0-2 +https://bugs.launchpad.net/qemu/+bug/894037 + + +This bug isn't getting any attention, but it's a total show-stopper for me. It priority should be raised to Critical. I cannot use any of my VMs at all. Please help! + +Thanks. + + +On Mon, Dec 19, 2011 at 3:23 PM, Timothy Miller <email address hidden> wrote: +> This bug isn't getting any attention, but it's a total show-stopper for +> me. It priority should be raised to Critical. I cannot use any of my +> VMs at all. Please help! + +Have you checked that the guest operating system is using the USB +tablet as the mouse input? If it is falling back to the PS/2 mouse +then you will not get synced mouse pointers. + +Stefan + + +That's easier said than done, because it's pretty unusable. And as I said, the OS didn't change. QEMU got updated, and then it broke. So if it was or wasn't using the tablet before, then it still is or isn't now. Either way, it used to work. + +I'll see what I can figure out about what it thinks its input device is. + +Ok, I'm seeing two devices that Windows XP doesn't recognize. One is "QEMU USB Tablet", and the other is "VGA Controller (VGA Compatible)". It doesn't appear to have drivers for these. + +Both of these used to work just fine. I'm not sure why it's complaining about either one, since things were fine before. Did identifying information about these devices change over an update? Is there a way to get back the old behavior from QEMU? + + +Can you please upgrade to 1.0 and see if that fixes the problem. The following patch should fix your problem (and is present in 1.0): + +commit 21635e121ae0f0ab7874152a7c2f96e9d8cd642f +Author: Gerd Hoffmann <email address hidden> +Date: Tue Aug 9 12:35:57 2011 +0200 + + usb/hid: add hid_pointer_activate, use it + + HID reorganziation broke the usb tablet in windows xp. The reason is + that xp activates idle before it starts polling, which creates a + chicken-and-egg issue: We don't call hid_pointer_poll because there are + no pending events. We don't get any events because the activation code + in hid_pointer_poll is never executed and thus all pointer events are + routed to the PS/2 mouse by qemu. + + Fix this by creating a hid_pointer_activate function and call it from + usb-hid when the guest sets the idle state. + + Signed-off-by: Gerd Hoffmann <email address hidden> + + +Windows XP does not have a VESA compatible driver by default. -std vga therefore won't work out of the box for Windows XP. This is not a regression, this has always been the case. + +This is strange. On a lark, I right-clicked the unknown tablet device and told Windows to find a driver for it. It told me it couldn't find a better one than what I already had, and then it appeared as a HID-compliant device. Now it works fine! + +I'm thinking that what has happened is that some characteristic (name? PCI ID?) of the tablet device changed, and Windows XP doesn't automatically adapt to the "new hardware", but if you fiddle with it, Windows will decide to attach the right driver. + +It works fine for me now, but that doesn't completely invalidate the bug. At the very least, the bug is that this change wasn't documented well. I tried googling for this, but I found nothing relevant. + + +Is qemu 1.0 headed for fedora-rawhide any time soon? I only see qemu-0.15.1-3.fc17 available... + +From the Qemu Monitor, try looking at "info mice" +I'm not exactly sure ho to access the Qemu Monitor from VNC. You might have +to start qemu with additional parameters: -monitor +telnet:localhost:12341,server,nowait +then use "telnet localhost 12341" to access the monitor... + +On Monday 19 December 2011 18:54:19 Timothy Miller wrote: +> That's easier said than done, because it's pretty unusable. And as I +> said, the OS didn't change. QEMU got updated, and then it broke. So if +> it was or wasn't using the tablet before, then it still is or isn't now. +> Either way, it used to work. +> +> I'll see what I can figure out about what it thinks its input device is. + + +From VNC, you access the monitor via Ctrl-Alt-2 and Ctrl-Alt-1. It works the same. + +"info mice" gives me: +* Mouse #1: QEMU USB Tablet (absolute) + Mouse #0: QEMU PS/2 Mouse + +As for Windows and VESA, I'm not sure what it's doing, but I can select all sorts of resolutions, like 1440x900. The default adaptor in the past (cirrus?) was much more limited. It must be doing some kind of BIOS thunking, but I bet it would be more efficient to have a VESA driver, no? + + +According to comment #6 this has been fixed in version 1.0 ... is there still something left to do here? + +There hasn't been a reply to my question in the last comment within +months, so I assume nobody cares about this anymore. So I'm closing this +ticket now... + |