Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#36333 - [tigervnc] local mouse cursor does not match appearance of remote mouse cursor

Attached to Project: Community Packages
Opened by Lewis Pike (ntwk) - Tuesday, 30 July 2013, 14:38 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 24 September 2013, 10:16 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Previously, on tigervnc 1.2.0-13, the appearance of mouse cursor displayed in the vncviewer window matched the appearance of the mouse cursor on the remote machine. When the mouse would roll over areas where the appearance of the cursor would typically change, such as the edge of windows on a Windows machine, the appearance of the local X11 mouse cursor would change accordingly.

On tigervnc 1.3.0-2, the mouse cursor drawn is that of the local X server and it does not match the appearance of what would typically be the mouse cursor of the remote machine. Further, the appearance of the mouse cursor does not change, regardless of its location in the vncviewer window.

Additional info:

I am currently running tigervnc 1.3.0-2 and connecting to two remote Windows machines with the following specifications:

remote 1: Windows 7 SP1 running TightVNC 2.0.3
remote 2: Windows XP Sp3 running TightVNC 2.7.7.0

Steps to reproduce:

1. Use vncviewer to connect to a Windows machine running a TightVNC server.
2. Note that the local X11 mouse cursor fails to match the appearance of the remote mouse cursor.
This task depends upon

Closed by  Sergej Pupykin (sergej)
Tuesday, 24 September 2013, 10:16 GMT
Reason for closing:  Fixed
Comment by U (Gusar) - Thursday, 01 August 2013, 10:45 GMT
I'm not exactly sure, but could be another fallout of using an unpatched fltk: https://bugs.archlinux.org/task/36186 <- there's a cursor patch among those, so chances are high that a patched fltk will do the trick. Either use the patch and PKGBUILD from that bug, or there's fltk-snapshot in AUR.
Comment by Lewis Pike (ntwk) - Tuesday, 06 August 2013, 19:32 GMT
The PKGBUILD and patch provided at https://bugs.archlinux.org/task/36186 failed to resolve the issue in my case.

However, the issue appears to be fixed when using fltk-snapshot & tigervnc-svn available in the AUR.
Comment by U (Gusar) - Wednesday, 07 August 2013, 09:25 GMT
Did you recompile tigervnc (the regular one, not the svn from AUR) after installing the fltk from bug #36186?

I'm asking because
1) tigervnc needs to be compiled with a patched fltk, just changing fltk without recompiling tigervnc afterwards will not do anything
2) I want to know whether there's something wrong with the patch at bug #36186. It should work, but I want to know for sure, because relying on fltk-snapshot from AUR should be just a temporary measure.
Comment by Lewis Pike (ntwk) - Wednesday, 07 August 2013, 20:53 GMT
In fact, It seems that I did not recompile the tigervnc package in the community repo against the patched fltk. Thanks for catching that.

After recompiling the tigervnc-1.3.0-2 available in community against the patched fltk, my cursor problem is fixed. So, it looks like this is related to issue  FS#36186 .

Loading...