Ubuntu
vino package

vino: mouse cursor stays in upper left corner

Bug #337926 reported by Oliver Gerlich on 2009-03-04

This bug affects 1 person

	Status	Importance	Assigned to
Fedora	Fix Released	Medium	redhat-bugs #490984
vino (Ubuntu)	Invalid	Low	Ubuntu Desktop Bugs
Jaunty	Invalid	Low	Ubuntu Desktop Bugs
xfree86-driver-synaptics (Ubuntu)	Invalid	Medium	Unassigned
Jaunty	Invalid	Medium	Unassigned
xorg-server (Ubuntu)	Fix Released	Medium	Timo Aaltonen
Jaunty	Fix Released	Medium	Timo Aaltonen

Bug Description

Seen on Jaunty Alpha: when accessing the desktop using Vino, the mouse cursor is stuck in upper left corner of the screen. More detailed, I can move the cursor using the physical mouse attached to the Jaunty system, but as soon as on the other machine I move the mouse into VNC window, the cursor on the Jaunty machine is moved to upper left corner. Clicking with the VNC mouse works, though (it opens the Application menu which is in that corner).

I haven't seen this problem on Intrepid, only on Jaunty. Also, it only happened on a fully-installed system (installed to USB flash drive), on an EeePC 701. When using the Jaunty Live CD (booted over network) on another system and also with a bigger monitor, the problem did not occur; so apparently it doesn't happen in really all cases. On the affected system, the problem occurs every time, however.

Switching Compiz on or off hasn't helped so far. The problem also occurs with all VNC viewers I tried (krdc, vinagre, xvncviewer).

This is with Jaunty Alpha 5 with all updates installed, using vino 2.25.92-0ubuntu1 .

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:82d9]

See original description

Tags:

Related branches

lp:ubuntu/lucid/xorg-server

Revision history for this message

Oliver Gerlich (ogerlich) wrote on 2009-03-04:

Looking at vino-server with ltrace, it seems that XTestFakeMotionEvent() is called correctly:

gdk_screen_get_number(0x9dac108, 446, 0xbff06e78, 0x8057e99, 0x9df7000) = 0
XTestFakeMotionEvent(0x9d9ebe0, 0, 351, 446, 0) = 1
poll(0xbff06f08, 1, 0, 1, 45) = 1
read(18, "\005", 1) = 1
read(18, "", 5) = 5
g_type_check_instance_cast(0x9df7000, 0x9dfe7d0, 0xbff06e78, 0x8064207, 0x9e2a1c
0) = 0x9df7000
gdk_screen_get_display(0x9dac108, 464, 0xbff06e78, 0x8057e99, 0x9df7000) = 0x9da
9010
gdk_x11_display_get_xdisplay(0x9da9010, 464, 0xbff06e78, 0x8057e99, 0x9df7000) =
0x9d9ebe0
gdk_screen_get_number(0x9dac108, 464, 0xbff06e78, 0x8057e99, 0x9df7000) = 0
XTestFakeMotionEvent(0x9d9ebe0, 0, 377, 464, 0) = 1
poll(0xbff06f08, 1, 0, 1, 45) = 1

... and so on.

Using the xevent app from http://www.isv.uu.se/~ziemann/xevent/ then shows that XTestFakeMotionEvent() always sets the mouse to upper left corner, while XTestFakeRelativeMotionEvent() works correctly. Maybe a bug in the new X server?

Revision history for this message

Metzelmaennchen (admin-dasmetzelmaennchen) wrote on 2009-03-05:

Same here on Intel gma 855, using intel or vesa driver shows the above described problem.

Seems to be related to intel hardware!?
My jaunty desktop doesn't show this problem which uses an ATI card with radeonhd driver.

Revision history for this message

Bryce Harrington (bryce) wrote on 2009-03-05:

Hi ogerlich,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Changed in libxtst:
status:	New → Incomplete

Revision history for this message

Oliver Gerlich (ogerlich) wrote on 2009-03-06:

output from lspci -vvnn Edit (19.4 KiB, text/plain)

