Allow the client to "lie" about its real display dimensions (and maybe still report the actual correct values somewhere) so that the server can render things at a different resolution and save CPU, memory and bandwidth.
This will allow us to handle 4k screens a lot better: we can render at 2k or even just 1080p and upscale client side. For a lot of content, especially video-like pixels, it is a lot more efficient than upscaling the video (in the client application: browser or video player) then downscaling it before compressing it, only to upscale it at the other end. The compression can introduce a lot of blurring which gets magnified. Compressing 4k is just too expensive in most cases, even with hardware assisted encoding. With a smaller virtual screen size, we are more likely to be able to compress losslessly or at a better quality and higher framerate. The client-side upscaling may also be able to do the anti-aliasing for us. This is what MS Windows does already for applications which are not DPI aware.
Maybe worth doing if dummy + randr does not get fixed in time: when we are scaling things, we could also use the full virtual screen's size (which may be bigger than the size the client requested) and let the client scale it appropriately. That's as long as the differences are minimal (say 10%?). It will avoid bugs with applications which use the display size without checking the desktop / workarea / available size options.
Related / impacted tickets:
work in progress - rendering part not done (big)
From the patch above, things that need to be fixed or added:
get_frame_extents
/ get_window_frame_sizes
/ get_window_frame_size
- not done
to verify:
get_client_window_classes
could use backing size? the opengl limit is on the texture? (but we also render to a PBO?)
mostly working patch - opengl done
working with all backends: cairo, pixmap and opengl!
Mostly done in r10533, currently only accessible via env vars. It looks really good and uses a lot less bandwidth! (much better than the automatic scaling - which may still kick in, but much less)
Note: the pixmap and cairo backings look quite ugly compared to the opengl one because we only repaint the area that has changed whereas the opengl backend repaints everything (because this is cheap) and therefore avoids aliasing issues on the edge of the area being repainted. We could update those backends I guess. Needs testing to decide if it is worth it.
The Pixmap backend upscales the picture using the "HYPER" gdk filter, this can be overriden with XPRA_SCALING_INTERPOLATION=FILTERNAME
- see here for the list of options: pixbuf.scale.
Still TODO:
parse_scaling_value
(ie: support 3/2
), and send this to the server instead of a float multiplied by 1000...
--client-scaling=off|auto|XVALUE,YVALUE
, auto could enabled client side scaling if DPI is high? or if the desktop size is very big, or both?
GL_MAX_VIEWPORT_DIMS
instead - which should always be bigger than the texture size already?)
Important fixup in r10553 - unscaled opengl rendering was broken since r10533 on platforms without double-buffering (all but win32).
Here are some usage examples:
Still TODO:
(some of these items are likely to be scheduled for a future release, ie: xshape)
@afarr: ready for testing:
future stuff (recording here for lack of a better place):
Running a Fedora 20 r10666 client against a Fedora 21 r10666 Server:
--desktop-scaling=auto
(unable to trigger due to resolution being at 1080p), everything works the same as before, even after a couple hours of normal usage (surfing Trac comments in Firefox, emails in Thunderbird).
shift + alt + *
(even sticks after a reconnect)
System tray forwarding does not work properly
Which desktop environment do you use?
With gnome3 and topicons, the tray icons don't work half the time - that's even without xpra...
And even without the topicons extension, the horrible and annoying little widget at the bottom left hand side of the screen doesn't work either!
I'll take a look later since I also get problems with win32 (and that one works reliably since Windows 2000!)
Some minor fixes in this area in r10667. (should help when upscaling)
Cursor scales down, but stays small when resetting scale (shift + alt + * (even sticks after a reconnect) Edit: The cursor does not scale up properly as well
Fixes to upscaling cursors in r10668.
Notes:
-d cursor
debug output.
Not sure how to test xshape
xeyes
raising the priority: this is one of the most important new features in 0.16, and I would like to make "auto" mode the default
The client(fedora 20) is currently running Mate, but I have Gnome, and Xfce installed - and use them from time to time.
Upped server (Fedora 21) and client (fedora 20) to trunk r10765:
-d cursor
output(connected, scaled a couple times, disconnected):
2015-10-08 14:33:13,534 Attached to tcp:10.0.32.139:2200 (press Control-C to detach) 2015-10-08 14:33:13,891 window dimensions are wrong: 1x1 2015-10-08 14:33:13,926 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) /usr/lib64/python2.7/site-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed import gobject._gobject 2015-10-08 14:33:15,622 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:15,623 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:15,624 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d00: GDK_LEFT_PTR> 2015-10-08 14:33:15,664 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:15,665 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:15,665 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9b48: GDK_LEFT_PTR> 2015-10-08 14:33:15,875 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:15,876 setting new cursor by name: hand2=<enum GDK_HAND2 of type GdkCursorType> 2015-10-08 14:33:15,877 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9b48: GDK_HAND2> 2015-10-08 14:33:15,979 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:15,980 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:15,981 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d00: GDK_LEFT_PTR> 2015-10-08 14:33:16,775 sound-sink using audio codec: MPEG 1 Audio, Layer 3 (MP3) 2015-10-08 14:33:18,032 sending updated screen size to server: 3840x2160 with 1 screens 2015-10-08 14:33:18,033 :0.0 (602x343 mm - DPI: 162x159) workarea: 3840x2064 at 0x48 2015-10-08 14:33:18,035 DVI-I-1 (600x340 mm - DPI: 162x161) 2015-10-08 14:33:18,394 scaling_changed() resetting cursors for: [ClientWindow(18)] 2015-10-08 14:33:18,395 set_windows_cursor([ClientWindow(18)], ..) 2015-10-08 14:33:18,396 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:18,397 make_cursor(..)=<gtk.gdk.Cursor at 0x3efc238: GDK_LEFT_PTR> 2015-10-08 14:33:19,387 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:19,435 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:19,438 setting new cursor by name: xterm=<enum GDK_XTERM of type GdkCursorType> 2015-10-08 14:33:19,439 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9df0: GDK_XTERM> 2015-10-08 14:33:20,346 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:20,347 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:20,348 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d28: GDK_LEFT_PTR> 2015-10-08 14:33:20,564 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:20,565 setting new cursor by name: hand2=<enum GDK_HAND2 of type GdkCursorType> 2015-10-08 14:33:20,566 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9d28: GDK_HAND2> 2015-10-08 14:33:20,603 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:20,605 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:20,606 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9cd8: GDK_LEFT_PTR> 2015-10-08 14:33:21,613 set_windows_cursor([ClientWindow(1), ClientWindow(40), ClientWindow(10), ClientWindow(11), ClientWindow(12), ClientWindow(18)], ..) 2015-10-08 14:33:21,614 setting new cursor by name: left_ptr=<enum GDK_LEFT_PTR of type GdkCursorType> 2015-10-08 14:33:21,615 make_cursor(..)=<gtk.gdk.Cursor at 0x3cf9df0: GDK_LEFT_PTR>
Ah, right, sorry about that, for testing I had been running my client with:
XPRA_USE_LOCAL_CURSORS=0 xpra ...
Which disabled named cursors, r10781 ensures we never use named cursors when scaling (as named cursors cannot be resized).
I'm still seeing cursors that seem too big when scaling or when using XPRA_USE_LOCAL_CURSORS=0
, but I think that's just a different server configuration.
If everything else works, please re-assign to me and I'll take another look.
Upped to r10783:
Here's the -d cursor
output for a quick connect-and-scale session:
attachment/ticket/976/976-comment11-cursor-log.txt
moving the cursor log to an attachment
Windows client does not scale properly (not sure if it's expected or not)
It is.
The situation on win32 is unclear, see #998. Cursors are meant to be using a fixed size so for the time being we do this:
scaling cursor from 48x48 to fixed OS size 32x32
Scaling down then attempting to use VLC's tray icon in Windows causes the right click to be sent to Google-Chrome (?)...
That's because we're not adjusting the tray icon's location properly to its new server-side on-virtual-screen position (scaled).
And so the clicks end up landing somewhere else...
Will fix.
As of r10798 we now paint the monitors and the workarea bounds onto the virtual screen with sync-xvfb
(see #988), and the tray seems to be in the right place.
Turns out that this HUGE bug was not tray related but only more apparent with the systray, and it would have caused us all sorts of problems elsewhere - now fixed in r10802. Works for me with win32 and vlc.
PS: I'm seeing some visual corruption with win32 when dowscaling without opengl. (will try to deal with it later - should be good enough for testing as it is)
Upped to r10786 Server and r10810 Client (Installed from xpra.org/beta
):
Since everything's working, I'll pass this back to you to decide what else needs to be done.
taskbar icon when scaling up and down... mild corruption only notable in Windows
Yes, I had noticed that - it looks as if it's painting the new one on top without clearing the previous one, but I have no idea where that is coming from - so we will have to live with it for now.
We already have a test app we can use to verify that changing the tray icon works and it's running fine with Windows clients: browser/xpra/trunk/src/tests/xpra/test_apps/test_system_tray.py (just click on the tray icon to change to the next one)
Since this works well enough, I have made "auto" mode the default in r10831. This is a big change.
@afarr / maxmylyn: this will need testing with 4k monitors (and multiple monitors, etc), especially with different DPI settings (see #163 / Writing DPI-Aware Desktop and Win32 Applications).
Windows 8.1 onwards used to scale our windows automatically on high dpi displays (see SetProcessDpiAwareness. You can use XPRA_DPI_AWARENESS=VALUE
to change this value (Process_System_DPI_Aware = 1
, Process_DPI_Unaware = 0
, Process_Per_Monitor_DPI_Aware = 2
- I don't think we will be able to handle per monitor DPI awareness for a while without some major changes X11 side). Use -d screen
to see the DPI calls, which should happen very early in the client startup process.
Note: I have no way to test this as I don't have a non-virtualized Windows 8.1 or later system to test on.
Important: without the "auto" desktop scaling mode added in r10831, we may end up using a lot more bandwidth with r10832 on Windows 8.1 and later since we should then be using "actual" monitor resolution instead of the DPI downscaled one. (a lot more pixels to forward) Why do we want to do this ourselves? We can scale more than the OS and we will get better quality if things are scaled only once by our client.
Maybe we should be taking into account the desired DPI to decide when to scale instead of just the display resolution? (if the user or OS chooses a high DPI, then we may want to scale - using Determining the DPI Scale Factor)
Maybe also re-test #919 at the same time as we may have to catch WM_DPICHANGED events (this page has a nice summary table listing scaling values for each DPI range) and check to see if the values for the frame extents have changed.
Note: I don't think we should be using the same scaling values as what MS Windows uses: scaling more is good for us as we save more CPU, bandwidth and we get a better framerate and user density.
Testing with windows client 0.16.0 r10853 against 0.16.0 r10853 fedora 21 server.
Just for a baseline, initial connection client output of desktop size and dpi:
2015-10-16 11:02:19,516 desktop size is 5120x2160 with 1 screen(s): 2015-10-16 11:02:19,516 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-10-16 11:02:19,516 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120 2015-10-16 11:02:19,516 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120 2015-10-16 11:02:19,516 scaled using 2 x 2 to: 2015-10-16 11:02:19,516 Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060 2015-10-16 11:02:19,516 DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 2560x1060 2015-10-16 11:02:19,516 DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 2560x1060 2015-10-16 11:02:19,657 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10854
Looks like attempts at scaling down below 1x1 on this size desktop (beyond the bounds of sanity really) is nicely caught, with a client warning, and refuses to scale down any further:
2015-10-16 11:03:49,463 Warning: cannot scale by 0.5 x 0.5 2015-10-16 11:03:49,463 the scaled client screen 5120 x 2160 -> 10240 x 4320 2015-10-16 11:03:49,463 would overflow the server's screen: 8192 x 4096 2015-10-16 11:03:49,463 using 0.625 x 0.625 2015-10-16 11:03:49,463 sending updated screen size to server: 8192x3456 with 1 screens 2015-10-16 11:03:49,463 Default (1354x571 mm - DPI: 153x153) workarea: 8192x3392 2015-10-16 11:03:49,463 DISPLAY1 6144x3456 at 2048x0 (621x341 mm - DPI: 251x257) workarea: 8192x3392 2015-10-16 11:03:49,463 DISPLAY2 2048x1152 (597x336 mm - DPI: 87x87) workarea: 8192x3392
Scaling up, however, doesn't seem to have a sanity check - using the shortcut shift-alt-+
4 times from the .625x.625 lower scaling limit triggers a crash client side.
Successive client side display output (with the client side IHDR
& IDAT
values peeled out, let me know if including them would be of use):
2015-10-16 11:04:05,786 sending updated screen size to server: 4096x1728 with 1 screens 2015-10-16 11:04:05,786 Default (1354x571 mm - DPI: 76x76) workarea: 4096x1696 2015-10-16 11:04:05,786 DISPLAY1 3072x1728 at 1024x0 (621x341 mm - DPI: 125x128) workarea: 4096x1696 2015-10-16 11:04:05,786 DISPLAY2 1024x576 (597x336 mm - DPI: 43x43) workarea: 4096x1696 ... 2015-10-16 11:04:06,812 sending updated screen size to server: 2048x864 with 1 screens 2015-10-16 11:04:06,812 Default (1354x571 mm - DPI: 38x38) workarea: 2048x848 2015-10-16 11:04:06,812 DISPLAY1 1536x864 at 512x0 (621x341 mm - DPI: 62x64) workarea: 2048x848 2015-10-16 11:04:06,812 DISPLAY2 512x288 (597x336 mm - DPI: 21x21) workarea: 2048x848 ... 2015-10-16 11:04:09,279 sending updated screen size to server: 1024x432 with 1 screens 2015-10-16 11:04:09,279 Default (1354x571 mm - DPI: 19x19) workarea: 1024x424 2015-10-16 11:04:09,279 DISPLAY1 768x432 at 256x0 (621x341 mm - DPI: 31x32) workarea: 1024x424 2015-10-16 11:04:09,296 DISPLAY2 256x144 (597x336 mm - DPI: 10x10) workarea: 1024x424 ... 2015-10-16 11:04:25,822 sending updated screen size to server: 512x216 with 1 screens 2015-10-16 11:04:25,823 Default (1354x571 mm - DPI: 9x9) workarea: 512x212 2015-10-16 11:04:25,823 DISPLAY1 384x216 at 128x0 (621x341 mm - DPI: 15x16) workarea: 512x212 2015-10-16 11:04:25,825 DISPLAY2 128x72 (597x336 mm - DPI: 5x5) workarea: 512x212 pnc=: N2015-10-16 11:04:35,078 sound-sink stopping C:\Program Files (x86)\Xpra>
The only output I get server side is:
2015-10-16 11:04:24,784 DPI set to 96 x 97 (wanted 96 x 96) 2015-10-16 11:04:24,786 sent updated screen size to 1 client: 512x384 (max 8192x4096) 2015-10-16 11:04:34,050 internal error: read connection tcp socket: 10.0.32.136:2200 <- 10.0.11.162:49634 reset 2015-10-16 11:04:34,051 [Errno 104] Connection reset by peer
Reconnecting the client with -d screen
I get this client side on re-connection to the same server session:
C:\Program Files (x86)\Xpra>xpra_cmd.exe attach tcp:10.0.32.136:2200 --sharing --password-file=key.txt --encryption-keyfile=key.txt --encryption=AES -d screen 2015-10-16 12:06:31,049 SetProcessDPIAware()=1 2015-10-16 12:06:31,049 SetProcessDPIAwareness(1) failed: function 'SetProcessDPIAwareness' not found 2015-10-16 12:06:31,049 (not available on MS Windows before version 8 2015-10-16 12:06:31,135 xpra gtk2 client version 0.16.0-r10853 2015-10-16 12:06:31,960 OpenGL_accelerate module loaded 2015-10-16 12:06:32,055 receiving data using AES encryption 2015-10-16 12:06:32,210 sending data using AES encryption 2015-10-16 12:06:32,305 detected keyboard: layout=us 2015-10-16 12:06:32,305 get_screen_sizes(1.000000, 1.000000) found 1 screens 2015-10-16 12:06:32,305 screen 0 has 2 monitors 2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65537>)={'Device': '\\\\.\\DISPLAY1', 'Work': (0, 0, 3840, 2120), 'Flags': 1, 'Monitor': (0, 0, 3840 , 2160)} 2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65539>)={'Device': '\\\\.\\DISPLAY2', 'Work': (-1280, 0, 0, 680), 'Flags': 0, 'Monitor': (-1280, 0, 0, 720)} 2015-10-16 12:06:32,305 get_workareas()=[(0, 0, 3840, 2120), (0, 0, 1280, 680)] 2015-10-16 12:06:32,305 monitor 0: ['\\\\.\\DISPLAY1', 1280, 0, 3840, 2160, 621, 341] 2015-10-16 12:06:32,305 monitor 1: ['\\\\.\\DISPLAY2', 0, 0, 1280, 720, 597, 336] 2015-10-16 12:06:32,305 get_workarea() absolute total monitor dimensions: (3840, 2160) 2015-10-16 12:06:32,305 workarea=(0, 0, 5120, 2120) 2015-10-16 12:06:32,305 screen 0: ('1\\WinSta0\\Default', 5120, 2160, 1354, 571, [('\\\\.\\DISPLAY1', 1280, 0, 3840, 2160, 621, 341, 0, 0, 3840, 2120), ('\\\\.\\DIS PLAY2', 0, 0, 1280, 720, 597, 336, 0, 0, 1280, 680)], 0, 0, 5120, 2120) 2015-10-16 12:06:32,305 desktop size is 5120x2160 with 1 screen(s): 2015-10-16 12:06:32,305 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-10-16 12:06:32,305 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120 2015-10-16 12:06:32,305 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120 2015-10-16 12:06:32,305 scaled using 2 x 2 to: 2015-10-16 12:06:32,305 get_screen_sizes(2.000000, 2.000000) found 1 screens 2015-10-16 12:06:32,305 screen 0 has 2 monitors 2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65537>)={'Device': '\\\\.\\DISPLAY1', 'Work': (0, 0, 3840, 2120), 'Flags': 1, 'Monitor': (0, 0, 3840 , 2160)} 2015-10-16 12:06:32,305 get_workareas() GetMonitorInfo(<PyHANDLE:65539>)={'Device': '\\\\.\\DISPLAY2', 'Work': (-1280, 0, 0, 680), 'Flags': 0, 'Monitor': (-1280, 0, 0, 720)} 2015-10-16 12:06:32,305 get_workareas()=[(0, 0, 3840, 2120), (0, 0, 1280, 680)] 2015-10-16 12:06:32,305 monitor 0: ['\\\\.\\DISPLAY1', 640, 0, 1920, 1080, 621, 341] 2015-10-16 12:06:32,305 monitor 1: ['\\\\.\\DISPLAY2', 0, 0, 640, 360, 597, 336] 2015-10-16 12:06:32,319 get_workarea() absolute total monitor dimensions: (3840, 2160) 2015-10-16 12:06:32,319 workarea=(0, 0, 5120, 2120) 2015-10-16 12:06:32,319 screen 0: ('1\\WinSta0\\Default', 2560, 1080, 1354, 571, [('\\\\.\\DISPLAY1', 640, 0, 1920, 1080, 621, 341, 0, 0, 1920, 1060), ('\\\\.\\DISP LAY2', 0, 0, 640, 360, 597, 336, 0, 0, 640, 340)], 0, 0, 2560, 1060) 2015-10-16 12:06:32,319 Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060 2015-10-16 12:06:32,319 DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 2560x1060 2015-10-16 12:06:32,319 DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 2560x1060 2015-10-16 12:06:32,319 get_vrefresh()=29 2015-10-16 12:06:32,476 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10854 2015-10-16 12:06:32,555 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)
And I get this repeatedly as I doggedly alt-shift-+
past a 6x6 dpi:
2015-10-16 12:37:57,841 do_paint_rgb32 error Traceback (most recent call last): File "xpra\client\window_backing_base.pyc", line 309, in do_paint_rgb32 File "xpra\client\gl\gl_window_backing_base.pyc", line 625, in _do_paint_rgb32 File "xpra\client\gl\gl_window_backing_base.pyc", line 641, in _do_paint_rgb File "xpra\client\gl\gl_window_backing_base.pyc", line 366, in gl_init File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes\OpenGL_accelerate\src\er rorchecker.c:1218) GLError: GLError( err = 1285, description = 'out of memory', baseOperation = glViewport, cArguments = (0, 0, 487, 290) ) 2015-10-16 12:37:57,904 do_paint_rgb32 error Traceback (most recent call last): File "xpra\client\window_backing_base.pyc", line 309, in do_paint_rgb32 File "xpra\client\gl\gl_window_backing_base.pyc", line 625, in _do_paint_rgb32 File "xpra\client\gl\gl_window_backing_base.pyc", line 641, in _do_paint_rgb File "xpra\client\gl\gl_window_backing_base.pyc", line 366, in gl_init File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (c:\Users\mcfletch\OpenGL-dev\OpenGL-ctypes\OpenGL_accelerate\src\er rorchecker.c:1218) GLError: GLError( err = 1285, description = 'out of memory', baseOperation = glViewport, cArguments = (0, 0, 487, 290) ) ** GLib:ERROR:gmain.c:2444:g_main_dispatch: assertion failed: (current->dispatching_sources == ¤t_source_link) This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. 2015-10-16 12:38:11,844 sound-sink stopping
Server-side, this time around, I'm seeing this:
2015-10-16 12:37:56,675 client_decode_error: do_paint_rgb32 error: GLError( err = 1285, description = 'out of memory', baseOperation = glViewport, cArguments = (0, 0, 487, 290) ) (-1) 2015-10-16 12:37:56,736 client_decode_error: do_paint_rgb32 error: GLError( err = 1285, description = 'out of memory', baseOperation = glViewport, cArguments = (0, 0, 487, 290) ) (-1) 2015-10-16 12:38:10,730 internal error: read connection tcp socket: 10.0.32.136:2200 <- 10.0.11.162:50088 reset 2015-10-16 12:38:10,731 [Errno 104] Connection reset by peer
... but the server is still apparently running.
I'll attach an xpra info from the server after the client's initial and second crash both.
initial scaling induced crash server info - comment 16
scaling up, up, and away - crashes client ... comment16
Testing against 0.16.0 r10854 fedora 21 server with 0.16.0 r10854 osx client...
fn+option/alt+shift+_
when trying to input alt-shift-minus
- without the numpad I can't input shift
and minus
at the same time. (Used gtk_view_keyboard.py
to confirm server-side keystroke inputs.)
KP_Multiply
key, only the asterisk
key.
fn-option/alt-shift-plus
to effect an alt-shift-plus
(again, keystrokes confirmed with gtk_view_keyboard.py
) also seems to have no effect.
Re-trying the last of the above with -d keyboard
, it looks like the +/=
key of the OSX laptop keyboard is being read as 'plusminus'
by the server keymapping:
2015-10-16 14:47:36,503 parse_key_event(<gtk.gdk.Event at 0x9242950: GDK_KEY_PRESS keyval=Alt_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 1, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65513, 'keycode': 58}> 2015-10-16 14:47:36,503 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 1, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65513, 'keycode': 58}>) wid=10 2015-10-16 14:47:36,503 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 1, 'string': '', 'keyname': 'Alt_L', 'pressed': True, 'keyval': 65513, 'keycode': 58}>) 2015-10-16 14:47:37,182 mask_to_names names=['mod1'], meta_on=False, meta_set=True, control_set=False 2015-10-16 14:47:37,183 mask_to_names(<flags GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'mod2'] 2015-10-16 14:47:37,183 parse_key_event(<gtk.gdk.Event at 0x9242950: GDK_KEY_PRESS keyval=Shift_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': True, 'keyval': 65505, 'keycode': 56}> 2015-10-16 14:47:37,183 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': True, 'keyval': 65505, 'keycode': 56}>) wid=10 2015-10-16 14:47:37,183 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': True, 'keyval': 65505, 'keycode': 56}>) 2015-10-16 14:47:37,725 mask_to_names names=['mod1', 'shift'], meta_on=False, meta_set=True, control_set=False 2015-10-16 14:47:37,726 mask_to_names(<flags GDK_SHIFT_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'shift', 'mod2'] 2015-10-16 14:47:37,726 parse_key_event(<gtk.gdk.Event at 0x92428d8: GDK_KEY_PRESS keyval=plusminus>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': True, 'keyval': 177, 'keycode': 24}> 2015-10-16 14:47:37,726 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': True, 'keyval': 177, 'keycode': 24}>) wid=10 2015-10-16 14:47:37,726 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': True, 'keyval': 177, 'keycode': 24}>) 2015-10-16 14:47:37,983 mask_to_names names=['mod1', 'shift'], meta_on=False, meta_set=True, control_set=False 2015-10-16 14:47:37,983 mask_to_names(<flags GDK_SHIFT_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'shift', 'mod2'] 2015-10-16 14:47:37,983 parse_key_event(<gtk.gdk.Event at 0x92428d8: GDK_KEY_RELEASE keyval=plusminus>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': False, 'keyval': 177, 'keycode': 24}> 2015-10-16 14:47:37,983 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': False, 'keyval': 177, 'keycode': 24}>) wid=10 2015-10-16 14:47:37,983 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '\xc2\xb1', 'keyname': 'plusminus', 'pressed': False, 'keyval': 177, 'keycode': 24}>) 2015-10-16 14:47:38,150 mask_to_names names=['mod1', 'shift'], meta_on=False, meta_set=True, control_set=False 2015-10-16 14:47:38,151 mask_to_names(<flags GDK_SHIFT_MASK | GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'shift', 'mod2'] 2015-10-16 14:47:38,151 parse_key_event(<gtk.gdk.Event at 0x92428d8: GDK_KEY_RELEASE keyval=Shift_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': False, 'keyval': 65505, 'keycode': 56}> 2015-10-16 14:47:38,151 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': False, 'keyval': 65505, 'keycode': 56}>) wid=10 2015-10-16 14:47:38,151 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'shift', 'mod2'], 'group': 1, 'string': '', 'keyname': 'Shift_L', 'pressed': False, 'keyval': 65505, 'keycode': 56}>) 2015-10-16 14:47:38,174 mask_to_names names=['mod1'], meta_on=False, meta_set=True, control_set=False 2015-10-16 14:47:38,175 mask_to_names(<flags GDK_MOD1_MASK of type GdkModifierType>)=['mod1', 'mod2'] 2015-10-16 14:47:38,175 parse_key_event(<gtk.gdk.Event at 0x92428c0: GDK_KEY_RELEASE keyval=Alt_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': False, 'keyval': 65513, 'keycode': 58}> 2015-10-16 14:47:38,175 handle_key_action(GLClientWindow(10 : gtk2.GLWindowBacking(10, (576, 501), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': False, 'keyval': 65513, 'keycode': 58}>) wid=10 2015-10-16 14:47:38,175 send_key_action(10, <GTKKeyEvent object, contents: {'modifiers': ['mod1', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Alt_L', 'pressed': False, 'keyval': 65513, 'keycode': 58}>)
With all the above said, I'll assume the odd behavior on this osx system when trying to manipulate the scaling (with a chromium browser the contents of the tabs seems to zoom in and out, while the address bar and tab bar remain at whatever the default scaling is).
Perhaps a link through the tray/application menu for users with annoying keyboard layouts would be worth the effort? Maybe a control channel switch?
Scaling up, however, doesn't seem to have a sanity check
None should be needed.
Since we get an "out of memory" in opengl, it would be very useful to know which opengl driver you used for testing, so r10890 will show that by default in the client output from now on. (not as good as the gl_check / GL info exe output, but better than nothing).
I will take a stab in the dark and guess it was an Intel driver: glClear() gives GL_OUT_OF_MEMORY on Intel HD 4000 (GL 4.0) but not GeForce (GL 4.2)… why?: "Intel" plus "OpenGL" plus "strange problem" is sadly almost self-explanatory.. ouch, that hurts.
It would also be useful to know which version of "Windows" you were running, so r10894 will now also log this information.
My guess is Windows 7 or Windows 8 (not 8.1) since SetProcessDPIAware()
worked but SetProcessDPIAwareness
did not.
initial scaling induced crash server info
How can you get the server info if it is crashed?
How did you figure out it was crashed? Where is the server log? Can you not re-connect with a client? (xpra info is a client of sorts)
I run into the difficulty that my laptop has no numpad it looks like the
+/=
key of the OSX laptop keyboard is being read asplusminus
by the server keymapping:
Just to clarify: since this is all running client-side, there is no "server keymapping".
r10893 adds a plusminus
shortcut for scaleup
.
Not sure if you managed to trigger scaledown
with minus
, if not please provide a keyname for the alternative OSX shortcut we want to use.
Laptops usually have a numlock somewhere, if not you can just define your own shortcut for the scaleup
, scaledown
and scalereset
actions. See man page or:
$ xpra -h |& grep -A 11 shortcut
Perhaps a link through the tray/application menu for users with annoying keyboard layouts would be worth the effort? Maybe a control channel switch?
Both would be good to have... if I find the time.
PS: I have edited the log output to remove the Pillow debug bits - this is a side effect of the upgrade to Pillow 3, I will deal with that separately.
r10900 ensures we don't continue to enlarge the window when we hit the maximum clamped scaling value (20 currently). On Windows 7 with an nvidia card this was triggering some WM_DWMCOMPOSITIONCHANGED events.
I suspect that the problem you hit might have been #942 instead: by doubling the window size every time, we must be reaching the OS / driver limits pretty quickly.
You are absolutely correct about the video driver -
OpenGL_accelerate module loaded OpenGL properties: * GLU extensions : GL_EXT_bgra * GLU version : 1.2.2.0 Microsoft Corporation * display_mode : DOUBLE * gdkgl.version : 6.2 * gdkglext.version : 1.2.0 * gtkglext.version : 1.2.0 * has_alpha : True * max-viewport-dims : (16384, 16384) * opengl : 4.0 * pygdkglext.version : 1.0.0 * pyopengl : 3.1.0 * renderer : Intel(R) HD Graphics 4000 * rgba : True * safe : True * shading language version : 4.00 - Build 10.18.10.3345 * texture-size-limit : 16384 * vendor : Intel * zerocopy : True
It is actually windows 8.1 that I'm testing with (bootcamped on a mac mini with the mac Intel graphics card).
Ohh, and I guess I was using the "server mapping" term wrong, I assume that there is a mapping of the client's keyboard, and then appropriate interpretation of the client side keystrokes by the server, according to the mapping. I assumed that the server saves that mapping somewhere, but I'm now guessing that I was wrong and it's the client that has the mapping, and just sends those keystrokes according to its own mapping interpretations to the server to "digest". I'll try not to confuse further with that.
initial scaling induced crash server info
I had to search to find this, thought I'd been meticulous to describe it as a client crash. Once I found what this was referring to, I laughed for a moment ... it would perhaps have been clearer with a comma: "initial scaling induced crash, server info" - that was the xpra info after the scaling induced the "initial client crash". Sorry about that.
I'm also unclear why the new 2x2 default, is it meant to be displaying windows at double the size to the client? (Maybe I'm just not sure why- when I connect, I then immediately end up downscaling, with shift-alt-minus
, to get my windows back to matching the display size/resolution of the rest of my client side applications.)
It feels odd to have the default not try to match the sizing/dpi of the client's general settings.
In my case - initial connection lists:
2015-10-19 18:11:36,586 desktop size is 5120x2160 with 1 screen(s): 2015-10-19 18:11:36,586 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-10-19 18:11:36,586 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120 2015-10-19 18:11:36,586 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120 2015-10-19 18:11:36,586 scaled using 2 x 2 to: 2015-10-19 18:11:36,586 Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060 2015-10-19 18:11:36,586 DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 2560x1060 2015-10-19 18:11:36,586 DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 2560x1060 2015-10-19 18:11:36,786 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10854
I then have to scale down to get it to match...
2015-10-19 18:12:05,936 sending updated screen size to server: 5120x2160 with 1 screens 2015-10-19 18:12:05,936 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-10-19 18:12:05,936 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120 2015-10-19 18:12:05,936 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120
Though, perhaps to answer my own question, the bandwidth is considerably lower if I use the 2x2 scaling to make the window contents larger rather than using the ctrl-+ functionality of the browser. (Maybe I'm just insane to leave the 4k at 4k resolution?)
And, while this maybe should be obvious, testing the combination of scaling +/- and using ctrl-+/- seems to have triggered a server crash (trying to repro isn't immediately successful though, so I couldn't confirm whether or not I just managed to use up all the server vm's resources):
[xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. python2: xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. 2015-10-19 18:20:25,391 sound-source stopping Aborted (core dumped)
--desktop-scaling=auto
works as expected (with the 2x2).
--desktop-scaling=0.73
, --desktop-scaling=1
, desktop=-scaling=1.6
, as well as --desktop-scaling=3/2
all work as expected.
-d cursor
mentioned above later.)
It is actually windows 8.1 that I'm testing with (bootcamped on a mac mini with the mac Intel graphics card).
(expletives removed) - I'm going to have to install that thing somewhere, because my win32 DPI code looks borken: SetProcessDPIAwareness(1) failed: function 'SetProcessDPIAwareness' not found
.. I assumed that the server saves that mapping somewhere, but I'm now guessing that I was wrong and it's the client that has the mapping, and just sends those keystrokes according to its own mapping interpretations to the server to "digest". I'll try not to confuse further with that.
Actually, it's almost correct: the server has the mapping, but the client does almost no interpretation of the key events and just forwards them to the server, as raw as we can get them. Hence why when you report a client debug log, there is no server mapping involved at all.
I'm also unclear why the new 2x2 default, is it meant to be displaying windows at double the size to the client?
Yes. As per comment:4 : r10622 adds the "auto" mode, which will automatically enable scaling for client resolutions above 1080p: 150% up to WQXGA, 200% up to UHD, 300% for FUHD and 400% above that
And "auto" is the now the default as per comment:15 : Since this works well enough, I have made "auto" mode the default in r10831. This is a big change.
The point of this scaling is also covered in the ticket description and comments.
It feels odd to have the default not try to match the sizing/dpi of the client's general settings.
Unless there are DPI bugs, it should match: we report the screen size to the server as being smaller (half the width and height in your 4k test case) and so the DPI will be halved too (which we then double up when we re-upscale the window client side), so DPI aware applications should render at the same size as before, with somewhat bigger pixels but using a lot less bandwidth.
xterm is not DPI aware, at least for its characters - the mouse cursor is handled differently though.
Maybe I'm just insane to leave the 4k at 4k resolution?
Most users will be running their 4k monitors at 4k resolution, this allows us to support them without completely hammering the server.
seems to have triggered a server crash
Indeed.
If you can reproduce this one, a gdb backtrace would be very nice to have, it looks like a hard server crash that will need fixing.
Edit: we now rate limit those scaling changes in r10919 but you can also change the rate limit using XPRA_SCALING_EMBARGO_TIME=DELAY
where the delay is in milliseconds: using 0 would disable the new rate limiting code - potentially allowing you to more easily reproduce that crash.
Unless there are DPI bugs, it should match: we report the screen size to the server as being smaller (half the width and height in your 4k test case) and so the DPI will be halved too (which we then double up when we re-upscale the window client side), so DPI aware applications should render at the same size as before
Ok, I think I've finally pinned down why I was feeling like I was taking crazy pills. This description was what I thought the intention was, but looking at what's going on with tests on a 4k monitor, it looks like the opposite is what I'm seeing.
When I connect, the client side output is the following:
2015-10-20 10:18:55,039 Xpra gtk2 client version 0.16.0-r10921 2015-10-20 10:18:55,039 running on Microsoft Windows 8 2015-10-20 10:18:56,003 OpenGL_accelerate module loaded 2015-10-20 10:18:56,019 OpenGL enabled with Intel(R) HD Graphics 4000 2015-10-20 10:18:56,112 receiving data using AES encryption 2015-10-20 10:18:56,253 sending data using AES encryption 2015-10-20 10:18:56,346 detected keyboard: layout=us 2015-10-20 10:18:56,346 desktop size is 5120x2160 with 1 screen(s): 2015-10-20 10:18:56,346 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-10-20 10:18:56,346 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-10-20 10:18:56,346 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-10-20 10:18:56,346 scaled using 2 x 2 to: 2015-10-20 10:18:56,346 Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060 2015-10-20 10:18:56,346 DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 1920x1060 2015-10-20 10:18:56,346 DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 640x340 2015-10-20 10:18:56,815 server: Linux 4.1.5-100.fc21.x8664 Fedora 21 Twenty One, Xpra version 0.16.0-r10916
The initially acknowledged desktop size is correct, and per your description above ("we report the screen size to the server as being smaller (half the width and height in your 4k test case)"), I gather that the "scaled using 2 x 2 ..." is the lie the client is telling the server.
The server seems to be believing the lie:
2015-10-20 10:18:51,621 client root window size is 2560x1080 with 1 displays: 2015-10-20 10:18:51,621 Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060 2015-10-20 10:18:51,621 DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 1920x1060 2015-10-20 10:18:51,621 DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 640x340 2015-10-20 10:18:51,879 server virtual display now set to 3200x1080 (best match for 2560x1080) 2015-10-20 10:18:51,881 setting key repeat rate from client: 500ms delay / 33ms interval 2015-10-20 10:18:51,882 setting keyboard layout to 'us' 2015-10-20 10:18:51,953 DPI set to 96 x 96
The problem seems to be that neither the server nor the client seems to then be taking that 2 x 2, DPI: 78x80 and scaling it back to the DPI: 157x160 display that I'm expecting - which is why I keep having to use shift-alt-minus
to get it back to the display size I'm expecting.
desktop-scaling=auto 2x scaled on 4k window on left, local 157x160 DPI browser on right - don't match
I won't try to squeeze this scaled down image into the ticket, but the browser on the left in the screenshot is a scaled chromium, while the one on the right is a local chrome browser. The scaled xpra window seems to be displaying at 78x80 DPI listed in what I assumed was the lie to the server, while the local seems to be displaying at what I presume is the 157x160 DPI that is the pre-lie value indicated in client output - and if I use shift-alt-minus
or shift-alt-*
, the applications seem to display the same size, and client output indicates at that point that it is a 157x160 DPI display.
I also noticed that the client output is indicating running on Microsoft Windows 8
, but checking shows that the local machine is convinced that it is running windows 8.1 Enterprise.
Testing with other resolutions/DPI settings, with the 4k pretending to be a 1080p, the auto setting doesn't scale, with 1920x1440 it scales at 1.5x, so it looks like the auto settings are triggering as expected (just not being "scaled back up to client DPI settings ... at 1.5x with the 1920x1440 the windows again displayed as if I'd lowered the resolution for them).
Haven't been able to repro the server crash, but I think I'd left the session running idle for a couple of days prior... so I'll try again to see if overnight is liable to help trigger.
Testing the osx laptop keyboard layout keys - osx 0.16.0 r10922 against 0.16.0 r10916 fedora 21 server:
shift+fn+option/alt+=/+
seems be working as expected now, with the shift part causing the gtk_view_keyboard tool to register the "=/+" to interpret as a "+".
shift-fn-option/alt--/_
, however, still is failing to work - despite checking the key-shortcuts showing Meta+Shift+underscore:scaledown
. As an experiment I added --key-shortcut=Meta+Shift+Underscore:scaledown
, at which point it worked as expected... which was odd, since the gtk_view_keyboard tool does list it as "underscore"... even more confusing, though, is that when I tried it a second time adding --key-shortcut=Meta+Shift+Asterisk:scalereset
it not only failed to work, but afterward I couldn't get the original underscore key shortcut to work again (???).
down Alt_L 65513 64 1 0 ['2'] up Alt_L 65513 64 1 0 ['2', '1']
... though, testing with both to see what the effect on the scaled windows would be, it looks like the control-plus/minus key combo is scaling the browser application (as expected), while the fn-alt is being interpreted as an alt key and working (or not working) as described above.
Checking with -d keyboard
, the only difference I can see is that the control key has a keyval:65507, while the fn-alt has a keyval:65513.
Of course, testing the shift-alt-plus
eventually also triggered a client crash:
2015-10-20 16:17:11,180 sending updated screen size to server: 4869x4096 with 1 screens 2015-10-20 16:17:11,180 schadenfreude.local (1044x878 mm - DPI: 118x118) 2015-10-20 16:17:11,180 monitor 1 2763x1727 at 2105x2368 (592x370 mm - DPI: 118x118) 2015-10-20 16:17:11,180 monitor 2 4211x2368 (903x508 mm - DPI: 118x118) 2015-10-20 16:18:00,542 sending updated screen size to server: 2434x2048 with 1 screens 2015-10-20 16:18:00,542 schadenfreude.local (1044x878 mm - DPI: 59x59) 2015-10-20 16:18:00,542 monitor 1 1381x863 at 1052x1184 (592x370 mm - DPI: 59x59) 2015-10-20 16:18:00,542 monitor 2 2105x1184 (903x508 mm - DPI: 59x59) 2015-10-20 16:18:03,606 sending updated screen size to server: 1217x1024 with 1 screens 2015-10-20 16:18:03,606 schadenfreude.local (1044x878 mm - DPI: 29x29) 2015-10-20 16:18:03,606 monitor 1 690x431 at 526x592 (592x370 mm - DPI: 29x29) 2015-10-20 16:18:03,606 monitor 2 1052x592 (903x508 mm - DPI: 29x29) 2015-10-20 16:18:22,845 sending updated screen size to server: 608x512 with 1 screens 2015-10-20 16:18:22,846 schadenfreude.local (1044x878 mm - DPI: 14x14) 2015-10-20 16:18:22,846 monitor 1 345x215 at 263x296 (592x370 mm - DPI: 14x14) 2015-10-20 16:18:22,846 monitor 2 526x296 (903x508 mm - DPI: 14x14) 2015-10-20 16:19:38,446 sending updated screen size to server: 1217x1024 with 1 screens 2015-10-20 16:19:38,446 schadenfreude.local (1044x878 mm - DPI: 29x29) 2015-10-20 16:19:38,447 monitor 1 690x431 at 526x592 (592x370 mm - DPI: 29x29) 2015-10-20 16:19:38,447 monitor 2 1052x592 (903x508 mm - DPI: 29x29) 2015-10-20 16:19:49,376 sending updated screen size to server: 2434x2048 with 1 screens 2015-10-20 16:19:49,377 schadenfreude.local (1044x878 mm - DPI: 59x59) 2015-10-20 16:19:49,377 monitor 1 1381x863 at 1052x1184 (592x370 mm - DPI: 59x59) 2015-10-20 16:19:49,377 monitor 2 2105x1184 (903x508 mm - DPI: 59x59) 2015-10-20 16:20:03,097 sending updated screen size to server: 1217x1024 with 1 screens 2015-10-20 16:20:03,097 schadenfreude.local (1044x878 mm - DPI: 29x29) 2015-10-20 16:20:03,097 monitor 1 690x431 at 526x592 (592x370 mm - DPI: 29x29) 2015-10-20 16:20:03,097 monitor 2 1052x592 (903x508 mm - DPI: 29x29) /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10922/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:331: GtkWarning: gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed Bus error: 10
It wasn't clear that this is another OpenGL issue, but I went ahead and grabbed the OpengGL info off this client as well (spoiler alert, it's an osx with an intel video card... I used --opengl=on
out of habit, though I suppose it wasn't necessary):
OpenGL_accelerate module loaded OpenGL properties: * GLU extensions : * GLU version : 1.3 MacOSX * display_mode : SINGLE * gdkgl.version : 1.0 * gdkglext.version : 1.2.0 * gtkglext.version : 1.2.0 * has_alpha : True * max-viewport-dims : (16384, 16384) * opengl : 2.1 * pygdkglext.version : 1.0.0 * pyopengl : 3.1.1a1 * renderer : Intel Iris OpenGL Engine * rgba : True * safe : True * shading language version : 1.20 * texture-size-limit : 16384 * vendor : Intel Inc. * zerocopy : True
I also noticed that the client output is indicating running on Microsoft Windows 8, but checking shows that the local machine is convinced that it is running windows 8.1 Enterprise.
This has got to be the most epic fail I have ever seen from Microsoft (and they've had some astonishing ones already, but this one takes the cake). They broke it and introduced an API that is so bad, I had to check 3 times that this was not a joke. It isn't.
There will be a workaround in Python 2.7.11: http://bugs.python.org/issue19143, so we will just have to wait for it.
The problem seems to be that neither the server nor the client seems to then be taking that 2 x 2, DPI: 78x80 and scaling it back to the DPI: 157x160 display that I'm expecting - which is why I keep having to use shift-alt-minus to get it back to the display size I'm expecting.
No. As can be seen in the output:
If the window contents look too big, then that's because the application being used is not honouring the DPI we set (and I would have expected this to be reported in #163). Minor fixes in r10928 and r10929, maybe this will help? If not, please see #163 for instructions on checking the server's DPI values, as there is more than one... Also note that some applications will only query the DPI on startup and will not re-adjust if the display geometry is changed afterwards.
Looking at the screenshot, the window contents are indeed bigger, but not by a factor of 2, more like 1.5 which is odd. Maybe the application is taking the DPI into account, but not using a linear scale as you would expect? We could change the heuristics to scale by 1.5 instead of 2.0 for 4k (please try it using the command line switch), and lower or none at all for lower resolutions, but maybe the application will use a different DPI then... testing will tell.
Of course, testing the shift-alt-plus eventually also triggered a client crash: (..)
monitor 1 2763x1727 at 2105x2368 (592x370 mm - DPI: 118x118)
monitor 2 4211x2368 (903x508 mm - DPI: 118x118)
Is this a real monitor??
Where did you find a monitor with such odd (literally) numbers of pixels?
What revision was this? Judging by the lack of scaling change rate throttling, this isn't the latest?
Can you also trigger this crash by toggling opengl on and off repeatedly, or only when scaling up and down repeatedly?
Unlike the win32 crash, this one is not happening at the highest scaling possible (you had a 14x14 DPI higher up in the log).
It looks like scaling by 8 is the limit on this particular system, but it would be good to know the limit on more systems so we can come up with a hard limit that is unlikely to ever trigger a crash.
It wasn't clear that this is another OpenGL issue, ...
Right, and maybe it isn't:
The cursor size problem should now be fixed in r10941 (+r10942 for applications start with start / start-child), we needed to:
I was testing with the latest OSX client I could lay my hands on when I produced that crash - 0.16.0 r10922 (our build, against a 0.16.0 r10916 fedora 21 server from your repo).
I was also able to produce another crash with --opengl=off
and only using the laptop display (taking stock of my usual machines for testing, I realize that they are all running with Intel graphics cards... the horror)... and the crash triggered an OSX Problem Report & traceback (I'll also include some of the desktop size change output prior):
2015-10-21 17:32:05,096 sending updated screen size to server: 840x525 with 1 screens 2015-10-21 17:32:05,096 schadenfreude.local (592x370 mm - DPI: 36x36) 2015-10-21 17:32:05,096 monitor 1 2015-10-21 17:32:18,553 sending updated screen size to server: 1680x1050 with 1 screens 2015-10-21 17:32:18,553 schadenfreude.local (592x370 mm - DPI: 72x72) 2015-10-21 17:32:18,553 monitor 1 2015-10-21 17:36:34,428 sending updated screen size to server: 840x525 with 1 screens 2015-10-21 17:36:34,428 schadenfreude.local (592x370 mm - DPI: 36x36) 2015-10-21 17:36:34,428 monitor 1 2015-10-21 17:37:24,168 sending updated screen size to server: 420x262 with 1 screens 2015-10-21 17:37:24,169 schadenfreude.local (592x370 mm - DPI: 18x17) 2015-10-21 17:37:24,169 monitor 1 2015-10-21 17:37:39,615 sending updated screen size to server: 210x131 with 1 screens 2015-10-21 17:37:39,615 schadenfreude.local (592x370 mm - DPI: 9x8) 2015-10-21 17:37:39,616 monitor 1 2015-10-21 17:37:40,521 UI thread is now blocked 2015-10-21 17:37:45,819 UI thread is running again, resuming 2015-10-21 17:37:46.489 xpra[38150:d0b] _NXPlaceWindow: error setting window shape (1000) 2015-10-21 17:37:46.490 xpra[38150:d0b] _NSShapeRoundedWindowWithWeighting: error setting window shape (1000) 2015-10-21 17:38:07,064 sending updated screen size to server: 105x65 with 1 screens 2015-10-21 17:38:07,064 schadenfreude.local (592x370 mm - DPI: 4x4) 2015-10-21 17:38:07,064 monitor 1 2015-10-21 17:38:07.329 xpra[38150:d0b] An uncaught exception was raised 2015-10-21 17:38:07.332 xpra[38150:d0b] Error (1007) creating CGSWindow on line 263 2015-10-21 17:38:07.349 xpra[38150:d0b] ( 0 CoreFoundation 0x925d1471 __raiseError + 193 1 libobjc.A.dylib 0x92c24091 objc_exception_throw + 162 2 CoreFoundation 0x925d138b +[NSException raise:format:] + 139 3 AppKit 0x94ceaf23 _NSCreateWindowWithOpaqueShape2 + 1718 4 AppKit 0x94ce99aa -[NSWindow _commonAwake] + 4391 5 AppKit 0x94bbe56b -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 864 6 AppKit 0x94bbdb53 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1090 7 AppKit 0x94bbd70a -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70 8 AppKit 0x953b24b0 -[NSWindow initWithContentRect:styleMask:backing:defer:screen:] + 79 9 libgdk-quartz-2.0.0.dylib 0x02f03ef6 -[GdkQuartzWindow initWithContentRect:styleMask:backing:defer:screen:] + 118 10 libgdk-quartz-2.0.0.dylib 0x02f187c2 _gdk_window_impl_new + 1066 11 libgdk-quartz-2.0.0.dylib 0x02ef00da gdk_window_new + 1265 12 libgtk-quartz-2.0.0.dylib 0x02ca9452 gtk_window_realize + 918 13 libgobject-2.0.0.dylib 0x0330ef08 g_cclosure_marshal_VOID__VOID + 170 14 libgobject-2.0.0.dylib 0x0330c7d5 g_type_class_meta_marshal + 97 15 libgobject-2.0.0.dylib 0x0330c17a g_closure_invoke + 366 16 libgobject-2.0.0.dylib 0x03325c9f signal_emit_unlocked_R + 597 17 libgobject-2.0.0.dylib 0x033254ad g_signal_emit_valist + 3568 18 libgobject-2.0.0.dylib 0x0332590b g_signal_emit + 44 19 libgtk-quartz-2.0.0.dylib 0x02c912b8 gtk_widget_realize + 446 20 libgtk-quartz-2.0.0.dylib 0x02ca8b43 gtk_window_show + 293 21 libgobject-2.0.0.dylib 0x0330ef77 g_cclosure_marshal_VOID__VOIDv + 105 22 libgobject-2.0.0.dylib 0x0330c840 g_type_class_meta_marshalv + 105 23 libgobject-2.0.0.dylib 0x0330c401 _g_closure_invoke_va + 375 24 libgobject-2.0.0.dylib 0x03324c6f g_signal_emit_valist + 1458 25 libgobject-2.0.0.dylib 0x0332590b g_signal_emit + 44 26 libgtk-quartz-2.0.0.dylib 0x02c907eb gtk_widget_show + 219 27 _gtk.so 0x03ce6c15 _wrap_gtk_widget_show + 46 28 libpython2.7.dylib 0x00011575 PyObject_Call + 85 29 libpython2.7.dylib 0x000c01fe PyEval_CallObjectWithKeywords + 78 30 libpython2.7.dylib 0x0002f794 methoddescr_call + 260 31 libpython2.7.dylib 0x00011575 PyObject_Call + 85 32 libpython2.7.dylib 0x000c2a24 PyEval_EvalFrameEx + 5556 33 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 34 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 35 libpython2.7.dylib 0x000434bb function_call + 139 36 libpython2.7.dylib 0x00011575 PyObject_Call + 85 37 libpython2.7.dylib 0x00022d5e instancemethod_call + 350 38 libpython2.7.dylib 0x00011575 PyObject_Call + 85 39 libpython2.7.dylib 0x000c4656 PyEval_EvalFrameEx + 12774 40 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 41 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 42 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 43 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 44 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 45 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 46 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 47 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 48 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 49 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 50 libpython2.7.dylib 0x000434bb function_call + 139 51 libpython2.7.dylib 0x00011575 PyObject_Call + 85 52 libpython2.7.dylib 0x000c4656 PyEval_EvalFrameEx + 12774 53 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 54 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 55 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 56 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 57 libpython2.7.dylib 0x000434bb function_call + 139 58 libpython2.7.dylib 0x00011575 PyObject_Call + 85 59 libpython2.7.dylib 0x00022d5e instancemethod_call + 350 60 libpython2.7.dylib 0x00011575 PyObject_Call + 85 61 libpython2.7.dylib 0x000c01fe PyEval_CallObjectWithKeywords + 78 62 libpython2.7.dylib 0x00011620 PyObject_CallObject + 32 63 _gtk.so 0x03cf9ee7 _wrap_GtkWidget__proxy_do_key_press_event + 370 64 libgtk-quartz-2.0.0.dylib 0x02b1dc39 _gtk_marshal_BOOLEAN__BOXED + 225 65 libgobject-2.0.0.dylib 0x0330c7d5 g_type_class_meta_marshal + 97 66 libgobject-2.0.0.dylib 0x0330c17a g_closure_invoke + 366 67 libgobject-2.0.0.dylib 0x03326085 signal_emit_unlocked_R + 1595 68 libgobject-2.0.0.dylib 0x0332554b g_signal_emit_valist + 3726 69 libgobject-2.0.0.dylib 0x0332590b g_signal_emit + 44 70 libgtk-quartz-2.0.0.dylib 0x02c93d2d gtk_widget_event_internal + 846 71 libgtk-quartz-2.0.0.dylib 0x02c937ac gtk_widget_event + 283 72 libgtk-quartz-2.0.0.dylib 0x02b1c147 gtk_propagate_event + 519 73 libgtk-quartz-2.0.0.dylib 0x02b1ac77 gtk_main_do_event + 1211 74 libgdk-quartz-2.0.0.dylib 0x02f0a692 gdk_event_dispatch + 130 75 libglib-2.0.0.dylib 0x0338f8d5 g_main_dispatch + 393 76 libglib-2.0.0.dylib 0x033905f0 g_main_context_dispatch + 41 77 libglib-2.0.0.dylib 0x033907cf g_main_context_iterate + 466 78 libglib-2.0.0.dylib 0x03390c01 g_main_loop_run + 476 79 libgtk-quartz-2.0.0.dylib 0x02b1a127 gtk_main + 239 80 _gtk.so 0x03e221af _wrap_gtk_main + 129 81 libpython2.7.dylib 0x000c75ab PyEval_EvalFrameEx + 24891 82 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 83 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 84 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 85 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 86 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 87 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 88 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 89 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 90 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 91 libpython2.7.dylib 0x000ca097 PyEval_EvalCode + 87 92 libpython2.7.dylib 0x000ef73d PyRun_StringFlags + 285 93 libpython2.7.dylib 0x000ef84e PyRun_SimpleStringFlags + 78 94 libpython2.7.dylib 0x00106a0c Py_Main + 1564 95 xpra 0x00002fb6 start + 54 ) 2015-10-21 17:38:07.351 xpra[38150:d0b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1007) creating CGSWindow on line 263' *** Call stack at first throw: ( 0 CoreFoundation 0x925d1471 __raiseError + 193 1 libobjc.A.dylib 0x92c24091 objc_exception_throw + 162 2 CoreFoundation 0x925d138b +[NSException raise:format:] + 139 3 AppKit 0x94ceaf23 _NSCreateWindowWithOpaqueShape2 + 1718 4 AppKit 0x94ce99aa -[NSWindow _commonAwake] + 4391 5 AppKit 0x94bbe56b -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 864 6 AppKit 0x94bbdb53 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1090 7 AppKit 0x94bbd70a -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70 8 AppKit 0x953b24b0 -[NSWindow initWithContentRect:styleMask:backing:defer:screen:] + 79 9 libgdk-quartz-2.0.0.dylib 0x02f03ef6 -[GdkQuartzWindow initWithContentRect:styleMask:backing:defer:screen:] + 118 10 libgdk-quartz-2.0.0.dylib 0x02f187c2 _gdk_window_impl_new + 1066 11 libgdk-quartz-2.0.0.dylib 0x02ef00da gdk_window_new + 1265 12 libgtk-quartz-2.0.0.dylib 0x02ca9452 gtk_window_realize + 918 13 libgobject-2.0.0.dylib 0x0330ef08 g_cclosure_marshal_VOID__VOID + 170 14 libgobject-2.0.0.dylib 0x0330c7d5 g_type_class_meta_marshal + 97 15 libgobject-2.0.0.dylib 0x0330c17a g_closure_invoke + 366 16 libgobject-2.0.0.dylib 0x03325c9f signal_emit_unlocked_R + 597 17 libgobject-2.0.0.dylib 0x033254ad g_signal_emit_valist + 3568 18 libgobject-2.0.0.dylib 0x0332590b g_signal_emit + 44 19 libgtk-quartz-2.0.0.dylib 0x02c912b8 gtk_widget_realize + 446 20 libgtk-quartz-2.0.0.dylib 0x02ca8b43 gtk_window_show + 293 21 libgobject-2.0.0.dylib 0x0330ef77 g_cclosure_marshal_VOID__VOIDv + 105 22 libgobject-2.0.0.dylib 0x0330c840 g_type_class_meta_marshalv + 105 23 libgobject-2.0.0.dylib 0x0330c401 _g_closure_invoke_va + 375 24 libgobject-2.0.0.dylib 0x03324c6f g_signal_emit_valist + 1458 25 libgobject-2.0.0.dylib 0x0332590b g_signal_emit + 44 26 libgtk-quartz-2.0.0.dylib 0x02c907eb gtk_widget_show + 219 27 _gtk.so 0x03ce6c15 _wrap_gtk_widget_show + 46 28 libpython2.7.dylib 0x00011575 PyObject_Call + 85 29 libpython2.7.dylib 0x000c01fe PyEval_CallObjectWithKeywords + 78 30 libpython2.7.dylib 0x0002f794 methoddescr_call + 260 31 libpython2.7.dylib 0x00011575 PyObject_Call + 85 32 libpython2.7.dylib 0x000c2a24 PyEval_EvalFrameEx + 5556 33 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 34 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 35 libpython2.7.dylib 0x000434bb function_call + 139 36 libpython2.7.dylib 0x00011575 PyObject_Call + 85 37 libpython2.7.dylib 0x00022d5e instancemethod_call + 350 38 libpython2.7.dylib 0x00011575 PyObject_Call + 85 39 libpython2.7.dylib 0x000c4656 PyEval_EvalFrameEx + 12774 40 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 41 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 42 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 43 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 44 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 45 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 46 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 47 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 48 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 49 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 50 libpython2.7.dylib 0x000434bb function_call + 139 51 libpython2.7.dylib 0x00011575 PyObject_Call + 85 52 libpython2.7.dylib 0x000c4656 PyEval_EvalFrameEx + 12774 53 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 54 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 55 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 56 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 57 libpython2.7.dylib 0x000434bb function_call + 139 58 libpython2.7.dylib 0x00011575 PyObject_Call + 85 59 libpython2.7.dylib 0x00022d5e instancemethod_call + 350 60 libpython2.7.dylib 0x00011575 PyObject_Call + 85 61 libpython2.7.dylib 0x000c01fe PyEval_CallObjectWithKeywords + 78 62 libpython2.7.dylib 0x00011620 PyObject_CallObject + 32 63 _gtk.so 0x03cf9ee7 _wrap_GtkWidget__proxy_do_key_press_event + 370 64 libgtk-quartz-2.0.0.dylib 0x02b1dc39 _gtk_marshal_BOOLEAN__BOXED + 225 65 libgobject-2.0.0.dylib 0x0330c7d5 g_type_class_meta_marshal + 97 66 libgobject-2.0.0.dylib 0x0330c17a g_closure_invoke + 366 67 libgobject-2.0.0.dylib 0x03326085 signal_emit_unlocked_R + 1595 68 libgobject-2.0.0.dylib 0x0332554b g_signal_emit_valist + 3726 69 libgobject-2.0.0.dylib 0x0332590b g_signal_emit + 44 70 libgtk-quartz-2.0.0.dylib 0x02c93d2d gtk_widget_event_internal + 846 71 libgtk-quartz-2.0.0.dylib 0x02c937ac gtk_widget_event + 283 72 libgtk-quartz-2.0.0.dylib 0x02b1c147 gtk_propagate_event + 519 73 libgtk-quartz-2.0.0.dylib 0x02b1ac77 gtk_main_do_event + 1211 74 libgdk-quartz-2.0.0.dylib 0x02f0a692 gdk_event_dispatch + 130 75 libglib-2.0.0.dylib 0x0338f8d5 g_main_dispatch + 393 76 libglib-2.0.0.dylib 0x033905f0 g_main_context_dispatch + 41 77 libglib-2.0.0.dylib 0x033907cf g_main_context_iterate + 466 78 libglib-2.0.0.dylib 0x03390c01 g_main_loop_run + 476 79 libgtk-quartz-2.0.0.dylib 0x02b1a127 gtk_main + 239 80 _gtk.so 0x03e221af _wrap_gtk_main + 129 81 libpython2.7.dylib 0x000c75ab PyEval_EvalFrameEx + 24891 82 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 83 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 84 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 85 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 86 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 87 libpython2.7.dylib 0x000c7cdb PyEval_EvalFrameEx + 26731 88 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 89 libpython2.7.dylib 0x000c96cf PyEval_EvalFrameEx + 33375 90 libpython2.7.dylib 0x000c9f4c PyEval_EvalCodeEx + 2012 91 libpython2.7.dylib 0x000ca097 PyEval_EvalCode + 87 92 libpython2.7.dylib 0x000ef73d PyRun_StringFlags + 285 93 libpython2.7.dylib 0x000ef84e PyRun_SimpleStringFlags + 78 94 libpython2.7.dylib 0x00106a0c Py_Main + 1564 95 xpra 0x00002fb6 start + 54 ) Trace/BPT trap: 5 Schadenfreude:MacOS Schadenfreude$ 2015-10-21 17:38:07,907 sound-sink stopping
Testing some of those issues with the key shortcuts, I noticed that the laptop, when using "fn-option/alt" in place of alt, seemed to also be triggering some of the OSX versions of the key-sym shortcuts:
shift-fn-option/alt-minus
, when watched with -d keyboard
, was producing Shift_L
, Alt_L
, and... emdash
(don't you love it?).
shift-fn-option/alt-asterisk
was producing Shift_L
, Alt-L
, and ... degree
.
So, using --key-shortcut=Meta+Shift+emdash:scaledown
& --key-shortcut=Meta+Shift+degree:scalereset
seems to be working to use what looks like a -
and a *
with the shift-alt to produce effects similar to the ones with a numpad.
However, it looks like the fn-option/alt is sometimes triggering, with browsers, zooming (I'll continue to chase that one down, maybe I was just doing something silly while distracted).
As for the dimensions of those monitors - I'm not sure what happened to those values. Scaling up and down and all around seemed to be producing some extremely strange values (the default dpi when I connect with just the laptop display is 72x72, and when I connect with the second monitor connected it scales 2x2 and uses 36x36... maybe I happened to also be trying some other --desktop-scaling=
value?). Unfortunately, scaling up often sizes up applications to the point where they cover the entire display, so I'm not sure what the values are doing until I look at the command line later.
Also worth mentioning, when I launch other applications (google-chrome, firefox, epiphany, gedit) from an xterm on a scaled client (due to new defaults with large workspace) - they all seem to also be unwilling to respect the scaling back up that the client is supposed to be doing.
I'll do more testing of the DPI (per #163) and include any further info on that issue there.
I was testing with the latest OSX client I could lay my hands on when I produced that crash - 0.16.0 r10922 (our build, against a 0.16.0 r10916 fedora 21 server from your repo).
It would be good to know if the crash was caused by the scaling, or by the window becoming too big. Testing with a newer client would help.
In any case r10950 now limits upscaling to 8 times, as going above that is what triggers crashes on win32 and osx. Hopefully this limit is now low enough to avoid crashes on all platform + card combinations.
Thanks for the new osx shortcuts, added in r10951.
However, it looks like the fn-option/alt is sometimes triggering, with browsers, zooming (I'll continue to chase that one down, maybe I was just doing something silly while distracted).
Ouch. Browsers often scale up/down with control + plus/minus. Maybe Alt is being dropped, and so we don't intercept the key combo as a shortcut and pass it to the browser..
maybe I happened to also be trying some other --desktop-scaling= value?
Yes, that must be it.
Also worth mentioning, when I launch other applications .. they all seem to also be unwilling to respect the scaling back up that the client is supposed to be doing.
r10953, r10966 and r10970 should fix that: the "hardware" dpi was correctly updated, but the xsettings one was not (I thought google-chrome was using the "hardware" one? maybe not then)
r10967 changes by how much we adjust the scaling using the key shortcuts (was 100% increase, now just 50% at a time)
Simple apps like gnome-calculator and most of our GTK test apps do seem to adjust to the new DPI settings.
If you find that with the default scaling factor (or even with a custom one), the browser rendering is very different - it would be worth taking a snapshot of a local and remote browser side by side showing the same page to see by how much things are diverging - and if this is the same ratio as the scaling factor. (say a fixed size picture, some font, a youtube video, etc..)
Hmm... testing with osx 0.16.0 r10972 I was getting decoding problems (#1010), but ignoring those, I decided to try changing the screen resolution values (through System Preferences menu) up and down to see what would happen with the resolution of the applications (especially chromium).
It seemed like the content of the chromium window was not changing resolution, though oddly the window itself kept resizing as if I had maximized it with every local resolution change.
After a number of screen resolution changes, and attendant workarea changes, the client crashed (seemed stable enough despite the decoding errors in #1010, leading me to suspect crash is related to the resolution changes). Here are some of the size changes, and some of the tracebacks (editing to remove some repetitions):
Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 275, in on_realize File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 62, in get_xid AttributeError: xid attribute not supported 2015-10-23 15:17:11,255 server is not responding, drawing spinners over the windows 2015-10-23 15:17:23,086 server is OK again 2015-10-23 15:17:36,851 sending updated screen size to server: 1920x1680 with 1 screens 2015-10-23 15:17:36,851 schadenfreude.local (903x790 mm - DPI: 54x54) 2015-10-23 15:17:36,851 monitor 1 960x600 at 960x1080 (451x282 mm - DPI: 54x54) 2015-10-23 15:17:36,852 monitor 2 1920x1080 (903x508 mm - DPI: 54x54) 2015-10-23 15:17:36,852 screen size change: will reinit the windows ... 2015-10-23 15:18:14,130 sending updated screen size to server: 2040x1755 with 1 screens 2015-10-23 15:18:14,131 schadenfreude.local (959x825 mm - DPI: 54x54) 2015-10-23 15:18:14,131 monitor 1 1080x675 at 960x1080 (508x317 mm - DPI: 54x54) 2015-10-23 15:18:14,131 monitor 2 1920x1080 (903x508 mm - DPI: 54x54) 2015-10-23 15:18:14,131 screen size change: will reinit the windows ... 2015-10-23 15:18:53,842 sending updated screen size to server: 2220x1867 with 1 screens 2015-10-23 15:18:53,842 schadenfreude.local (1044x878 mm - DPI: 54x54) 2015-10-23 15:18:53,843 monitor 1 1260x787 at 960x1080 (592x370 mm - DPI: 54x54) 2015-10-23 15:18:53,843 monitor 2 1920x1080 (903x508 mm - DPI: 54x54) 2015-10-23 15:18:53,843 screen size change: will reinit the windows 2015-10-23 15:18:53,872 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)} Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 275, in on_realize File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 62, in get_xid AttributeError: xid attribute not supported Bus error: 10 Schadenfreude:MacOS Schadenfreude$ 2015-10-23 15:18:54,978 sound-sink stopping
Repro'ing rather easily, I got a different traceback:
2015-10-23 17:19:30,338 sending updated screen size to server: 2960x1950 with 1 screens 2015-10-23 17:19:30,338 schadenfreude.local (1044x687 mm - DPI: 72x72) 2015-10-23 17:19:30,339 monitor 1 1680x1050 at 1280x900 (592x370 mm - DPI: 72x72) 2015-10-23 17:19:30,339 monitor 2 1600x900 (564x317 mm - DPI: 72x72) 2015-10-23 17:19:30,339 screen size change: will reinit the windows /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:433: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:434: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk_compat.py:101: GtkWarning: gtk_widget_set_colormap: assertion 'GDK_IS_COLORMAP (colormap)' failed /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-16-10972/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:321: GtkWarning: gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed Bus error: 10 Schadenfreude:MacOS Schadenfreude$ 2015-10-23 17:19:30,863 sound-sink stopping
The scaling changes should trigger exactly the same code as the "screen size change": in both cases we re-init the windows... But if the crash from comment:28 only ever occurs with "screen size change" then it should go in a new ticket. (one I have no idea how I would fix - but maybe this a regression? in which case we could do something)
Minor fixup for handling window move/resize in r11029.
Another important fix: r11058, triggered by testing with browser/xpra/trunk/src/tests/xpra/test_apps/test_window_moveresize.py as part of testing for #990... (confused me for hours thinking there was a bug in the changes from #990). So it is worth testing with more of those test applications to find corner cases.
Well, with windows client 0.16.0 r10983, against 0.16.0 r11031 fedora 21 server, I went back through the dpi tests listed in both #163 & #697 - but all dpi and client.screen checks seemed to be in agreement with the desktop & display info output by both client and server upon each re-init.
I'll have to dig deeper to see if I can find more info about application dpi settings, I guess... to see why the windows and content still seem larger than local applications.
Will build some new clients to re-test for comment:29 & comment:30 soon as well.
r11089 (+ r11094 for osx) makes it a little bit easier to test scaling by adding a tray menu entry to choose scaling values, those scaling values can be overriden with:
XPRA_TRAY_SCALING_OPTIONS=0.4,0.5,2.0,4.0 xpra attach ..
(note: the values are floating point numbers, which we show to the user as percentages - maybe the command line should take percentages too?)
Be aware of #559. Sub pixel rendering will help smooth things when upscaling. (and this ticket doesn't look like it really got tested properly)
Hmmm... scaling up a session with just a pair of xterms (re-testing #559 a bit), I'm seeing the following traceback on windows 8.1 client 0.16.0 r11122 (against same revision fedora 21 server):
2015-11-05 15:29:18,789 draw error Traceback (most recent call last): File "xpra\client\ui_client_base.pyc", line 2493, in _do_draw File "xpra\client\client_window_base.pyc", line 540, in draw_region File "xpra\client\window_backing_base.pyc", line 521, in draw_region File "xpra\client\window_backing_base.pyc", line 301, in paint_rgb32 File "xpra\client\window_backing_base.pyc", line 180, in process_delta Exception: delta region bucket 0 references pixmap data we do not have! 2015-11-05 15:29:18,789 error processing draw packet
It is being reliably triggered when I start with --encodings=rgb
and get the client scaled to:
2015-11-05 15:29:18,576 get_workareas()=[(0, 0, 3840, 2120), (0, 0, 1280, 680)] 2015-11-05 15:29:18,576 get_workarea() absolute total monitor area: (-1280, 0, 3840, 2160) 2015-11-05 15:29:18,576 total monitor dimensions: (5120, 2160) 2015-11-05 15:29:18,576 sending updated screen size to server: 1137x480 with 1 screens 2015-11-05 15:29:18,576 Default (1354x571 mm - DPI: 21x21) workarea: 1137x471 2015-11-05 15:29:18,576 DISPLAY1 853x480 at 284x0 (621x341 mm - DPI: 34x35) workarea: 853x471 2015-11-05 15:29:18,576 DISPLAY2 284x160 (597x336 mm - DPI: 12x12) workarea: 284x151
I couldn't repro with --encodings=
jpg or webp.
... ohh, and, in case it matters, I had XPRA_OPENGL_PAINT_POX=1
set.
Yes, I have seen those "delta region bucket XXX references pixmap data we do not have!" (this can happen with any encoding set if we end up actually using rgb), it's a tricky one to fix as we re-create the windows whilst the server is sending us screen updates, things easily get out of sync. The server will just re-send a new screen update, so I am not going to worry too much about for now.
Note: r11151 fixes windows 8.1 onwards "DPI awareness".
r11162 fixes the resizing loops caused by coordinates rounding, also disables scaling when connecting to older servers and when using mmap.
Glad I saw that message - stumbled across the resizing loop and was just getting ready to make a ticket.
Installed 0.16.0 r11176 windows client and 0.16.0 r11152 (which was pulled from the winswitch.beta repo) - and got the following warning client side:
2015-11-10 10:52:58,446 desktop size is 5120x2160 with 1 screen(s): 2015-11-10 10:52:58,446 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-11-10 10:52:58,446 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-11-10 10:52:58,446 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-11-10 10:52:58,446 scaled using 2 x 2 to: 2560x1080 2015-11-10 10:52:58,446 Default (1354x571 mm - DPI: 48x48) workarea: 2560x1060 2015-11-10 10:52:58,446 DISPLAY1 1920x1080 at 640x0 (621x341 mm - DPI: 78x80) workarea: 1920x1060 2015-11-10 10:52:58,446 DISPLAY2 640x360 (597x336 mm - DPI: 27x27) workarea: 640x340 2015-11-10 10:52:58,634 Xpra X11 server version 0.16.0-r11152 2015-11-10 10:52:58,634 running on Linux Fedora 21 Twenty One 2015-11-10 10:52:58,664 Server does not support rounding, disabling scaling 2015-11-10 10:52:58,664 sending updated screen size to server: 5120x2160 with 1 screens 2015-11-10 10:52:58,680 Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120 2015-11-10 10:52:58,680 DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120 2015-11-10 10:52:58,680 DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680 2015-11-10 10:52:58,680 Server's virtual screen is too small 2015-11-10 10:52:58,680 server: 2560x1080 vs client: 5120x2160 2015-11-10 10:52:58,680 you may see strange behavior, 2015-11-10 10:52:58,680 please see http://xpra.org/trac/wiki/Xdummy#Configuration
... when I noticed that the server side version wasn't the latest, I found I had to yum localinstall your latest rpms (some issue with the build in the repo?).
Even after localinstall - the Session Info is still showing the server as being r11152, and still giving me that warning.
However... if I scale up and down enough (3 to 5 times, or more, in a minute) and then immediately try to disconnect the client (control-C) - the client locks up, requiring use of the task manager to disconnect (the tray icon with the disconnect option becomes as non-responsive as all of the session applications).
Client side, I just see 2015-11-10 13:45:34,364 received console event CTRL_C
, but the application doesn't exit.
Server side I see a whole lot of error messages suggesting that there are some back damage acks that are still being processed, causing the hang up:
2015-11-10 13:45:12,671 sent updated screen size to 1 client: 3200x1080 (max 8192x4096) 2015-11-10 13:45:53,363 delayed_region_timeout: region is 15008ms old, bad connection? 2015-11-10 13:46:08,384 delayed_region_timeout: region is 15014ms old, bad connection? 2015-11-10 13:46:23,423 delayed_region_timeout: region is 15034ms old, bad connection? 2015-11-10 13:46:38,515 delayed_region_timeout: region is 15087ms old, bad connection? 2015-11-10 13:46:38,544 Error: expiring missing damage acks: [6784, 6785, 6786, 6787, 6788, 6789, 6790, 6791, 6792, 6793, 6773, 6774, 6775, 6776, 6777, 6778, 6779, 6780, 6781, 6782, 6783] 2015-11-10 13:46:39,539 Error: expiring missing damage acks: [6794, 6795, 6796, 6797, 6798, 6799, 6800, 6801, 6802] 2015-11-10 13:46:53,702 delayed_region_timeout: region is 15182ms old, bad connection? 2015-11-10 13:47:15,432 delayed_region_timeout: region is 15344ms old, bad connection? 2015-11-10 13:47:30,793 delayed_region_timeout: region is 15356ms old, bad connection? 2015-11-10 13:47:46,045 delayed_region_timeout: region is 15250ms old, bad connection? 2015-11-10 13:48:01,278 delayed_region_timeout: region is 15228ms old, bad connection? 2015-11-10 13:48:01,308 Error: expiring missing damage acks: [6803, 6804, 6805, 6806, 6807, 6808, 6809, 6810, 6811, 6812, 6813, 6814, 6815, 6816, 6817, 6818] 2015-11-10 13:48:16,521 delayed_region_timeout: region is 15241ms old, bad connection? 2015-11-10 13:48:16,536 Error: expiring missing damage acks: [6819] 2015-11-10 13:48:38,313 delayed_region_timeout: region is 15362ms old, bad connection? ...
... Almost forgot comment:32.
Testing with 0.16.0 r11176 osx client (and with same version windows client) against fedora 21 0.16.0 r11178.
I set XPRA_TRAY_SCALING_OPTIONS=0.4,0.5
- but it doesn't seem to be behaving as I would've expected... not sure if it's the behavior that's wrong though, or my expectations.
When I scale "up" (shift-alt-+), with the above environment variable, the dpi scales to 32 in both cases - which is a scaling of 1/3 (assuming mere math applies to dpi). Scaling again, in both cases, scales to a dpi of 21 - which is again a 1/3 factor, adjusted for rounding.
I was expecting (perhaps foolishly?) that the 0.4 and 0.5 values of the variable would be the factor by which the scaling would be applied.
Just as a second check, the osx client default (48 dpi) has workarea of 1707x1660, which scales to 1138x1107, which seems to round up slightly above a factor of .666. Likewise, the windows client with the default (48 dpi) workarea of 2560x1080 scales to 1707x720, a factor of slightly more than .666.
Running again without the environment variable, though, and the (shift-alt-+) scaling seems to scale by the same factors as with the environment variable.
Did I misinterpret what that variable is supposed to do?
not sure if it's the behavior that's wrong though, or my expectations.
This seemed like a reasonable expectation so r11180 does this and also ensures that we show the new scaling value as selected in the systray menu.
Notes:
See also: wiki/DPI
There was a bug in the pixmap backing (opengl=no), which only manifested itself with scaling values lower than 1.0: #1036.
Interestingly, testing for #919 with 0.16.1 r11604 osx client against 0.16.1 fedora 23 server (r11649 I think)... I was re-scaling a display with the local System Preferences, and came across a traceback.
Scaling locally from 2560x1440 to 2048x1152 (with a default desktop-scaling value of 1.5), I had no problems... but when I scaled locally from 2048x1152 to 1600x900 I got the following traceback (further local scaling didn't reproduce... neither with the laptop display nor the second display, neither scaling up nor down).
Server-side, all I got was 2016-01-11 12:34:42,736 Warning: client decoding error: delta region bucket 0 references pixmap data we do not have!
.
Client-side:
2016-01-11 12:34:13,761 sending updated screen size to server: 1707x1468 with 1 screens 2016-01-11 12:34:13,762 schadenfreude.local (903x776 mm - DPI: 48x48) 2016-01-11 12:34:13,762 monitor 1 1120x700 at 587x768 (592x370 mm - DPI: 48x48) 2016-01-11 12:34:13,762 monitor 2 1365x768 (722x406 mm - DPI: 48x48) 2016-01-11 12:34:13,762 screen size change: will reinit the windows 2016-01-11 12:34:30,097 sending updated screen size to server: 1707x1300 with 1 screens 2016-01-11 12:34:30,098 schadenfreude.local (903x687 mm - DPI: 48x48) 2016-01-11 12:34:30,098 monitor 1 1120x700 at 587x600 (592x370 mm - DPI: 48x48) 2016-01-11 12:34:30,098 monitor 2 1067x600 (564x317 mm - DPI: 48x48) 2016-01-11 12:34:30,098 screen size change: will reinit the windows 2016-01-11 12:34:30,285 draw error Traceback (most recent call last): File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2587, in _do_draw window.draw_region(x, y, width, height, coding, data, rowstride, packet_sequence, options, [record_decode_time]) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/client_window_base.py", line 538, in draw_region backing.draw_region(x, y, width, height, coding, img_data, rowstride, options, callbacks) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 521, in draw_region self.paint_rgb32(img_data, x, y, width, height, rowstride, options, callbacks) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 301, in paint_rgb32 rgb32_data = self.process_delta(raw_data, width, height, rowstride, options) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 180, in process_delta raise Exception("delta region bucket %s references pixmap data we do not have!" % bucket) Exception: delta region bucket 0 references pixmap data we do not have! 2016-01-11 12:34:30,291 error processing draw packet Traceback (most recent call last): File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2527, in _draw_thread_loop self._do_draw(packet) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/ui_client_base.py", line 2587, in _do_draw window.draw_region(x, y, width, height, coding, data, rowstride, packet_sequence, options, [record_decode_time]) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/client_window_base.py", line 538, in draw_region backing.draw_region(x, y, width, height, coding, img_data, rowstride, options, callbacks) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 521, in draw_region self.paint_rgb32(img_data, x, y, width, height, rowstride, options, callbacks) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 301, in paint_rgb32 rgb32_data = self.process_delta(raw_data, width, height, rowstride, options) File "/Users/Schadenfreude/Desktop/xpra-catalog/xpra-16-1-ant-11604/Xpra.app/Contents/Resources/lib/python/xpra/client/window_backing_base.py", line 180, in process_delta raise Exception("delta region bucket %s references pixmap data we do not have!" % bucket) Exception: delta region bucket 0 references pixmap data we do not have!
This Exception: delta region bucket 0 references pixmap data we do not have!
can occur when re-initialize the windows because of scaling. I haven't found a workaround yet, but we shouldn't worry too much about it: the picture will just get re-sent and the delta will get reset.
Can we close this?
One last issue (maybe-issue) I can see.
Connecting with --desktop-scaling=1.5,1
, aside from having funny-looking windows, if I scale down past the point where the x-scaling drops below 100%, then the "relative" scaling values seem to be lost... and not restored if I then scale back up past the 100% x-value.
2016-01-11 18:00:42,909 setting scaling to 150% x 100%: 2016-01-11 18:00:42,909 sending updated screen size to server: 1707x2490 with 1 screens 2016-01-11 18:00:42,910 schadenfreude.local (903x878 mm - DPI: 48x72) 2016-01-11 18:00:42,910 monitor 1 1120x1050 at 587x1440 (592x370 mm - DPI: 48x72) 2016-01-11 18:00:42,910 monitor 2 1707x1440 (903x508 mm - DPI: 48x72) 2016-01-11 18:00:48,164 setting scaling to 125% x 83%: 2016-01-11 18:00:48,165 sending updated screen size to server: 2048x2988 with 1 screens 2016-01-11 18:00:48,165 schadenfreude.local (903x878 mm - DPI: 57x86) 2016-01-11 18:00:48,165 monitor 1 1344x1260 at 704x1728 (592x370 mm - DPI: 57x86) 2016-01-11 18:00:48,165 monitor 2 2048x1728 (903x508 mm - DPI: 57x86) 2016-01-11 18:00:53,869 setting scaling to 100% x 67%: 2016-01-11 18:00:53,869 sending updated screen size to server: 2560x3735 with 1 screens 2016-01-11 18:00:53,869 schadenfreude.local (903x878 mm - DPI: 72x108) 2016-01-11 18:00:53,870 monitor 1 1680x1575 at 880x2160 (592x370 mm - DPI: 72x108) 2016-01-11 18:00:53,870 monitor 2 2560x2160 (903x508 mm - DPI: 72x108) 2016-01-11 18:00:57,549 Warning: cannot scale by 0.666 x 0.444 or lower 2016-01-11 18:00:57,549 the scaled client screen 2560 x 2490 -> 3843 x 5608 2016-01-11 18:00:57,549 would overflow the server's screen: 8192 x 4096 2016-01-11 18:00:57,549 using 0.60791015625 x 0.60791015625 -> 4211 x 4096 2016-01-11 18:00:57,550 setting scaling to 61%: 2016-01-11 18:00:57,550 sending updated screen size to server: 4211x4096 with 1 screens 2016-01-11 18:00:57,550 schadenfreude.local (903x878 mm - DPI: 118x118) 2016-01-11 18:00:57,550 monitor 1 2764x1727 at 1448x2369 (592x370 mm - DPI: 118x118) 2016-01-11 18:00:57,551 monitor 2 4211x2369 (903x508 mm - DPI: 118x118) 2016-01-11 18:01:06,717 setting scaling to 67%: 2016-01-11 18:01:06,717 sending updated screen size to server: 3844x3739 with 1 screens 2016-01-11 18:01:06,717 schadenfreude.local (903x878 mm - DPI: 108x108) 2016-01-11 18:01:06,718 monitor 1 2523x1577 at 1321x2162 (592x370 mm - DPI: 108x108) 2016-01-11 18:01:06,718 monitor 2 3844x2162 (903x508 mm - DPI: 108x108) 2016-01-11 18:01:12,317 setting scaling to 100%: 2016-01-11 18:01:12,317 sending updated screen size to server: 2560x2490 with 1 screens 2016-01-11 18:01:12,317 schadenfreude.local (903x878 mm - DPI: 72x72) 2016-01-11 18:01:12,317 monitor 1 1680x1050 at 880x1440 (592x370 mm - DPI: 72x72) 2016-01-11 18:01:12,317 monitor 2 2560x1440 (903x508 mm - DPI: 72x72) 2016-01-11 18:01:14,037 setting scaling to 125%: 2016-01-11 18:01:14,038 sending updated screen size to server: 2048x1992 with 1 screens 2016-01-11 18:01:14,038 schadenfreude.local (903x878 mm - DPI: 57x57) 2016-01-11 18:01:14,038 monitor 1 1344x840 at 704x1152 (592x370 mm - DPI: 57x57) 2016-01-11 18:01:14,038 monitor 2 2048x1152 (903x508 mm - DPI: 57x57) 2016-01-11 18:01:17,853 setting scaling to 150%: 2016-01-11 18:01:17,853 sending updated screen size to server: 1707x1660 with 1 screens 2016-01-11 18:01:17,853 schadenfreude.local (903x878 mm - DPI: 48x48) 2016-01-11 18:01:17,853 monitor 1 1120x700 at 587x960 (592x370 mm - DPI: 48x48) 2016-01-11 18:01:17,853 monitor 2 1707x960 (903x508 mm - DPI: 48x48)
Not sure i'd call this a bug, but my initial expectation would be that the relative-scaling values would be "re-asserted" as the x-value scales back up over 100% (I suppose this would require saving those initial values somewhere to check against).
Oddly, trying with the reverse (--desktop-scaling=1,1.5
, the scaling value "relativity" was preserved longer:
2016-01-11 18:07:38,607 setting scaling to 100% x 150%: 2016-01-11 18:07:38,607 sending updated screen size to server: 2560x1660 with 1 screens 2016-01-11 18:07:38,607 schadenfreude.local (903x878 mm - DPI: 72x48) 2016-01-11 18:07:38,608 monitor 1 1680x700 at 880x960 (592x370 mm - DPI: 72x48) 2016-01-11 18:07:38,608 monitor 2 2560x960 (903x508 mm - DPI: 72x48) 2016-01-11 18:07:39,791 setting scaling to 83% x 125%: 2016-01-11 18:07:39,791 sending updated screen size to server: 3072x1992 with 1 screens 2016-01-11 18:07:39,792 schadenfreude.local (903x878 mm - DPI: 86x57) 2016-01-11 18:07:39,792 monitor 1 2016x840 at 1056x1152 (592x370 mm - DPI: 86x57) 2016-01-11 18:07:39,792 monitor 2 3072x1152 (903x508 mm - DPI: 86x57) 2016-01-11 18:07:41,286 setting scaling to 67% x 100%: 2016-01-11 18:07:41,287 sending updated screen size to server: 3840x2490 with 1 screens 2016-01-11 18:07:41,287 schadenfreude.local (903x878 mm - DPI: 108x72) 2016-01-11 18:07:41,287 monitor 1 2520x1050 at 1320x1440 (592x370 mm - DPI: 108x72) 2016-01-11 18:07:41,287 monitor 2 3840x1440 (903x508 mm - DPI: 108x72) 2016-01-11 18:07:42,382 setting scaling to 44% x 67%: 2016-01-11 18:07:42,383 sending updated screen size to server: 5766x3739 with 1 screens 2016-01-11 18:07:42,383 schadenfreude.local (903x878 mm - DPI: 162x108) 2016-01-11 18:07:42,383 monitor 1 3784x1577 at 1982x2162 (592x370 mm - DPI: 162x108) 2016-01-11 18:07:42,383 monitor 2 5766x2162 (903x508 mm - DPI: 162x108) 2016-01-11 18:07:44,422 Warning: cannot scale by 0.333333333333 x 0.5 or lower 2016-01-11 18:07:44,422 the scaled client screen 2560 x 2490 -> 7679 x 4980 2016-01-11 18:07:44,423 would overflow the server's screen: 8192 x 4096 2016-01-11 18:07:44,423 using 0.60791015625 x 0.60791015625 -> 4211 x 4096 2016-01-11 18:07:44,423 setting scaling to 61%: 2016-01-11 18:07:44,423 sending updated screen size to server: 4211x4096 with 1 screens 2016-01-11 18:07:44,423 schadenfreude.local (903x878 mm - DPI: 118x118) 2016-01-11 18:07:44,423 monitor 1 2764x1727 at 1448x2369 (592x370 mm - DPI: 118x118) 2016-01-11 18:07:44,423 monitor 2 4211x2369 (903x508 mm - DPI: 118x118) 2016-01-11 18:07:46,415 setting scaling to 67%: 2016-01-11 18:07:46,415 sending updated screen size to server: 3844x3739 with 1 screens 2016-01-11 18:07:46,415 schadenfreude.local (903x878 mm - DPI: 108x108) 2016-01-11 18:07:46,415 monitor 1 2523x1577 at 1321x2162 (592x370 mm - DPI: 108x108) 2016-01-11 18:07:46,416 monitor 2 3844x2162 (903x508 mm - DPI: 108x108) 2016-01-11 18:07:47,479 setting scaling to 100%: 2016-01-11 18:07:47,479 sending updated screen size to server: 2560x2490 with 1 screens 2016-01-11 18:07:47,479 schadenfreude.local (903x878 mm - DPI: 72x72) 2016-01-11 18:07:47,479 monitor 1 1680x1050 at 880x1440 (592x370 mm - DPI: 72x72) 2016-01-11 18:07:47,480 monitor 2 2560x1440 (903x508 mm - DPI: 72x72) 2016-01-11 18:07:48,727 setting scaling to 125%: 2016-01-11 18:07:48,727 sending updated screen size to server: 2048x1992 with 1 screens 2016-01-11 18:07:48,727 schadenfreude.local (903x878 mm - DPI: 57x57) 2016-01-11 18:07:48,728 monitor 1 1344x840 at 704x1152 (592x370 mm - DPI: 57x57) 2016-01-11 18:07:48,728 monitor 2 2048x1152 (903x508 mm - DPI: 57x57)
Or, if that's just too ridiculous a set of user behaviors to support, then sure, let's close this.
One last detail, after trying these strange scaling maneuvers, when I disconnect the client I get some client-side warnings that might be of interest (unlikely, but I'll post anyway).
got signal SIGINT, exiting 2016-01-11 18:09:54,188 sound output stopping /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11640/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gl_window_backing_base.py:435: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed self.glconfig = None /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11640/Xpra.app/Contents/Resources/lib/python/xpra/client/gtk_base/gtk_client_window_base.py:995: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.Window.destroy(self) /Users/Schadenfreude/Desktop/xpra-catalog/xpra-ant-17-11640/Xpra.app/Contents/Resources/lib/python/xpra/gtk_common/gtk_util.py:365: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed gtk.main()
--desktop-scaling=180%
I'll backport the first two and if that works for you then I think we can finally close this ticket. If you can reproduce the third one then please file a new ticket and link it from here and #980.
Hmm, testing with osx client 0.17.0 r11653 against fedora 23 0.17.0 r11669, when I try to mix scalings (starting client with ./xpra attach tcp:10.0.32.134:1203 --opengl=on --desktop-scaling=1.8,110%
), the server doesn't seem to recognize the % value (2016-01-12 12:58:15,342 upscaled by 180% x 100%, virtual screen size: 1422x2490
). (Perhaps leading to client crash posted in #1087.)
Connecting a 0.17.0 r11653 windows client with mis-matching "units" had a similar result (--desktop-scaling=1.2,170%
led to upscaled by 120% x 100%
... and while scaling up and down worked as expected, using control-C to disconnect triggered an odd traceback (#1088).
Connecting with --desktop-scaling=120%,170%
... resulted in no scaling at all (well, 100% I suppose). Repeating with OSX client, but with desktop-scaling=180%,110%
, the display size output client side also indicates no scaling, but using that flag when shifting the session from that earlier indicated windows session to the osx, the xterm start-childs were incredibly oddly "squashed" — that is to say, the frames were essentially two columns high, while an expected width. (Probably just an odd coincidence, but perhaps helpful.)
Likewise, connecting with OSX client with ---desktop-scaling=180%
seems to display at 100%.
Connecting with desktop-scaling=1.2,1.7
though, works as expected, and the "relative" scaling is respected within reasonable limits and re-asserts as scaling shifts back into "middling" ranges.
Hehe, do we really need clients to be able to use percentages? (Ok, ok... we'll get that, then finally close this ticket.)
Good catch, the percentage parsing is fixed in r11671 (will backport). It was only working with multiples of 100... or python3!
Ok — tested with 0.17.0 r11687 osx and windows clients against 0.17.0 r11692 fedora 23 server.
Percentages work, decimals work, "relative" scaling works & is maintained as scaling is shortcut-adjusted up or down... mixing percentages and decimals works.
Then I remembered to try the shift-alt-asterisk
shortcut with scaling at something odd (129%x150%?; scaled down from initial 143%x166%) ... and noticed that it reset to a simple 100% scaling (rather than the "initial" setting)... and from there it scaled up as expected (125%, 150%, etc.).
I'm not sure if the asterisk short cut should go back to 100% or to the initial setting. I could see the virtues of leaving it as is for users to "turn off" scaling... or have it jump back to the initialized default. The "turn off" option has the distinct appeal of allowing us to close this ticket.
I'll hand this back to you yet again to decide.
Meta+Shift+question
@afarr: if that works for you then please close. (I'm not going to backport these)
r11718 fixes the scalingoff shortcut (missed commit on window class), beta win32 build uploaded.
Testing with win32 0.17.0 r11718 client against a 0.17.0 r11705 fedora 23 server... all those last fixes are working as expected.
Since I can't think of any other nitpicks, or find anything else - I'll close.
Follow up in #1101
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/976