With Xpra 0.11.2 I noticed strange behaviour of mouse cursors. For instance on kate
when I move mouse over application window Xpra (client) logs the following to console:
cursor name 'ibeam' not found cursor name 'split_h' not found
Is it normal if application runs on local machine like in the following example?
xpra start :33 DISPLAY=:33 kate & xpra attach :33
In addition to this with "fglrx" drivers missing cursors appears on screen as somewhat 3 times larger than others. With radeon/mesa drivers cursor size do not change.
Interestingly those mouse cursors appears on screen properly without fallback do default 'X' cursor. The only problems are warning and cursor size.
Hah, yes, forgot about that, sorry.
r5400 removes the warning, will backport. As per the commit message: we may not have all the cursor names the server knows about, and that's fine. I left this in for debugging, and forgot about it.
The size issue sounds a lot like #369 / #189, see r3770. May also be related to #438, #343, #205. (so many tickets for what sounds like such a simple thing!)
The fact that it only appears with a specific driver makes me think that the driver/display are reporting different dpi and/or max/default cursor sizes.
When the size is not correct, can you please post:
xpra info :10 | grep "^cursor"
And maybe also the client debug log around that time.
And... I should be more careful, I ended up committing some work-in-progress code from the same file, reverted in r5401.
Here is output from xpra info :10 | grep "^cursor"
on server.
Normal cursor:
cursor.height=48 cursor.is_default=True cursor.name=left_ptr cursor.serial=7 cursor.width=48 cursor.x=706 cursor.xhot=10 cursor.y=524 cursor.yhot=
Large cursors:
cursor.height=48 cursor.is_default=True cursor.name=ibeam cursor.serial=31 cursor.width=48 cursor.x=695 cursor.xhot=8 cursor.y=540 cursor.yhot=18
cursor.height=48 cursor.is_default=True cursor.name=pointing_hand cursor.serial=57 cursor.width=48 cursor.x=583 cursor.xhot=18 cursor.y=680 cursor.yhot=2
cursor.height=48 cursor.is_default=True cursor.name=split_v cursor.serial=54 cursor.width=48 cursor.x=412 cursor.xhot=22 cursor.y=399 cursor.yhot=22
cursor.height=48 cursor.is_default=True cursor.name=split_h cursor.serial=53 cursor.width=48 cursor.x=561 cursor.xhot=22 cursor.y=301 cursor.yhot=22
Client says "cursor name not found" for all large cursors...
Client says "cursor name not found" for all large cursors...
Ooops, v0.11.x backport now done in r5689
Since you're running 0.11, I also need:
python -c "from gtk import gdk;display=gdk.display_get_default();print('default=%s, max=%s' % (display.get_default_cursor_size(), display.get_maximal_cursor_size()))"
From both outside and inside xpra. This is what I get:
default=24, max=(64, 64)
default=24, max=(128, 128)
Version 0.12 adds much improved logging (#411) and so one can just do:
xpra attach -d cursor ...
To get verbose cursor debugging (same for server), like this:
server cursor sizes: default=24, max=(64, 64) new cursor at 11,11 with serial=38, dimensions: 24x24, len(pixels)=2304, default cursor size is 24, maximum=(128, 128) setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> server cursor sizes: default=24, max=(64, 64) new cursor at 11,11 with serial=38, dimensions: 24x24, len(pixels)=2304, default cursor size is 24, maximum=(128, 128) setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType>
With 0.11.4 I'm getting default=21, max=(64, 64)
on client and inside Xpra...
Will try 0.12 when I can...
Bump, this may be related to #553
It looks like 0.12 fixed this issue for me. It may be (unless I'm mistaken about it) that some cursors appear slightly smaller than default arrow but it is not visually disturbing like cursors 2...3 times bigger that I was originally reporting. I think this bug can be closed. Thanks.
OK, closing.
If it does re-occur, please post cursor debugging:
xpra -d cursor ...
Which you can also activate on the server without restarting it, using:
xpra control :DISPLAY debug enable cursor
And see also #163, using the ConstantDPI
dummy driver option may solve this.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/513