xpra icon
Bug tracker and wiki

Opened 7 months ago

Closed 6 months ago

Last modified 6 months ago

#2607 closed defect (needinfo)

Mouse pointer not visible

Reported by: stdedos Owned by: stdedos
Priority: major Milestone: 4.0
Component: client Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

I am resurrecting #2300, with a small twist:

From / To my Xenial server:

$ xpra --version
xpra for python 2.7 is not installed
 retrying with python3
xpra v3.0.6-r25174

And mouse pointer won't come up with nothing

raw-attachment/ticket/2607/Screencast%202020-02-21%2012%3A00%3A15.mp4

Attachments (4)

Screencast 2020-02-21 12:00:15.mp4 (2.5 MB) - added by stdedos 7 months ago.
_usr_bin_xpra.1000.crash (116.9 KB) - added by stdedos 7 months ago.
xpra-2607-comments.tar.gz (35.9 KB) - added by stdedos 7 months ago.
xpra-2607-cursor.tar.gz (4.2 KB) - added by stdedos 7 months ago.

Change History (30)

Changed 7 months ago by stdedos

Changed 7 months ago by stdedos

Attachment: _usr_bin_xpra.1000.crash added

comment:1 Changed 7 months ago by stdedos

I found a small core during the experiment. Maybe it is useful in some part?

I also found a 9MB-core - maybe that's the opengl-core we have already discussed?

Last edited 7 months ago by stdedos (previous) (diff)

comment:2 Changed 7 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

And mouse pointer won't come up with nothing

Will check.
The -d cursor client log output would be good to have, just when you move over the window and it goes blank.
It is possible that this is a problem with your local theme, in which case this will help:

XPRA_USE_LOCAL_CURSORS=0 xpra attach ...

I found a small core during the experiment. Maybe it is useful in some part?
NameError: name 'ss' is not defined

That's already been fixed in r25193.
I even re-issued 3.0.6 with this fix on top, the problem is that every build succeeded (including xenial 32-bit) except for xenial 64-bit! (which is what you're using).

comment:3 Changed 7 months ago by stdedos

(Invocation is similar to #2606: xpra start --start=gnome-keyring-daemon --start=gnome-terminal --modal-windows=no --start='env GTK_MODULES="${GTK_MODULES//:unity-gtk-module/}" flatpak run org.gnome.Evolution')

Last edited 7 months ago by stdedos (previous) (diff)

comment:4 Changed 7 months ago by Antoine Martin

... flatpak run org.gnome.Evolution

Do I need to be running evolution to trigger this bug?
If so, only the flatpak one?

comment:5 in reply to:  2 Changed 7 months ago by stdedos

Replying to Antoine Martin:

I found a small core during the experiment. Maybe it is useful in some part?
NameError: name 'ss' is not defined

That's already been fixed in r25193.
I even re-issued 3.0.6 with this fix on top, the problem is that every build succeeded (including xenial 32-bit) except for xenial 64-bit! (which is what you're using).

I love how much I need to kill that Xenial with fire


Did the start command with XPRA_USE_LOCAL_CURSORS=0. No luck

Attached with logging:

$ xpra -d cursor attach 1
[...]
2020-02-21 16:17:41,483 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (723, 412), None))]), args[0])
2020-02-21 16:17:41,605 server does not support xi input devices
2020-02-21 16:17:41,605  server uses: xtest
2020-02-21 16:17:42,986 used PIL to convert png cursor to raw
2020-02-21 16:17:42,986 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:17:42,987 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:17:42,987 server cursor sizes: default=24, max=128
2020-02-21 16:17:42,987 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:17:42,988 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:17:42,988 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:17:42,988 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd12ebdd438 (GdkX11Cursor at 0x3f1be80)>
2020-02-21 16:17:47,061 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:17:49,033 used PIL to convert png cursor to raw
2020-02-21 16:17:49,033 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:17:49,034 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:17:49,034 server cursor sizes: default=24, max=128
2020-02-21 16:17:49,034 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:17:49,035 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:17:49,035 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:17:49,035 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd12224c5a0 (GdkX11Cursor at 0x3def000)>
2020-02-21 16:17:50,642 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])

