xpra icon
Bug tracker and wiki

Custom Query (1903 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (10 - 12 of 1903)

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Ticket Resolution Summary Owner Reporter
#2135 wontfix Ambiguous / Erroneous logic on commandline flag "-desktop-scaling" thiner thiner
Description

xpra/client/scaling_parser.py

"The desktop−scaling value can take the form:

desktop−size the scaling will be enabled and the server will render to the given size. ie: 1600x1200 "

Basically I expect the "desktop-size" to work like: the pair I assign to it become the final xpra window size.

But there are at least two problems here:

  1. As for now r21542 it seems that the code contains an annoying bug on somewhere near line 108-109, where the integer division is done rather than a float division.

PoC: xpra attach :7 --desktop-scaling=10x10

There will be a line of log says something like:

2019-02-06 14:05:09,118 Warning: scaling values 0.0x0.0 are out of range

whereas --desktop-scaling=10.0x10.0 indicates otherwise.

I have no idea whether it is a feature but it follows a buggy pattern.

  1. Even without the float point number problem, The formula used in the source code is (width/root_width, height/root_height)

Consider that the X screen is 400x300 and my monitor is 1600x1200, to fit the X screen to my monitor I need to scale to 4x the original size, so width/1600 = 4, height/1200 = 4, yields that width=6400, height=4800, I will need to send 6400x4800 to make a 4x scaling, so that the final rendering window is 1600x1200.

I believe there is more likely a bug than a feature here...

#2129 fixed File Upload with Websocket connection causing unexpected data type <type 'memoryview'> Mark Harkin Mark Harkin
Description

Server: Centos7 r21499 proxy server Client: Windows 10 r21499 python client websocket connection

Uploading a file works fine with tcp connection but trying to upload using a websocket connection fails with server error:

2019-01-30 07:10:11,084 new proxy instance started
2019-01-30 07:10:11,084  for client ws websocket: 172.23.0.2:10000 <- 192.168.1.19:65091
2019-01-30 07:10:11,085  and server unix-domain socket:  <- /run/user/1000/xpra/890f20e343f1-0
2019-01-30 07:10:11,086 proxy instance now also available using unix domain socket:
2019-01-30 07:10:11,086  /run/user/1000/xpra/890f20e343f1-proxy-75
2019-01-30 07:10:54,966 Warning: unexpected data type <type 'memoryview'> in 'send-file-chunk' packet: <memory at 0x7f5978ed1510>
2019-01-30 07:10:54,966 failed to encode packet: ['send-file-chunk', '215a2a51217746fda5bbc72dcaef248b', 418, <memory at 0x7f5978ed1510>, True]
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/net/protocol.py", line 562, in encode
    main_packet, proto_flags = self._encoder(packet)
  File "/usr/lib/python2.7/site-packages/xpra/net/packet_encoding.py", line 89, in do_rencode
    return  rencode_dumps(data), FLAGS_RENCODE
  File "rencode/rencode.pyx", line 334, in rencode._rencode.dumps
  File "rencode/rencode.pyx", line 314, in rencode._rencode.encode
  File "rencode/rencode.pyx", line 247, in rencode._rencode.encode_list
  File "rencode/rencode.pyx", line 320, in rencode._rencode.encode
Exception: type <type 'memoryview'> not handled
2019-01-30 07:10:54,967 unsupported type: <type 'memoryview'> in 'send-file-chunk' packet->[3]
2019-01-30 07:10:54,967 Error: error in network packet write/format
2019-01-30 07:10:54,967  type <type 'memoryview'> not handled
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/net/protocol.py", line 356, in _write_format_thread_loop
    self._add_packet_to_queue(*gpc())
  File "/usr/lib/python2.7/site-packages/xpra/net/protocol.py", line 368, in _add_packet_to_queue
    chunks = self.encode(packet)
  File "/usr/lib/python2.7/site-packages/xpra/net/protocol.py", line 562, in encode
    main_packet, proto_flags = self._encoder(packet)
  File "/usr/lib/python2.7/site-packages/xpra/net/packet_encoding.py", line 89, in do_rencode
    return  rencode_dumps(data), FLAGS_RENCODE
  File "rencode/rencode.pyx", line 334, in rencode._rencode.dumps
  File "rencode/rencode.pyx", line 314, in rencode._rencode.encode
  File "rencode/rencode.pyx", line 247, in rencode._rencode.encode_list
  File "rencode/rencode.pyx", line 320, in rencode._rencode.encode
Exception: type <type 'memoryview'> not handled
2019-01-30 07:10:54,970 stopping proxy instance: server connection lost
2019-01-30 07:10:54,970 removing socket /run/user/1000/xpra/890f20e343f1-proxy-75
2019-01-30 07:10:54,971 waiting for network connections to close
2019-01-30 07:10:55,071 proxy instance 75 stopped

I feel this is similar to a previous fix r20229

Also, I'd like the client build to support websocket connections. However MINGW_BUILD.sh sets the client with --without-html5 but mimetools is required by the client to use websocket connections. Can I propose we change setup.py around line 373 from this:

if not html5_ENABLED:
    external_excludes += ["BaseHTTPServer", "mimetypes","mimetools"]

to this:

if not html5_ENABLED:
    external_excludes += ["BaseHTTPServer", "mimetypes"]
    if not client_ENABLED
        external_excludes += ["mimetools"]
#2128 invalid Flag --start-on-last-client-exit appears not to be working Antoine Martin stdedos
Description

Ubuntu 16.04.5 xpra v2.5-r21480 (py2?) / Win10 Xpra-Python3-x86_64_Setup_2.5-r21454

I have tried testing the usability of the --start-on-last-client-exit flag with a number of definitions:

"C:\Program Files\Xpra\xpra_cmd" shadow ssh://user@ip/0 --opengl=no --desktop-scaling=0.75

--start-on-last-client-exit="gnome-screensaver-command -l"
--start-on-last-client-exit="DISPLAY=:0 gnome-screensaver-command -l"
--start-on-last-client-exit="bash -c 'DBUS_SESSION_BUS_ADDRESS=$(cut -f 2- -d= /run/user/1000/dbus-session) gnome-screensaver-command -l'"
--start-on-last-client-exit="bash -c 'touch /tmp/xpra-test ; DBUS_SESSION_BUS_ADDRESS=$(cut -f 2- -d= /run/user/1000/dbus-session) gnome-screensaver-command -l'"
--start-on-last-client-exit="/tmp/lock-test.sh"

and with a variety of ways:

  • "Network timeout"
  • Disconnect server
  • Shutdown Server

All of which, appear not to be working - neither the naive:

$ ls -lah /tmp/xpra-test
ls: cannot access '/tmp/xpra-test': No such file or directory
$

nor the (original) locking of the screen.


There seem to be other interoperability issues between the client and the server: Connections that constantly need to be initiated twice (or more) before they are working, (major) leak of screens (cannot be reconnected, need to be killed manually) etc., so, I am not sure how to approach debugging.

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Note: See TracQuery for help on using queries.