xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Custom Query (2683 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (19 - 21 of 2683)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Ticket Resolution Summary Owner Reporter
#19 fixed client goes into infinite loop on ^C Antoine Martin Antoine Martin
Description

sometimes when I hit ctrl-c to the client it goes to infinite loop printing

 Traceback (most recent call last):
   File "v0.0.7.22-75-gb933db8/lib/python/xpra/protocol.py", line 67, in cb
     fn(*args, **kwargs)
   File "v0.0.7.22-75-gb933db8/lib/python/xpra/protocol.py", line 179, in _handle_read
     self._read_decoder.add(buf)
   File "v0.0.7.22-75-gb933db8/lib/python/xpra/bencode.py", line 34, in add
     assert self._result is None
 AssertionError

Looks like we need to more forcefully shutdown the client network receive queue.

#20 fixed client prints stuff forever after ^c Antoine Martin Antoine Martin
Description

This may be related to #19,

 Ignoring stray packet read after connection allegedly closed ([<object object at 0xb75114d0>, 'l4:drawi1ei2ei57ei1266ei886e5:rgb243365028:\x00\x00\x00\x00\x00\x00\x00'...])

Repeating forever. We should not be getting so much stuff on a closed connection!

#21 fixed jitter on link causes keys to repeat Antoine Martin Antoine Martin
Description

Solutions proposed:

  • doing the key repeat client-side - this does not seem to be a workable solution, it is likely to break applications which are currently working just fine
  • a better approach would be to require the client to confirm the key repeat within a certain amount of time: that way we can keep the key pressed on the server side, but we unpress it if we don't receive a "key-still-pressed" from the client in time. This allows us to maintain a consistent server-side state but we can also detect jitter on the line and take appropriate counter measures. (if we do eventually get the "key-still-pressed" packet after the timeout, we just press it again). The downside is that the line jitter will probably still cause keys to be pressed more than once (probably twice), just not dozens of times as it is now. Difficulty comes from the fact that the key-repeat delay is configurable and that it may well be shorter than the connection's transmit time when accounting for jitter.. And that we would need to communicate this delay to the client, and that those "key-still-pressed" messages waste precious bandwidth (although hardly more so than the pure client-side option)
  • letting the server increase the key repeat delay - we probably would need some kind of timing information with the packets so the server can have an idea of latency (this may be worth having in any case)
  • sending key events ahead of anything else (even mouse motion?) - this would not solve all cases, but work for cases where the high latency is caused by xpra packets
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Note: See TracQuery for help on using queries.