Here I am barely seeing the mouse (Top half of the I-text-selection cursor, ~1px in width - forgot to take a screenshot)

2020-02-21 16:23:11,580 used PIL to convert png cursor to raw
2020-02-21 16:23:11,580 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:11,581 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:11,581 server cursor sizes: default=24, max=128
2020-02-21 16:23:11,581 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:11,581 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:11,582 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:11,582 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b2e090 (GdkX11Cursor at 0x3f1be80)>
2020-02-21 16:23:12,833 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:23:14,029 used PIL to convert png cursor to raw
2020-02-21 16:23:14,030 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:14,030 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:14,030 server cursor sizes: default=24, max=128
2020-02-21 16:23:14,031 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:14,031 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:14,031 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:14,031 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b2e4c8 (GdkX11Cursor at 0x3def1c0)>
2020-02-21 16:23:15,730 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:23:16,714 used PIL to convert png cursor to raw
2020-02-21 16:23:16,714 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:16,714 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:16,733 server cursor sizes: default=24, max=128
2020-02-21 16:23:16,734 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:16,734 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:16,734 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:16,734 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b2eab0 (GdkX11Cursor at 0x3848100)>
2020-02-21 16:23:16,753 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:23:16,805 used PIL to convert png cursor to raw
2020-02-21 16:23:16,805 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:16,805 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:16,810 server cursor sizes: default=24, max=128
2020-02-21 16:23:16,811 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:16,811 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:16,811 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:16,812 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b2eab0 (GdkX11Cursor at 0x3848380)>
2020-02-21 16:23:18,133 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])


Here I am seeing it normally. This is after typing stuff in the ticket, I thought I should try and take a screenshot ().

2020-02-21 16:23:30,281 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:23:30,741 used PIL to convert png cursor to raw
2020-02-21 16:23:30,741 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:30,742 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:30,742 server cursor sizes: default=24, max=128
2020-02-21 16:23:30,742 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:30,742 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:30,742 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:30,743 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b32480 (GdkX11Cursor at 0x3f1be80)>
2020-02-21 16:23:31,956 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:23:33,686 used PIL to convert png cursor to raw
2020-02-21 16:23:33,686 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:33,686 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:33,687 server cursor sizes: default=24, max=128
2020-02-21 16:23:33,687 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:33,687 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:33,687 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:33,687 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b35948 (GdkX11Cursor at 0x3f83a40)>
2020-02-21 16:23:38,227 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[0])
2020-02-21 16:23:39,508 used PIL to convert png cursor to raw
2020-02-21 16:23:39,508 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (714, 399), None))]), args[13])
2020-02-21 16:23:39,509 make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True
2020-02-21 16:23:39,509 server cursor sizes: default=24, max=128
2020-02-21 16:23:39,510 new b'raw' cursor at 11,11 with serial=0x6, dimensions: 24x24, len(pixels)=2304
2020-02-21 16:23:39,510 default cursor size is 24, maximum=(128, 128)
2020-02-21 16:23:39,510 scaling cursor from 24x24 hotspot at 11x11 to 30x30 hotspot at 14x14
2020-02-21 16:23:39,510 make_cursor(..)=<GdkX11.X11Cursor object at 0x7fd121b357e0 (GdkX11Cursor at 0x3def180)>


Here, I cannot see anything. This is after playing with the window, to understand why am I now able to see the cursor


Replying to Antoine Martin:

... flatpak run org.gnome.Evolution

Do I need to be running evolution to trigger this bug?
If so, only the flatpak one?

I trigger it consinstently by doing the #2606 things. Idk how else to do it.

