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
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?
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).
(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'
)
... flatpak run org.gnome.Evolution
Do I need to be running evolution to trigger this bug? If so, only the flatpak one?
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)
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.
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?
#2623 could be a duplicate of this ticket.
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)>
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.
Forgot about that ticket, apologies.
Replying to Antoine Martin:
Did the start command with
XPRA_USE_LOCAL_CURSORS=0
. No luckAs 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 filenamecursor-$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=TrueCan 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
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 filenamecursor-$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=TrueCan 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 2560but 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.
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'
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.
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
notcursors
.
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.
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.
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.
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.
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.
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
If this does not qualify for you
It doesn't because the problem does not occur for me.
And installing from flatpak is not considered a simple installation, too many variables.
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)
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)
I can't reproduce the problem anymore with 3.0.7 used on server and client sides. Huzzah!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2607