vncviewer and broken mouse behaviour - is there a fix?

vncviewer and broken mouse behaviour - is there a fix?

[Tomasz Chmielewski]

Currently, using mouse with vncviewer is a bit broken: "VNC mouse 
pointer" moves much faster than the real mouse pointer.

As a result, it's not always easy to point&click in the right area.

Is there a workaround for that?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: vncviewer and broken mouse behaviour - is there a fix?

[Avi Kivity]

Tomasz Chmielewski wrote:
> Currently, using mouse with vncviewer is a bit broken: "VNC mouse 
> pointer" moves much faster than the real mouse pointer.
>
> As a result, it's not always easy to point&click in the right area.
>
> Is there a workaround for that?
>

-usbdevice tablet

-- 
error compiling committee.c: too many arguments to function

Re: vncviewer and broken mouse behaviour - is there a fix?

[Tomasz Chmielewski]

Avi Kivity schrieb:
> Tomasz Chmielewski wrote:
>> Currently, using mouse with vncviewer is a bit broken: "VNC mouse 
>> pointer" moves much faster than the real mouse pointer.
>>
>> As a result, it's not always easy to point&click in the right area.
>>
>> Is there a workaround for that?
>>
> 
> -usbdevice tablet

I already use it:

qm> info usb
   Device 0.0, Speed 12 Mb/s, Product QEMU USB Tablet

I wonder why it doesn't work for me (with kvm-83)?

Do I have to configure something special on the quest?
On my guests, "vnc mouse pointer" moves much faster than the real one - 
both when X is started, but also in console, with gpm started.

-- 
Tomasz Chmielewski
http://wpkg.org

RE: vncviewer and broken mouse behaviour - is there a fix?

[Dietmar Maurer]

use the vmmouse driver (instead of mouse) for X

> Do I have to configure something special on the quest?
> On my guests, "vnc mouse pointer" moves much faster than the real one -
> both when X is started, but also in console, with gpm started.

Re: vncviewer and broken mouse behaviour - is there a fix?

[Tomasz Chmielewski]

Dietmar Maurer schrieb:
> use the vmmouse driver (instead of mouse) for X

Assuming it'll work, what about console? Well, I guess I could live with it.

But what about Windows guests? I've heard unconfirmed rumours that 
Windows doesn't run X (and have no console mode, either).


>> Do I have to configure something special on the quest?
>> On my guests, "vnc mouse pointer" moves much faster than the real one -
>> both when X is started, but also in console, with gpm started.


-- 
Tomasz Chmielewski
http://wpkg.org

RE: vncviewer and broken mouse behaviour - is there a fix?

[Dietmar Maurer]

> Dietmar Maurer schrieb:
> > use the vmmouse driver (instead of mouse) for X
> 
> Assuming it'll work, what about console? Well, I guess I could live
> with it.
> 
> But what about Windows guests? I've heard unconfirmed rumours that
> Windows doesn't run X (and have no console mode, either).

Windows guests use the usb tablet driver.

- Dietmar

Re: vncviewer and broken mouse behaviour - is there a fix?

[Daniel P. Berrange]

On Thu, Feb 26, 2009 at 01:34:03PM +0100, Tomasz Chmielewski wrote:
> Avi Kivity schrieb:
> >Tomasz Chmielewski wrote:
> >>Currently, using mouse with vncviewer is a bit broken: "VNC mouse 
> >>pointer" moves much faster than the real mouse pointer.
> >>
> >>As a result, it's not always easy to point&click in the right area.
> >>
> >>Is there a workaround for that?
> >>
> >
> >-usbdevice tablet
> 
> I already use it:
> 
> qm> info usb
>   Device 0.0, Speed 12 Mb/s, Product QEMU USB Tablet
> 
> I wonder why it doesn't work for me (with kvm-83)?
> 
> Do I have to configure something special on the quest?

Yes, you need to make sure Xorg has activated the USB tablet, and is using
it in absolute coordinate mode. If Xorg is using the shared stream
/dev/input/mice, or not configured absolute mode, then the mouse pointer
will still not track 1-for-1.

In current state of the art Xorg, this should all happen automatically
if hal has labelled the USB tablet with 'input.x11_driver = evdev'. The
FDI rules for HAL are only just added though, so your distro is probably
missing them. See this bug for example of FDI rule you need to make 
Xorg auto-configure correctly

https://bugzilla.redhat.com/show_bug.cgi?id=487025

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: vncviewer and broken mouse behaviour - is there a fix?

[Stuart Jansen]

On Thu, 2009-02-26 at 12:04 +0100, Tomasz Chmielewski wrote:
> Currently, using mouse with vncviewer is a bit broken: "VNC mouse 
> pointer" moves much faster than the real mouse pointer.
> 
> As a result, it's not always easy to point&click in the right area.
> 
> Is there a workaround for that?

I'm not sure if this is the bug you're referring to or not, but this
might have just been fixed in gtk-vnc.

http://mail.gnome.org/archives/gtk-vnc-list/2009-February/msg00003.html

Re: vncviewer and broken mouse behaviour - is there a fix?

[duck]

Have you turned mouse acceleration off in your guest OS?

If not, then the mouse pointer is not guaranteed to move one distance unit 
inside the guest for every distance unit it moves in real life. (Sorry, an 
unscientific explanation, but I hope it suffices.) In fact, when you move
the mouse quickly, the pointer will move even more quickly ;-) This makes 
it impossible for QEMU reliably to coordinate the host and guest mouse 
locations.

Under Windows, IIRC, you can go to:

   Settings|Control Panel|Mouse|Pointer Options

and to turn off the (ironically named) tick-box option:

   [ ] Enhance pointer precision

Under X, try:

   $ xset m 1

which sets the mouse "acceleration multiplier" to 1, thus keeping the 
mouse positioning host-pixel-perfect both in regular and accelerated 
modes.

For gpm, try adding the command line qualifier:

   -a 1

for similar reasons to the xset command above.

HtH.