cursor issues on OSX

[totaam]

Issue migrated from trac ticket # 438

component: platforms | priority: major | resolution: fixed | keywords: osx

2013-10-09 06:53:50: totaam created the issue

---

Apparently:

• the cursor disappears (note: even without GL enabled)
• sometimes it is the wrong size..

I am creating a new ticket instead of overloading #189, though it may well be related.

---

Summary of how cursor handling works:

We send the cursor pixels (and name..) in the size we get from the X11 server,
which is often bigger than what we need since we use a larger virtual screen (max res is usually 5120x3200) and we scale it down to the size that the system tells us is the usual size:

size = gdk.display_get_default().get_default_cursor_size()

On Linux (and win32?), this is often less of a problem because we can use cursors by name and so we just request the cursor named 'XYZ' without having to worry about its size. We only have to deal with cursor pixels (and scaling them) when the application uses a custom cursor.
With gtk on OSX... I don't think this works? So maybe we always end up using the pixels?

[totaam]

2013-10-09 06:55:54: totaam changed owner from antoine to afarr

[totaam]

2013-10-09 06:55:54: totaam commented

---

To help in debugging, those that can reproduce the issue should post the output of the client with the following patch applied on top of r4431:

@@ -339,7 +339,7 @@
                 x = max(0, min(xhot, w-1))
                 y = max(0, min(yhot, h-1))
                 size = gdk.display_get_default().get_default_cursor_size()
-                log("new cursor at %s,%s with serial=%s, dimensions: %sx%s, len(pixels)=%s, default cursor size is %s", xhot,yhot, serial, w,h, len(pixels), size)
+                log.info("new cursor at %s,%s with serial=%s, dimensions: %sx%s, len(pixels)=%s, default cursor size is %s", xhot,yhot, serial, w,h, len(pixels), size)
                 if size>0 and (size<w or size<h):
                     ratio = float(max(w,h))/size
                     pixbuf = pixbuf.scale_simple(int(w/ratio), int(h/ratio), gdk.INTERP_BILINEAR)

Alternatively, you can also run the client in debug mode (-d all) and grep the output for get_default_cursor_size. (still needs r4431 or later)

[totaam]

2013-12-05 23:41:13: afarr commented

---

Testing with osx client 0.11.0r4855, fedora 19 server 0.11.0r4840 ...

I am not seeing any instances of the cursor size changing, but I am finding that the cursor disappears when scrolling over xterms or browser address bars & links (text links, graphic links, graphic video player links, any links).

The disappearance only occurs when an xpra window (xterm or browser) is in focus. When focus is, instead, on a local application then the mouse scrolls over xpra session windows as expected.

I'm attaching two sets of -d all output. No. 1 I was scrolling over and changing focus back and forth with xpra xterm and chrome windows, No. 2 all I did was shift focus to an xterm and slide the cursor "underneath" it a few times.

cmd-f for 'get_default_cursor_size' turns up no results, but searching for 'new cursor' turns up a few... though I'm not sure if that's expected or not.

I didn't get a chance to try the patch you provided, but there doesn't seem to be any cursor size instances occurring, would something to log 'new cursor' instances (or something perhaps more relevant) be of use?

[totaam]

2013-12-05 23:56:17: afarr uploaded file xpra_mouse_cursor_test1.txt (356.3 KiB)

osx client mouse cursor test, disappearung under xterms and chrome

[totaam]

2013-12-05 23:57:48: afarr uploaded file xpra_mouse_cursor_test2.txt (239.4 KiB)

osx client mouse disappearance tests, quick xterm disappearing act

[totaam]

2013-12-06 01:19:26: totaam commented

---

These log files are ~ 300KB big and includes things like sound, really clobbering the output, I can't just skim through something that big. Please grab the output of when the events of interest occur, not the whole thing from start to finish.

[totaam]

2013-12-06 15:42:04: totaam commented

---

FYI: a bug introduced very recently (in r4805), fixed in r4870 would have caused some of the cursor pixels to go missing. Worth mentioning as this may have been mistaken for an occurrence of this bug.

---

As for the logs, grepping them for cursor, I see:

• in xpra_mouse_cursor_test1.txt​:

cursors_toggled((<gtk.CheckMenuItem object at 0x6e125a8 (GtkCheckMenuItem at 0xdd3f48)>,)) cursors_enabled=True
new cursor at 22,22 with serial=2, dimensions: 48x48, len(pixels)=9216, default cursor size is 32
new cursor at 9,5 with serial=17, dimensions: 24x24, len(pixels)=2304, default cursor size is 32
new cursor at 9,5 with serial=17, dimensions: 24x24, len(pixels)=2304, default cursor size is 32
new cursor at 9,5 with serial=17, dimensions: 24x24, len(pixels)=2304, default cursor size is 32

