Bug 2781 - Mouse pointer disappear when I work with vncviewer
Summary: Mouse pointer disappear when I work with vncviewer
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Mouse (show other bugs)
Version: 6.8.1
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-21 04:30 UTC by Alexander N. treyner
Modified: 2018-08-10 20:58 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Alexander N. treyner 2005-03-21 04:30:27 UTC
When I leave vncviewer or Remote Desktop (using vnc protocol) opened for a long
time (more than 10 min) - mouse pointer disappear. 
I'm using fc3 on IBM R50 laptop with USB mouse and TrackPoint. When pointer
disappear I can not use not USB mouse nor TrackPoint, but if I switch to another
text console I got my mouse back.
Comment 1 FreeDesktop Bugzilla Database Corruption Fix User 2005-06-14 10:37:12 UTC
I can reproduce this bug at will:
I use vnc on my linux workstation to connect by vnc to a windows computer
running UltraVNC server. I don't know if the server is important, since the bug
exhibits itself at both places.

One detail that IS important is that vncviewer must be running FULLSCREEN,
otherwise the bug will NOT manifest itself.

At that point, if I leave both computers idle until both their screen-savers
come on, the bug happens.

If I then move the mouse or touch the keyboard (makes no difference which I
pick), the mouse pointer will seem to have disappeared on BOTH computers.

The only way I've found in which you can extricate yourself from this is by
using the following method:

I press CTRL+ESC, causing the Windows START button to act as if it had been
clicked with the mouse. This has the side-effect of setting focus to the START
button, I then press tab until the focus-rectangle enters the system-tray, I tab
to the VNC server's tray-icon, press SHIFT+F10, and from the pop-up menu that
appears, I use the arrow-keys to select "Kill All Clients"

This drops me back onto my Linux workstation's desktop. UNFORTUNATELY, there is
still NO MOUSE POINTER.

The trick now is to let xscreensaver come on.

The moment the screen-saver comes on, I move the mouse and VOILA -
Everything is back to normal. No bug.

So there is an interaction between X11, VNC (client) and xscreensaver.

The reason I think X11 is involved is because I have never seen this bug when
the roles are reversed (Windows as the workstation running the VNC client)

Comment 2 Hans Deragon 2006-01-16 07:13:48 UTC
I confirm this behavior on FC4.

Here is the version info:

VNC Viewer Free Edition 4.1.1 for X - built Aug  4 2005 06:43:41

However, I do not get the mouse back when going to console.  I have to 'killall
vncviewer' in the console and then return to X, wait for the screensaver to kick
in and only then the mouse returns.

I suspect that the problem is related with the screensaver.
Comment 3 Francois-Xavier KOWALSKI 2006-01-28 01:58:19 UTC
I confirm this issue on the following configurations:

- FC2 with Xorg 2D accelerated drivers
- FC3 with Nvidia 3D accelerated drivers
- FC4 with ATI 3D accelerated drivers

Conditions: not only connected to a VNC server, but also to an RDP one (MS
Windows Remote Display Protocol) using rdesktop.

I am using the "blank" screen-saving of xscreensaver.  The proposed work-around
(killall rdesktop & wait for anoth resume from screensaver) does not work for
me.  I always have to kill (Ctrl+Backspace) the X server & restart my whole
environment (*extremelly* annoying).
Comment 4 Daniel Stone 2007-02-27 01:25:52 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 5 chemtech 2013-03-15 14:32:06 UTC
Alexander N. treyner 
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Comment 6 GitLab Migration User 2018-08-10 20:58:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-mouse/issues/2.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.