For me, the only evolution working is the flatpak one. xenial-evolution is broken for me #2034
I suspect it's not broken for you, because (a) you haven't it configured (obviously), and (b) the old evolution used to show the Welcome dialog alone. Flatpak-evolution initializes the UI and shows the Welcome dialog (and it's a few millenia newer than the one shipped with Xenial)

comment:6 Changed 7 months ago by arrowd

Hello. I'm trying to update Xpra port for FreeBSD and seeing the same issue.

When hovering over remote Konsole window (a KDE terminal emulator) the cursor becomes invisible.

I tried playing with color scheme - it has nothing to do with terminal background. However, it certainly have something to do with terminal emulator applications.

comment:7 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

Did the start command with XPRA_USE_LOCAL_CURSORS=0. No luck

As per comment:2, XPRA_USE_LOCAL_CURSORS=0 is for the client (attach), not the server. But I don't think this would help anyway, local named cursors would have printed an extra line of debug.
One thing you can try is to run the client with XPRA_SAVE_CURSORS=1 xpra attach ....
This will save cursors as PNG images using the filename cursor-$SERIAL.png (so the same serial may overwrite the cursor file - though they should be identical in that case?)

Another thing which may affect the cursors is scaling:

make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True

Can you reproduce the problem with scaling disabled?

comment:8 Changed 7 months ago by Antoine Martin

#2623 could be a duplicate of this ticket.

comment:9 Changed 7 months ago by arrowd

Here is a relevant part of "-d cursor" log:

2020-03-06 09:26:19,250 Attached to ssh://root@farstar/
2020-03-06 09:26:19,251  (press Control-C to detach)

2020-03-06 09:26:19,291 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (1872, 1051), None))]), args[0])
2020-03-06 09:26:19,378 server does not support xi input devices
2020-03-06 09:26:19,379  server uses: xtest
2020-03-06 09:26:21,759 used PIL to convert png cursor to raw
2020-03-06 09:26:21,760 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (1872, 1051), None))]), args[13])
2020-03-06 09:26:21,760 make_cursor: has-name=True, has-cursor-types=True, xscale=1, yscale=1, USE_LOCAL_CURSORS=True
2020-03-06 09:26:21,760 cursor name 'ibeam' not found
2020-03-06 09:26:21,761 server cursor sizes: default=53, max=128
2020-03-06 09:26:21,761 new b'raw' cursor at 16,16 with serial=0x3, dimensions: 32x32, len(pixels)=4096
2020-03-06 09:26:21,761 default cursor size is 22, maximum=(128, 128)
2020-03-06 09:26:21,762 make_cursor(..)=<GdkX11.X11Cursor object at 0x8352b2690 (GdkX11Cursor at 0x8333dcd00)>

comment:10 Changed 7 months ago by Antoine Martin

Here is a relevant part of "-d cursor" log:

Nothing unusual here. Looks like we're using the cursor exactly as the server intended.
It would be good to verify that this is the cursor that the server sends.

XPRA_SAVE_CURSORS=1 xpra start -d cursor ...

