architecture: 0.934
virtual: 0.932
semantic: 0.928
network: 0.928
PID: 0.922
graphic: 0.918
device: 0.910
performance: 0.909
assembly: 0.907
debug: 0.905
risc-v: 0.901
ppc: 0.900
arm: 0.898
boot: 0.897
vnc: 0.890
user-level: 0.888
permissions: 0.877
VMM: 0.876
hypervisor: 0.875
register: 0.870
peripherals: 0.852
mistranslation: 0.851
socket: 0.851
KVM: 0.843
TCG: 0.830
x86: 0.816
files: 0.799
kernel: 0.791
i386: 0.432

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...