Revision history for this message

Oliver Gerlich (ogerlich) wrote on 2009-03-06:

Xorg log file Edit (47.4 KiB, text/plain)

Here's the output from lspci, and the Xorg log file from the Eeepc 701 where the bug occurs.

Btw. the other system (where the bug does not occur) is a VIA Epia board with VIA graphics chip. Also, it seems that the bug does not happen when connecting to Vino right after logging in, without moving the physical mouse at all.

Revision history for this message

Andy Owen (the-new-andy) wrote on 2009-03-07:

I get the same thing using the open source nvidia driver. Let me know if there are any more details that would be useful.

Revision history for this message

mcnicholls (nicholls-mc) wrote on 2009-03-16:

I have similar problem that i think may be related.

I can move the mouse pointer, but the local and remote pointers are offset from each other. As i move my local mouse pointer off the bottom of the vnc window, the remote pointer is still about 1/6th up the screen.

I am on an Asus 901 with Jaunty Alpha running the same version of the package as the original reporter.

Not sure if they are related. I have tried it using UltraVNC viewer 1.0.2 and TightVNC viewer 1.3.10 on WindowsXP.

Also noticed in the Xorg log posted that X is using the Synaptics mouse driver. I am pretty sure mine is as well. Could there be an issue here? (No idea how vino interacts with X so don't know if it is relevant).

Revision history for this message

mcnicholls (nicholls-mc) wrote on 2009-03-16:

Ok i just force downgraded my xserver-xorg-input-synaptics package from 0.99.3-2ubuntu3 down to 0.15.2-0ubuntu7 and the problem appeared to be fixed for me.

Can anyone else confirm the version of xserver-xorg-input-synaptics they are running?

I am not sure if this is a different bug i have come across or the same one.

Revision history for this message

Jay Goldberg (jaymgoldberg) wrote on 2009-03-17:

Xorg startup and running log. Edit (34.8 KiB, text/plain)

Confirm that I have this problem and xserver-xorg-input-synaptics, v1.1.0.

If I remove the touchpad section from xorg.conf, the Synaptics module still loads, so I had to move it:
mv /usr/lib/xorg/modules/input/synaptics.so ~

After doing this the mouse pointer no longer gets stuck in the upper left corner.

Attached Xorg.log.

Revision history for this message

In Red Hat Bugzilla #490984, Fabrice (fabrice-redhat-bugs) wrote on 2009-03-18:

#22

With current rawhide, I experience the same problem than the one described here:

https://bugs.launchpad.net/ubuntu/+source/libxtst/+bug/337926

It can be very simply reproduced with the xevent program as described in the ubuntu bug report. I filled this bug for the xorg intel driver component, instead of libXtst, because it seems to me specific to the intel driver. I could not reproduce it on another rawhide box, with the radeon driver.

Revision history for this message

In Red Hat Bugzilla #490984, Fabrice (fabrice-redhat-bugs) wrote on 2009-03-20:

#23

reassigning to xorg-x11-server, as it seems its a bug in the XTEST extension. I think that GetPointerEvents() in ProcXTestFakeInput() should be called with POINTER_SCREEN flag set.

The problem is visible on the eeepc (like described in the ubuntu bug), because of the synaptics driver, that changes pDev->valuator->axes->min_value and max_value. On my other rawhide box, these values are -1, and the bug is somewhat hidden is that case.

Bryce Harrington (bryce) on 2009-03-24

description:

updated

Revision history for this message

In Red Hat Bugzilla #490984, Peter (peter-redhat-bugs) wrote on 2009-03-25:

#24

Fixed with xorg-x11-server-1.6.0-15. Thanks for reporting.

Revision history for this message

BullCreek (jeff-openenergy) wrote on 2009-03-27:

#10

This still doesn't work as of today with latest updates installed. I'm seeing it on a Dell M1330. Jay's fix above makes it work for Vino, but then of course breaks it if you actually go to the machine.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2009-03-27:

#11

could be a bug that should be consider for jaunty since that impact the default vnc server

Changed in xfree86-driver-synaptics (Ubuntu):
assignee:	nobody → canonical-desktop-team
importance:	Undecided → Medium

Revision history for this message

Sebastien Bacher (seb128) wrote on 2009-03-27:

#12

the comments suggest that downgrading the synaptic driver fixes the issue so not really a GNOME bug

Changed in vino (Ubuntu):
assignee:	nobody → desktop-bugs
importance:	Undecided → Low
status:	New → Invalid

Revision history for this message

Rick Spencer (rick-rickspencer3) wrote on 2009-03-27:

#13

if this is tracking in Jaunty, should be assigned to someone

Changed in xfree86-driver-synaptics (Ubuntu Jaunty):
assignee:	canonical-desktop-team → bryceharrington

Bryce Harrington (bryce) on 2009-04-01

Changed in xfree86-driver-synaptics (Ubuntu Jaunty):
assignee:	bryceharrington → nobody
tags:	added: ct-rev

Revision history for this message

Jeremy Nickurak (nickurak) wrote on 2009-04-03:

#14

Same symptoms as https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/321444/ , which is currently filed on -mouse. Is that one a dupe of this then? Does this bug occur if you don't have a touchpad?

Revision history for this message

Oliver Gerlich (ogerlich) wrote on 2009-04-03:

#15

The workaround from bug 321444 works for me as well: after attaching and using an external USB mouse, XTestFakeMotionEvent works fine. Btw. instead of the xevent tool you can use the xdotool app which is available in Ubuntu repository to test for the bug (use "xdotool mousemove 100 100" as test).

Revision history for this message

Oliver Gerlich (ogerlich) wrote on 2009-04-05:

#16

Looks like there's a patch in Fedora Rawhide for this problem - see http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.6.0-xtest-pointerscreen.patch?view=markup for the patch and https://bugzilla.redhat.com/show_bug.cgi?id=490984 for the bug report.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2009-04-05:

#17

thanks for investigating on that issue

Revision history for this message

Schorschi (schorschi) wrote on 2009-04-06:

#18

So is there fix in the works? This happens on Dell 2950 with standard PS/2 mouse, RealVNC 4.1.3 Free version.

Revision history for this message

Willem Ligtenberg (wligtenberg) wrote on 2009-04-06:

#19

I will try to patch it with the patched provided here:
http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.6.0-xtest-pointerscreen.patch?view=markup

Changed in libxtst (Ubuntu Jaunty):
assignee:	nobody → wligtenberg
status:	Incomplete → In Progress

Revision history for this message

Timo Aaltonen (tjaalton) wrote on 2009-04-06:

#20

I'll add the patch to xserver.

Changed in xfree86-driver-synaptics (Ubuntu Jaunty):
status:	New → Invalid
affects:	libxtst (Ubuntu Jaunty) → xorg-server (Ubuntu Jaunty)
Changed in libxtst (Ubuntu Jaunty):
assignee:	wligtenberg → tjaalton
Changed in xorg-server (Ubuntu Jaunty):
importance:	Undecided → Medium

Bug Watch Updater (bug-watch-updater) on 2009-04-07

Changed in fedora:
status:	Unknown → Fix Released

Bryce Harrington (bryce) on 2009-04-07

tags:

removed: ct-rev

Revision history for this message

Launchpad Janitor (janitor) wrote on 2009-04-07:

#21

This bug was fixed in the package xorg-server - 2:1.6.0-0ubuntu11

---------------
xorg-server (2:1.6.0-0ubuntu11) jaunty; urgency=low

  * Add 175_set_pointer_screen_in_xtestfakeinput.patch: Fixes issue when
    using Vino, mouse cursor can get stuck in the upper left corner of the
    screen. The POINTER_SCREEN flag must be set explicitly for XTest core events to avoid
    out-of-range events when the lastSlave was an SD with an explicit axis range.
    Device events sent through XTest don't need this flag, they are expected to be
    in the valuator range of the device anyway.
    (LP: #337926)

-- Bryce Harrington <email address hidden> Mon, 06 Apr 2009 17:22:35 -0700