Will save all the cursors that the server sends. (I'm reasonably confident that using XPRA_SAVE_CURSORS=1 client side would show the same picture)
Then you can attach the picture of the "incorrect" one to this ticket.

It could just be that the application is using a blank cursor for other reasons: missing theme, bad xsettings, etc.
The toolbox in xpra v4 has a cursor test application.

comment:11 in reply to:  10 ; Changed 7 months ago by stdedos

Forgot about that ticket, apologies.

Replying to Antoine Martin:

Did the start command with XPRA_USE_LOCAL_CURSORS=0. No luck

As per comment:2, XPRA_USE_LOCAL_CURSORS=0 is for the client (attach), not the server. But I don't think this would help anyway, local named cursors would have printed an extra line of debug.

I don't understand with env won't propagate to the attach instance too, but okay

One thing you can try is to run the client with XPRA_SAVE_CURSORS=1 xpra attach ....
This will save cursors as PNG images using the filename cursor-$SERIAL.png (so the same serial may overwrite the cursor file - though they should be identical in that case?)

Another thing which may affect the cursors is scaling:

make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True

Can you reproduce the problem with scaling disabled?

Scaling? What scaling? I didn't activate such thing.

For some reason, connections from/to Xenial server have this message:

2020-03-06 10:18:38,790 Warning: Invalid Scale Factor
2020-03-06 10:18:38,791  cannot scale by 100% x 100% or lower
2020-03-06 10:18:38,792  the scaled client screen 6400 x 1440 -> 6400 x 1440
2020-03-06 10:18:38,792   would overflow the server's screen: 5760 x 2560

but not when I connect from the Windows 10 client to the Xenial server. I don't understand why you pick such a big display (6400 x 1440), and why do you need to scale it down (5760 x 2560) since the screen size is an "imaginary" screen size (seamless i.e. only the windows are drawn)


For some reason, -d cursors debugging does not work for the client :/


Replying to Antoine Martin:

Here is a relevant part of "-d cursor" log:

Nothing unusual here. Looks like we're using the cursor exactly as the server intended.
It would be good to verify that this is the cursor that the server sends.

XPRA_SAVE_CURSORS=1 xpra start -d cursor ...

Will save all the cursors that the server sends. (I'm reasonably confident that using XPRA_SAVE_CURSORS=1 client side would show the same picture)
Then you can attach the picture of the "incorrect" one to this ticket.

It could just be that the application is using a blank cursor for other reasons: missing theme, bad xsettings, etc.
The toolbox in xpra v4 has a cursor test application.

XPRA_SAVE_CURSORS does not save anything (where would it be? You didn't specify)

$ /usr/bin/time find / -name 'raw-cursor-*.png' |& grep -v "Permission denied"
find: ‘/proc/15299’: No such file or directory
find: ‘/proc/15300’: No such file or directory
find: ‘/proc/15301’: No such file or directory
find: ‘/proc/15302’: No such file or directory
find: ‘/proc/15303’: No such file or directory
Command exited with non-zero status 1
6.23user 8.16system 0:31.51elapsed 45%CPU (0avgtext+0avgdata 16176maxresident)k
653048inputs+0outputs (0major+7951minor)pagefaults 0swaps

And a bunch of cores.


Also also: Reconnecting to the server (with -d cursors) crashes the server beyond repair.


Find all of that in the attachment/ticket/2607/xpra-2607-comments.tar.gz

Changed 7 months ago by stdedos

Attachment: xpra-2607-comments.tar.gz added

comment:12 in reply to:  11 ; Changed 7 months ago by Antoine Martin

One thing you can try is to run the client with XPRA_SAVE_CURSORS=1 xpra attach ....
This will save cursors as PNG images using the filename cursor-$SERIAL.png (so the same serial may overwrite the cursor file - though they should be identical in that case?)

Another thing which may affect the cursors is scaling:

make_cursor: has-name=True, has-cursor-types=True, xscale=1.25, yscale=1.25, USE_LOCAL_CURSORS=True

Can you reproduce the problem with scaling disabled?

Scaling? What scaling? I didn't activate such thing.

It is activated automatically because your client display is so large.

For some reason, connections from/to Xenial server have this message:

2020-03-06 10:18:38,790 Warning: Invalid Scale Factor
2020-03-06 10:18:38,791  cannot scale by 100% x 100% or lower
2020-03-06 10:18:38,792  the scaled client screen 6400 x 1440 -> 6400 x 1440
2020-03-06 10:18:38,792   would overflow the server's screen: 5760 x 2560

but not when I connect from the Windows 10 client to the Xenial server. I don't understand why you pick such a big display (6400 x 1440), and why do you need to scale it down (5760 x 2560) since the screen size is an "imaginary" screen size (seamless i.e. only the windows are drawn)

The server's virtual screen must be configured to match the client's display area.
Since the client's total resolution is higher than the maximum allowed by the server's vfb, the client is forced to use scaling to find a resolution that will be accepted by the server.

For some reason, -d cursors debugging does not work for the client :/

cursor not cursors.

XPRA_SAVE_CURSORS does not save anything (where would it be? You didn't specify)

In the CWD of the client and server.

/usr/bin/time find / -name 'raw-cursor-*.png' |& grep -v "Permission denied"

As per comment:7, the filename will be cursor-$SERIAL.png.

Also also: Reconnecting to the server (with -d cursors) crashes the server beyond repair.

Interesting, I've seen such a crash on re-connection but I never managed to reproduce it.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:13 in reply to:  10 Changed 7 months ago by arrowd

Replying to Antoine Martin:

Here is a relevant part of "-d cursor" log:

Nothing unusual here. Looks like we're using the cursor exactly as the server intended.
It would be good to verify that this is the cursor that the server sends.

XPRA_SAVE_CURSORS=1 xpra start -d cursor ...

Will save all the cursors that the server sends. (I'm reasonably confident that using XPRA_SAVE_CURSORS=1 client side would show the same picture)
Then you can attach the picture of the "incorrect" one to this ticket.

Tried that. It generated raw-cursor-0x2.png and raw-cursor-0x3.png files. These cursors look correct, so apart missing 0x1 one, the server side looks fine.

However, running the client with XPRA_SAVE_CURSORS produced no cursor files and following messages:

2020-03-06 13:10:39,293 error creating cursor: 'Pixbuf' object has no attribute 'save' (using default)
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/xpra/client/gtk_base/gtk_client_base.py", line 768, in set_windows_cursor
    cursor = self.make_cursor(cursor_data)
  File "/usr/local/lib/python3.7/site-packages/xpra/client/gtk_base/gtk_client_base.py", line 869, in make_cursor
    cursor_pixbuf.save("cursor-%#x.png" % serial, "png")
AttributeError: 'Pixbuf' object has no attribute 'save'
2020-03-06 13:10:44,108 error creating cursor: 'Pixbuf' object has no attribute 'save' (using default)
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/xpra/client/gtk_base/gtk_client_base.py", line 768, in set_windows_cursor
    cursor = self.make_cursor(cursor_data)
  File "/usr/local/lib/python3.7/site-packages/xpra/client/gtk_base/gtk_client_base.py", line 869, in make_cursor
    cursor_pixbuf.save("cursor-%#x.png" % serial, "png")
AttributeError: 'Pixbuf' object has no attribute 'save'

comment:14 Changed 7 months ago by Antoine Martin

These cursors look correct, so apart missing 0x1 one, the server side looks fine.

Cool.
The 0x1 was never used.

AttributeError: 'Pixbuf' object has no attribute 'save'

Ah, python3 builds!
Fixed in r25528. Which you can apply by hand.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:15 in reply to:  12 Changed 7 months ago by stdedos

but not when I connect from the Windows 10 client to the Xenial server. I don't understand why you pick such a big display (6400 x 1440), and why do you need to scale it down (5760 x 2560) since the screen size is an "imaginary" screen size (seamless i.e. only the windows are drawn)

The server's virtual screen must be configured to match the client's display area.
Since the client's total resolution is higher than the maximum allowed by the server's vfb, the client is forced to use scaling to find a resolution that will be accepted by the server.

Can you somehow fix it? Using

$ xpra -d cursor attach 4 --desktop-scaling=off
xpra for python 2.7 is not installed
 retrying with python3
2020-03-06 11:46:21,755 Xpra GTK3 X11 client version 3.0.6-r25174 64-bit
2020-03-06 11:46:21,823  running on Linux Ubuntu 16.04 xenial
2020-03-06 11:46:21,824  window manager is 'Compiz'
2020-03-06 11:46:21,914 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'
2020-03-06 11:46:22,267 OpenGL enabled with Quadro P400/PCIe/SSE2
2020-03-06 11:46:22,294  keyboard settings: layout=us, model=pc105, rules=evdev
2020-03-06 11:46:22,297  desktop size is 6400x1440 with 1 screen:
2020-03-06 11:46:22,297   :0.0 (1693x381 mm - DPI: 96x96) workarea: 6341x1416 at 59x24
2020-03-06 11:46:22,297     DP-0 2560x1440 (597x336 mm - DPI: 108x108)
2020-03-06 11:46:22,297     DP-2 1920x1080 at 2560x180 (527x296 mm - DPI: 92x92)
2020-03-06 11:46:22,297     DP-4 1920x1080 at 4480x180 (527x296 mm - DPI: 92x92)
2020-03-06 11:46:22,320 Warning: invalid frame extents value '[0, 0, 0, 0, 0, 0, 28, 0]'
2020-03-06 11:46:22,320  this is probably a bug in 'Compiz'
2020-03-06 11:46:22,321  using '[0, 0, 28, 0]' instead
2020-03-06 11:46:23,230 enabled fast mmap transfers using 281MB shared memory area
2020-03-06 11:46:23,231 enabled remote logging
2020-03-06 11:46:23,233 Xpra GTK3 X11 server version 3.0.6-r25174 64-bit
2020-03-06 11:46:23,234  running on Linux Ubuntu 16.04 xenial
2020-03-06 11:46:23,236 Server's virtual screen is too small
2020-03-06 11:46:23,237  server: 5760x2560 vs client: 6400x1440
2020-03-06 11:46:23,238  you may see strange behavior,
2020-03-06 11:46:23,238  please see http://xpra.org/trac/wiki/Xdummy#Configuration

Somehow fixed rendering for local clients so much.
Now, if somehow all the icons would look like the native ones (e.g. LibreOffice toolbars), that would be awesome .....

For some reason, -d cursors debugging does not work for the client :/

cursor not cursors.

XPRA_SAVE_CURSORS does not save anything (where would it be? You didn't specify)

In the CWD of the client and server.

Sorry, no:

~$ /usr/bin/time find / -name 'cursor-*.png' |& grep -v "Permission denied"
/opt/qt514/examples/widgets/widgets/tablet/images/cursor-pencil.png
/opt/qt514/examples/widgets/widgets/tablet/images/cursor-airbrush.png
/opt/qt514/examples/widgets/widgets/tablet/images/cursor-felt-marker.png
/opt/qt514/examples/widgets/widgets/tablet/images/cursor-eraser.png

Command exited with non-zero status 1
5.83user 6.69system 0:22.72elapsed 55%CPU (0avgtext+0avgdata 16584maxresident)k
96inputs+0outputs (0major+8223minor)pagefaults 0swaps
~$ /usr/bin/time find / -name 'raw-cursor-*.png' |& grep -v "Permission denied"
Command exited with non-zero status 1
5.77user 6.59system 0:22.38elapsed 55%CPU (0avgtext+0avgdata 16356maxresident)k
0inputs+0outputs (0major+8088minor)pagefaults 0swaps

Could it be that server cleans after itself when closed? :/
(It does sound weird that server would clean up files under ~ though)

/usr/bin/time find / -name 'raw-cursor-*.png' |& grep -v "Permission denied"

As per comment:7, the filename will be cursor-$SERIAL.png.

You keep saying that, but I keep seeing:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/server/source/windows_mixin.py", line 276, in do_send_cursor
    with open(filename, "wb") as f:
PermissionError: [Errno 13] Permission denied: 'raw-cursor-0xd.png'
[36m2020-03-06 11:42:18,942 client   1 @45.093 set_windows_cursor(dict_values([GLClientWindow(1 : gtk3.GLDrawingArea(1, (732, 416), None))]), args[0])[0m

raw-cursor-*.png
and no files found

Also also: Reconnecting to the server (with -d cursors) crashes the server beyond repair.

Interesting, I've seen such a crash on re-connection but I never managed to reproduce it.

Broken playground, at your service :-D


Find output attachment/ticket/2607/xpra-2607-cursor.tar.gz here.

Last edited 7 months ago by Antoine Martin (previous) (diff)

Changed 7 months ago by stdedos

Attachment: xpra-2607-cursor.tar.gz added

comment:16 Changed 7 months ago by arrowd

With patch applied I do indeed get an empty cursor file, called 0x6. Moreover, I actually get an empty file on server too. Probably just missed it on first look.

It is worth mentioning that cursor is visible when it hovers over Konsole menu bar at the top. It disappears only when entering terminal zone.

comment:17 Changed 7 months ago by Antoine Martin

Can you somehow fix it? Using
(..)
Somehow fixed rendering for local clients so much.

No, it doesn't really fix things: the rendering is unscaled, but it makes the rightmost side of the desktop unusable with xpra forwarded windows: those won't be able to receive pointer events past the end of the vfb's size.
The correct way to fix this is to make your server vfb bigger, see /etc/xpra/conf.d/55_server_x11.conf and change 5760x2560x24+32 to something bigger: try r25533.

In the CWD of the client and server.

Sorry, no:

The CWD of the server might not be what you expect, especially if it deamonizes or if it gets started via ssh.

As per comment:7, the filename will be cursor-$SERIAL.png.

You keep saying that, but I keep seeing:

  • cursor-$SERIAL.png is for the client, that's the cursor data just before we apply it
  • raw-cursor-$SERIAL.png is for the server, and also for the client when receiving the icon in png format

PermissionError: [Errno 13] Permission denied: 'raw-cursor-0xd.png'
(..)
and no files found

Your server does not have the permission to save the png file.
Start your server by hand, with --no-daemon, from a directory you have write access to.

With patch applied I do indeed get an empty cursor file, called 0x6. Moreover, I actually get an empty file on server too. Probably just missed it on first look.

My guess is that this is a theme or application configuration problem, a broken theme or a theme with some missing / blank cursors perhaps.
The client is just using whatever the server sent it, and the server got it from the X11 server.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:18 in reply to:  17 Changed 7 months ago by arrowd

But it works with xpra 2.5 as client. Moreover, I see same files on both sides in both cases.

Note that invisible is the cursor that does have image. The empty cursor image is probably a red herring.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:19 Changed 7 months ago by Antoine Martin

stdedos / arrowd: what is a simple setup I can use to test?
I want the most basic test application I can run to reproduce the problem.
On a basic install of a supported OS.

comment:20 in reply to:  19 Changed 7 months ago by stdedos

Replying to Antoine Martin:

stdedos / arrowd: what is a simple setup I can use to test?
I want the most basic test application I can run to reproduce the problem.
On a basic install of a supported OS.

If this does not qualify for you

(Invocation is similar to #2606: xpra start --start=gnome-keyring-daemon --start=gnome-terminal --modal-windows=no --start='env GTK_MODULES="${GTK_MODULES//:unity-gtk-module/}" flatpak run org.gnome.Evolution')

I don't know

comment:21 Changed 7 months ago by Antoine Martin

If this does not qualify for you

It doesn't because the problem does not occur for me.

comment:22 Changed 7 months ago by Antoine Martin

And installing from flatpak is not considered a simple installation, too many variables.

comment:23 Changed 6 months ago by stdedos

I keep seeing this from time to time; although not reliably or on the same program.

The case with the recent sessions is: Sessions started / attached to Windows, that worked normally, now attached under Ubuntu fail to show the cursor consistently.

This still involves scaling however; somehow server still has server.max_desktop_size=(5760, 2560), even after changing to xvfb = Xvfb +extension GLX +extension Composite -screen 0 7680x4320x24+32 -dpi 96 -nolisten tcp -noreset -auth $XAUTHORITY (and xpra-upgrade, because I don't 100% remember if that was started before or after this change)

comment:24 Changed 6 months ago by Antoine Martin

This still involves scaling however; somehow server still has server.max_desktop_size=(5760, 2560), even after changing to (..) (and xpra-upgrade, because I don't 100% remember if that was started before or after this change)

xpra upgrade does not restart the vfb, that's the point of upgrade: it doesn't kill your applications, restarting the vfb would.

Just like #2623, I strongly suspect that an unusual setup is messing up with the theme settings, causing the server to receive a blank cursor from X11.
Which means that this isn't an xpra bug but a setup issue with your OS and themes.

I have tested konsole and evolution on Xenial, with win32 clients and other Linux clients and I cannot reproduce any problems with cursors.
So I will probably close this as 'needinfo'.

FWIW: I did find a transparency rendering bug running the Xenial client with python2 / GTK2, works OK with python3 / GTK3. (could just be virtualbox acting up)

Last edited 6 months ago by Antoine Martin (previous) (diff)

comment:25 Changed 6 months ago by Antoine Martin

Resolution: needinfo
Status: newclosed

comment:26 Changed 6 months ago by arrowd

I can't reproduce the problem anymore with 3.0.7 used on server and client sides. Huzzah!

Note: See TracTickets for help on using tickets.