So the cursors are enabled via the menu, then we get 4 changes - no idea which one is what.

• in xpra_mouse_cursor_test2.txt​:

cursors_toggled((<gtk.CheckMenuItem object at 0x6dde878 (GtkCheckMenuItem at 0xbd9748)>,)) cursors_enabled=True
new cursor at 22,22 with serial=2, dimensions: 48x48, len(pixels)=9216, default cursor size is 32
new cursor at 22,22 with serial=3, dimensions: 48x48, len(pixels)=9216, default cursor size is 32
new cursor at 22,22 with serial=2, dimensions: 48x48, len(pixels)=9216, default cursor size is 32

Similar to the one above, again, I won't know what I am supposed to see different or when.

---

• r4867 adds a test application for choosing the cursor shown when over the window: tests/xpra/test_apps/test_all_cursors.py

• we already had one for testing custom cursors: tests/xpra/test_apps/test_custom_cursor.py

Both are worth trying, to verify that all the cursors are forwarded correctly (for a baseline, it is best to use a Linux system to run the test examples without involving xpra at all)

Also worth capturing is:

xpra info | grep "^cursor"

when the cursor has gone MIA (this can be done from another machine to prevent interfering with the current client state)

[totaam]

2013-12-09 11:40:36: totaam commented

---

OK, I have fixed a number of things: r4898 + r4899 + r4900 + r4901 (most should be backported - assuming 0.10.x is affected the same way)

You could make the cursor (almost) disappear in an xterm by hitting "control" once without moving the mouse. Moving the mouse should make it appear again, unless somehow it failed to create a cursor by name.

But I still don't understand why we weren't seeing any errors in the logs - or why this would affect OSX and not win32.. oh well. Did you try other server or client versions?

Please test, and see comment:4 for details.

[totaam]

2013-12-09 22:38:42: afarr commented

---

The good news: with osx client 0.11.0-4905 and fedora 19 server 0.11.0-r4904 the cursor is no longer disappearing. Likewise, as you pointed out, with an xterm, while pressing control will make the cursor disappear, it does indeed always return as soon as it is moved or any keys are stroked.

The bad news: In a chrome window, the cursor displays as an 'x' when scrolling over non-interactable screen space (when not scrolling over links, videos, etc.). It displays correctly with firefox though.

[totaam]

2013-12-09 23:52:35: afarr commented

---

I attached an edited -d all --no-speaker file of output, as well as the complete output file, in case there's something more you'd like to check on.

For context:

There were already two xterms running on the server xpra session, one having started a chrome browser, the other having started a firefox browser.

I connected the client, clicked on the chrome browser, then scrolled over to the overlapping firefox browser and clicked on some overlapping space.

This turned the cursor from the arrow that firefox was displaying to the 'x' currently displaying on chrome.

I then I simply scrolled the 'under'lapping chrome window up and down for a second, before switching focus to an osx terminal window to issue the CLI sigint command.

[totaam]

2013-12-10 03:13:20: totaam commented

---

In a chrome window, the cursor displays as an 'x' when scrolling over non-interactable screen space
[[BR]]
I believe this should be fixed in r4906.

FYI: the gtk.gdk.X_CURSOR ("X") is used as a fallback when we fail to locate a cursor by name and fail to instantiate one with the pixels sent by the server. Both of which should never happen, but did in the past, and we now take extra precautions. Before r4906, we would also (wrongly) use it when we should have used the default cursor. (gtk.gdk.Window.set_cursor: Passing None means that the window will use the cursor of its parent window)

[totaam]

2013-12-10 21:35:43: afarr commented

---

edit by totaam: this comment belonged in #469

[totaam]

2013-12-11 22:32:36: afarr commented

---

Ok, I think the relevant info for the focus issue has been moved to #469.

I see no ongoing sign of the cursor disappearance or mis-sizing issues. I think it's safe to close this ticket and we can open a new one if something appears again.

[totaam]

2013-12-12 02:06:58: totaam changed status from new to closed

[totaam]

2013-12-12 02:06:58: totaam changed resolution from ** to fixed

[totaam]

2013-12-12 02:06:58: totaam commented

---

The cursor issue is fixed. Closing.

(I've moved the remaining comments about focus to #469, and deleted the duplicate attachments)