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?
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)
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?
osx client mouse cursor test, disappearung under xterms and chrome
osx client mouse disappearance tests, quick xterm disappearing act
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.
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:
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 32So the cursors are enabled via the menu, then we get 4 changes - no idea which one is what.
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 32Similar to the one above, again, I won't know what I am supposed to see different or when.
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)
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.
The good news: with osx client 0.11.0-r4905 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.
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.
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.
In a chrome window, the cursor displays as an 'x' when scrolling over non-interactable screen space
I believe this should be fixed in r4906.
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)
edit by totaam: this comment belonged in #469
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.
The cursor issue is fixed. Closing.
(I've moved the remaining comments about focus to #469, and deleted the duplicate attachments)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/438