xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.

1. About
2. Installation
3. Usage
4. Documentation
5. Help

About

Xpra is known as "screen for X" : its seamless mode allows you to run X11 programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine(s), without losing any state. Effectively giving you remote access to individual graphical applications. It can also be used to access existing desktop sessions and start remote desktop sessions.

Xpra is open-source (GPLv2+) with clients available for many supported platforms and the server includes a built-in HTML5 client. Xpra is usable over a wide variety of network protocols and does its best to adapt to any network conditions.

Xpra forwards and synchronizes many extra desktop features which allows remote applications to integrate transparently into the client's desktop environment: audio input and output, printers, clipboard, system trays, notifications, webcams, etc

It can also open documents and URLs remotely, display high bit depth content, and it will try honour the display's DPI.

Here's what a seamless session with two windows (an xterm and glxspheres) looks like when attached from an MS Windows 11 desktop client: (the windows may look like native windows, but they are running on a remote Linux server)

---

Installation

Official stable downloads

• Microsoft Windows: EXE, ZIP, MSI
• MacOS x86_64 DMG / PKG, arm64 DMG / PKG
• Linux: RPM, DEB

All the packages are signed. There are also beta builds available. For more information, see xpra downloads

Build from source

git clone https://github.com/Xpra-org/xpra; cd xpra
python3 ./setup.py install

For more details, see building from source. To contribute to the project, please try to use pull-requests and follow our code of conduct. Unit test status:

---

Usage

Initial requirements

xpra must be installed on the client and the host.

You can use the html5 client in which case xpra is only required on the host.

Seamless Mode

Run xterm on a remote host, display and iteract with it locally (from the client machine):

xpra start ssh://USER@HOST/ --start=xterm
# hint: xterm must be installed on the HOST.

For more examples, see usage.

Shadow

View an existing desktop session running on a remote host:

xpra shadow ssh://USER@HOST/

Network Access

Xpra servers can support many different types of connections using a single TCP port: SSL, SSH, (secure) http / websockets, RFB, etc..
Connections can be secured using encryption and many authentication modules.
Sessions can be automatically announced on LANs using multicast DNS so that clients can connect more easily using a GUI (ie: xpra mdns-gui).
Its flexible proxy server can be used as a relay or front end for multiple server sessions.

---

Documentation

There is extensive documentation right here for the current development version. This documentation is also included with each release.

For more generic version-agnostic information, checkout the wiki.

---

Help

Make sure to check the FAQ, your question may already be answered there. You can ask your questions on the github discussions, or on the IRC channel #xpra on libera.chat or using discord. If you have hit a bug (sorry about that!), please see reporting bugs.

xpra's Issues

xpra crashed while selecting text: The program 'xpra' received an X Window System error.

Issue migrated from trac ticket # 3

component: server | priority: major | resolution: fixed

2011-06-20 07:38:35: lindi created the issue

---

xpra has crashed a few times. It's always the same setting:

1. I'm running gnome-terminal from a remote machine with xpra.
2. From that gnome-terminal I run "ssh -Y yet-another-machine firefox" to run firefox from a remote machine that does not have xpra installed
3. I select some text in firefox

=> all xpra windows disappear.

The

Xvfb-for-Xpra-:7 +extension Composite -screen 0 3840x2560x24+32 -noreset -auth /home/lindi/.Xauthority :7

process and its clients seem to be alive but xpra is gone. I have to use "DISPLAY=:7 x11vnc & xvncviewer :0" to shut them down properly.

Full $HOME/.xpra/lindi1-7.log is attached. I'm running svn r67.

AttributeError: 'OverrideRedirectWindowModel' object has no attribute '_composite'

Issue migrated from trac ticket # 15

component: client | priority: minor | resolution: fixed

2011-09-06 19:42:54: lindi created the issue

---

Traceback (most recent call last):
   File "wimpiggy/window.py", line 265, in do_unmanaged
     self._composite.disconnect(self._damage_forward_handle)
 AttributeError: 'OverrideRedirectWindowModel' object has no attribute '_composite'

At first sight, this particular case could just be dropped with a flag since the window is about to be dropped: we can just mark it and avoid creating it, or destroy it when created, or something..

holding down Ctrl + N sometimes produces ^N and sometimes n

Issue migrated from trac ticket # 34

component: client | priority: critical | resolution: fixed

2011-10-28 17:21:29: lindi created the issue

---

I'm using r259

Steps to reproduce:

1. open gnome-terminal
2. run "cat"
3. press and hold ctrl
4. press and hold N

Expected results:
4) gnome-terminal is filled with

^N^N^N^N^N^N^N^N^N^N^N^N...

Actual results:
4) gnome-terminal has

^Nn^Nn^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^Nn^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N^N...

More info:

1. xev also shows that ctrl is released and pressed multiple times even though I never release the physical key.

avoid client error due to missing pulseaudio X11 props

Issue migrated from trac ticket # 45

component: android | priority: minor | resolution: duplicate

2011-11-23 22:35:47: totaam created the issue

---

Missing window or missing property or wrong property type PULSE_SERVER (latin1)
Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/wimpiggy/prop.py", line 277, in prop_get
     data = trap.call_synced(XGetWindowProperty, target, key, atom)
   File "/usr/lib/python2.7/dist-packages/wimpiggy/error.py", line 101, in call_synced
     return self._call(False, fun, args, kwargs)
   File "/usr/lib/python2.7/dist-packages/wimpiggy/error.py", line 86, in _call
     value = fun(*args, **kwargs)
   File "bindings.pyx", line 484, in wimpiggy.lowlevel.bindings.XGetWindowProperty (wimpiggy/lowlevel/bindings.c:4189)
 NoSuchProperty: PULSE_SERVER

and also for PULSE_COOKIE and PULSE_ID

Also, should the property name be using latin1?

client goes into infinite loop on ^C

Issue migrated from trac ticket # 19

component: client | priority: major | resolution: fixed

2011-09-07 09:10:42: antoine created the issue

---

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.

if an application changes the screen size on the server via randr - what do we do?

Issue migrated from trac ticket # 33

component: server | priority: major

2011-10-14 14:43:33: antoine created the issue

---

r220 added the ability to detect screen size changes on the client so the server can resize on demand.

We could quite easily implement similar code on the server to catch changes to the screen geometry (but not the ones we requested ourselves obviously). The question is: what do we do then?
Forcing the screen to change back is probably wrong - but then so is keeping a virtual screen with the wrong dimensions... maybe we can tell the user with the new notifications? Not sure what to do here!

As for the detection code, we can do this either with the same pygtk code (see r220) or with native X11 code:

cdef extern from "X11/extensions/randr.h":
    unsigned int RRScreenChangeNotifyMask

cdef extern from "X11/extensions/Xrandr.h":
    ctypedef CARD16 SubpixelOrder
    ctypedef struct XRRScreenChangeNotifyEvent:
        int type
        unsigned long serial
        Bool send_event
        Display *display
        Window window
        Window root
        Time timestamp
        Time config_timestamp
        SizeID size_index
        SubpixelOrder subpixel_order
        Rotation rotation
        int width
        int height
        int mwidth
        int mheight
 
    void XRRSelectInput(Display *dpy, Window window, int mask)

def selectXRREvents(pywindow, on):
    cdef Display * display
    cdef Window window
    display = get_xdisplay_for(gtk.gdk.display_get_default())
    window = get_xwindow(gtk.gdk.get_default_root_window())
    mask = RRScreenChangeNotifyMask
    XRRSelectInput(display, window, mask)

xpra window icons can be far too big

Issue migrated from trac ticket # 25

component: server | priority: minor | resolution: fixed

2011-09-20 10:53:32: antoine created the issue

---

During testing on android (and sending icons as png as per r176) I noticed that some window icons, sent as "icon" as part of the window metadata can be up to 256x256 in size.
Most of the time these are only used as a small icon in the window's title bar and in the task manager. Also, as far as I know there are no constraints on the size which will be accepted by the window manager.
Therefore, to try to minimize the use of bandwidth we should scale those down to a more reasonable size before sending, maybe 48x48?

Typo in xpra manpage

Issue migrated from trac ticket # 37

component: platforms | priority: minor | resolution: fixed

2011-11-01 20:36:00: aelmahmoudy created the issue

---

Hello,

There's a typo (overriden instead of overridden) in xpra manpage, the attached patch fixes this typo

right-click freezes window display

Issue migrated from trac ticket # 44

component: server | priority: major | resolution: fixed

2011-11-23 11:04:26: pmarek created the issue

---

I've got a xchat window; a right-click on a URL should popup a menu, but only gives an empty white rectangle, and the window is not refreshed anymore.

XPra=>refresh doesn't help; but clicking on the button location changes the title, and I can send my input to IRC.

using strace on the server gave me this: (sadly not in any logfile!) - please read with caution, might have garbled something.

{{{
29976 11:59:23.303694 send(22, "PS00000000000050l21:new-override-redirecti4ei826ei683ei338ei94edee", 66, 0) = 66
...
write(2," ....:"
Unhandled exception in thread started by
<bound method ServerSource.damage_to_data of <xpra.server.ServerSource object at 0xa75504c>>
Traceback (most recent call last):
File "/usr/lib/xpra/xpra/server.py", line 311, in damage_to_data
(_, _, ww, wh) = self._desktop_manager.window_geometry(window)
File "/usr/lib/xpra/xpra/server.py", line 85, in window_geometry
return self._models[model].geom\n"

KeyError
<OverrideRedirectWindowModel object at 0xa801a7c (wimpiggy+window+OverrideRedirectWindowModel at 0xa7d72d0)

xpra died

Issue migrated from trac ticket # 14

component: client | priority: major | resolution: worksforme

2011-09-02 01:06:54: FredSRichardson created the issue

---

I was working away in emacs over X when xpra died. The console messages looked like this:

_focus_change((<ClientWindow object at 0xa200b6c (xpra+client+ClientWindow at 0xa3018b8)>, <GParamBoolean 'has-toplevel-focus'>))
_focus_change((<ClientWindow object at 0xa200b6c (xpra+client+ClientWindow at 0xa3018b8)>, <GParamBoolean 'has-toplevel-focus'>))
_focus_change((<ClientWindow object at 0xa200b6c (xpra+client+ClientWindow at 0xa3018b8)>, <GParamBoolean 'has-toplevel-focus'>))
Connection lost
Error reading from connection: I/O operation on closed file

trying to reconnect gave me this message:

'setxkbmap -query' failed with exit code 255

the server will try to guess your keyboard mapping, which works reasonably well in most cases
however, upgrading 'setxkbmap' to a version that supports the '-query' parameter is preferred
Connection failed: [Errno 111] Connection refused
Connection lost
Error reading from connection: I/O operation on closed file

the tail end of the xpra log for this display looked like this:

['xkbcomp', '-', ':14'] successfully applied
['xmodmap', '-'] successfully applied
The program 'xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 4260582 error_code 3 request_code 12 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

so I suspect the real problem is the X error, but I don't understand what happened.

error in logging when ^C the client

Issue migrated from trac ticket # 18

component: client | priority: minor | resolution: fixed

2011-09-07 09:08:06: antoine created the issue

---

 Exception in thread Thread-2 (most likely raised during interpreter shutdown):
 Traceback (most recent call last):
   File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
   File "/usr/lib/python2.6/threading.py", line 484, in run
   File "v0.0.7.22-75-gb933db8/lib/python/xpra/protocol.py", line 144, in _read_thread_loop
   File "v0.0.7.22-75-gb933db8/lib/python/wimpiggy/log.py", line 43, in <lambda>
   File "v0.0.7.22-75-gb933db8/lib/python/wimpiggy/log.py", line 39, in log
   File "v0.0.7.22-75-gb933db8/lib/python/wimpiggy/log.py", line 30, in getLogger
   File "/usr/lib/python2.6/logging/__init__.py", line 1427, in getLogger
   File "/usr/lib/python2.6/logging/__init__.py", line 956, in getLogger
 <type 'exceptions.TypeError'>: 'NoneType' object is not callable

Please add more details when available.

Window does not properly refresh

Issue migrated from trac ticket # 35

component: client | priority: major | resolution: fixed

2011-10-28 19:35:06: ddoole created the issue

---

In recent builds, I've been having window refresh issues, particularly when using gvim. If I page up or page down, or search for a term that requires moving more than a page in the file, then sometimes the window doesn't redraw properly and the top part of the window is the new text and the bottom part of the window is whatever was displayed previously. The point in the window where the redraw stops is not consistent, although it's generally about mid-window.

Most of the time, using "refresh" from the system tray icon's menu will clear up the drawing problem.

I have observed this behaviour on both 0.0.7.28 and 0.0.7.29. I did not see the problem on 0.0.7.23.

My client is on Kubuntu 11.04 and my server is on Ubuntu 10.04.

Please let me know what diagnostics I can gather to help you narrow this down.

Cursor left and cursor down do not repeat

Issue migrated from trac ticket # 36

component: client | priority: minor | resolution: fixed

2011-10-28 20:13:59: ddoole created the issue

---

The cursor left and cursor down keys are not auto repeating for me. All other keys that I have tried (including cursor up and cursor right) do auto repeat.

I have seen this in 0.0.7.28 and 0.0.7.29.

Cursor left and down were repeating in 0.0.7.23.

xpra thinks the window is not visible, so maximizing and other things won't work

Issue migrated from trac ticket # 48

component: android | priority: major | resolution: fixed

2011-11-25 17:53:16: totaam created the issue

---

This bug was originally recorded as #35 and although the symptoms are somewhat similar, this particular issue manifests itself differently: no need for scrolling pages, simply maximizing the window sitting at the front is enough to show this in the server log:

resize_window to 1590x1019, desktop manager set it to 1590x1019, visible=False

Which is obviously wrong as the window IS visible.

This looks exactly like winswitch bug 163: "Maximizing does not work correctly".

Please record your local window manager and anything which may be relevant to this bug. Are you using ssh to connect to the server? Are you using ssh -X from the server to somewhere else? Can you reproduce it without? etc
Does this happen with vi or just any window?

client prints stuff forever after ^c

Issue migrated from trac ticket # 20

component: client | priority: major | resolution: fixed

2011-09-07 09:13:34: antoine created the issue

---

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!

support png encoding of pixel data as an alternative to jpeg and raw

Issue migrated from trac ticket # 27

component: android | priority: minor | resolution: fixed

2011-09-20 11:05:03: antoine created the issue

---

android currently uses jpeg because BitmapFactory cannot handle the raw pixel data sent by xpra.
We should add a --encoding=[jpeg|png|raw] option passed to the server via capabilities to allow us to encode pixel data as png.
As far as I can tell, this is the easiest way of getting non-lossy pixel data on android clients.

The code can simply use the same method as used for the window icon in r176
Then probably do #31 as it will be easy.

let the user decide whether to use pixel perfect (png) or lossy (jpeg)

Issue migrated from trac ticket # 31

component: android | priority: minor | resolution: fixed

2011-09-20 11:30:55: antoine created the issue

---

in the settings pane, provide an option. depends on #27

Patch to fix hyphenation in xpra manpage

Issue migrated from trac ticket # 16

component: client | priority: minor | resolution: fixed

2011-09-06 21:14:34: aelmahmoudy created the issue

---

Hyphen is used as minus sign in xpra manpage.

PULSE_ properties missing

Issue migrated from trac ticket # 46

component: server | priority: minor | resolution: fixed

2011-11-24 07:31:52: pmarek created the issue

---

I got these errors/warnings on the server side:

Missing window or missing property or wrong property type PULSE_SERVER (latin1)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/wimpiggy/prop.py", line 277, in prop_get
    data = trap.call_synced(XGetWindowProperty, target, key, atom)
  File "/usr/lib/python2.7/dist-packages/wimpiggy/error.py", line 101, in call_synced
    return self._call(False, fun, args, kwargs)
  File "/usr/lib/python2.7/dist-packages/wimpiggy/error.py", line 86, in _call
    value = fun(*args, **kwargs)
  File "bindings.pyx", line 484, in wimpiggy.lowlevel.bindings.XGetWindowProperty (wimpiggy/lowlevel/bindings.c:4189)
NoSuchProperty: PULSE_SERVER

and similar lines for PULSE_COOKIE and PULSE_ID.

Emacs Issues: xpra locks up, screen stops re-drawing

Issue migrated from trac ticket # 6

component: client | priority: major | resolution: worksforme

2011-08-04 02:28:53: FredSRichardson created the issue

---

I'm working with a recent version off the SVN repo (the date on the sources is 2011-08-02 19:36).

I've found two problems: one is occasional lockups and the other has to do with screen redrawing.

I'm not sure what causes the lockups, sometimes they are cured by minimizing and maximizing or by killing the xpra attach session and re-attaching.

The screen re-drawing is a consistent problem when scrolling through a lot of text. It looks as though emacs isn't keeping up with the redrawing somehow (a lot of "artifacts" are left in the buffer). This wasn't a problem in older versions of xpra, so I wonder if there's a setting that might help.

Here's output from the console:

$ xpra attach ssh:fdata1:14
'setxkbmap -query' failed with exit code 255
Missing window or missing property or wrong property type PULSE_SERVER (latin1)
Missing window or missing property or wrong property type PULSE_COOKIE (latin1)
Missing window or missing property or wrong property type PULSE_ID (latin1)
Attached (press Control-C to detach)
/usr/local/lib/python/xpra/xposix/xclipboard.py:227: GtkWarning: gdk_x11_atom_to_xatom_for_display: assertion `ATOM_TO_INDEX (atom) < virtual_atom_array->len' failed
  gtk.Invisible.do_selection_request_event(self, event)

support cursors

Issue migrated from trac ticket # 12

component: core | priority: major | resolution: fixed

2011-08-18 12:57:41: antoine created the issue

---

Need a way to detect which cursor is used (when changed) and ensure the client also changes the cursor.

suggestion: "xpra detach" command

Issue migrated from trac ticket # 42

component: client | priority: minor | resolution: fixed | keywords: suggestion

2011-11-15 15:28:14: Norman Rasmussen created the issue

---

ref: http://code.google.com/p/partiwm/issues/detail?id=40

Reported by Lalo Martins, Dec 2, 2010:

My pattern of using xpra is that I leave a session running permanently on my home server, then attach to it from my laptop when the laptop is on. When I want to detach, I usually do "ps xw | grep xpra" and then kill the ssh process. It would be nice if xpra itself had a "detach" command instead, to better mirror screen.

Thanks again for the great software and the help with the other issue :-)

context menus of applications are sometimes drawn outside visible area

Issue migrated from trac ticket # 1

component: client | priority: major | resolution: wontfix

2011-06-16 12:55:29: lindi created the issue

---

This is probably a known problem but I could not find a bug report about it.

If I right-click an URL in quassel IRC client I get a context menu. If the URL is on the last line of the window then the last entries of the context menu are drawn outside the visible area of the desktop :-)

I need to manually move the window and then right-click to be able to access the menu.

openoffice slideshow shows only a tiny upper left corner of the slides

Issue migrated from trac ticket # 2

component: client | priority: major | resolution: wontfix

2011-06-16 17:31:37: lindi created the issue

---

View->Slide Show in openoffice.org shows only a tiny upper left corner of my slides.

My guess is that openoffice.org is trying to render the slides to the huge 3840x2560 Xvfb framebuffer.

xpra 0.0.7.29 (and above) is not backwards compatible with 0.0.7.27 (and older)

Issue migrated from trac ticket # 38

component: client | priority: major | resolution: fixed

2011-11-05 12:11:56: aelmahmoudy created the issue

---

When I connect using xpra 0.0.7.29 (or later) to a machine that has xpra 0.0.7.27 (or older), I get the following error:

Attached (press Control-C to detach)
connection lost: empty marker in read queue
Connection lost

Also I noticed once that the window I am trying to attach appears momentarily then disappears and the error message appeared.

wishlist: Support multiple clients connected at the same time

Issue migrated from trac ticket # 41

component: server | priority: minor | resolution: fixed | keywords: wishlist

2011-11-15 15:26:04: Norman Rasmussen created the issue

---

aka: session shadowing?

ref: http://code.google.com/p/partiwm/issues/detail?id=42

It would be useful to support multiple clients connected at the same time. This could allow window sharing between multiple desktops (perhaps with sync'ed location? - so that synergy can 'move' windows between desktops)

forwarding system tray

Issue migrated from trac ticket # 22

component: server | priority: major | resolution: worksforme | keywords: dbus

2011-09-10 19:21:48: pmarek created the issue

---

For even more complete integration into the client session it would be nice to get the dbus socket forwarded, too.

I don't know much about dbus ... but IIRC this would mean that the registered applications would have to be stored, so that on re-connection the dbus login can be re-done.

It would be too much to hope for automatic dbus reconnect in each application, although it would surely be the cleanest way if libdbus just did all that.

Furthermore there could be a way to intercept "exec" calls ... there are quite a few programs that just call other programs, eg. when clicking a link a call to the firefox executable is made.
But if this application runs via xpra, but firefox is on the client, this fails - unless there's some easy way to forward these calls, too.

(Perhaps it would be enough to have a xpra option, like "xpra run-on-client " for this - either the call can be configured in the application, or a shell script in a well-chosen PATH could do the forward call.
There should be some mechanism for that in xpra, as the exec forwarding via ssh is not that easy to configure ...)

keyboard detection code should live in platform

Issue migrated from trac ticket # 26

component: platforms | priority: minor | resolution: fixed

2011-09-20 10:59:17: antoine created the issue

---

rather than exporting X11_KEYMAPS from the platform code:

from xpra.platform import X11_KEYMAPS

We should export a get_keymapping_data method from there which returns (xkbmap_print, xkbmap_query, xmodmap_data).
The existing code can then be moved to the posix implementation and we then have the possibility of doing something else for osx/win32 (returning None until implemented).

Couldn't kill "xpra attach" after emacs locked up

Issue migrated from trac ticket # 9

component: client | priority: major | resolution: worksforme

2011-08-18 02:27:40: FredSRichardson created the issue

---

I think some combination of keys causes this problem. Emacs wasn't responding, but the odd thing is that I couldn't kill the process with Ctrl-C!

This is what I got in the console:

^C^CShutting down main-loop
Traceback (most recent call last):
  File "/usr/local/lib/python/xpra/protocol.py", line 67, in cb
    fn(*args, **kwargs)
  File "/usr/local/lib/python/xpra/protocol.py", line 179, in _handle_read
    self._read_decoder.add(buf)
  File "/usr/local/lib/python/xpra/bencode.py", line 35, in add
    self._buf += bytes
KeyboardInterrupt
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])
Ignoring stray packet read after connection allegedly closed ([<object object at 0xb77f04d0>, 'l4:drawi1ei0ei65ei2540ei1360e5:rgb2410363200:geoge'...])

Here's what I saw at the end of the log:

xkbcomp successfully applied new keymap
Uh-oh, our size doesn't fit window sizing constraints!
Uh-oh, our size doesn't fit window sizing constraints!
Uh-oh, our size doesn't fit window sizing constraints!
Error parsing property WM_TRANSIENT_FOR (type window); this may be a
  misbehaving application, or bug in Wimpiggy
  Data: '\x01\x00\x00\x00'[...?]
Error parsing property WM_TRANSIENT_FOR (type window); this may be a
  misbehaving application, or bug in Wimpiggy
  Data: '\x01\x00\x00\x00'[...?]
Error reading from connection: [Errno 104] Connection reset by peer
Error writing to connection: [Errno 32] Broken pipe
Connection lost
xpra client disconnected.
New connection received
Connection lost

allow a chain of SSH hosts

Issue migrated from trac ticket # 17

component: client | priority: major | resolution: wontfix

2011-09-07 06:59:48: antoine created the issue

---

Received this patch from Philip Marek.

This can be applied once tested, and since I have no need for it, no rush to test it. Feel free to test and provide a +1 and I'll apply it.

android client does not pass key events at all!

Issue migrated from trac ticket # 29

component: android | priority: major | resolution: wontfix

2011-09-20 11:19:47: antoine created the issue

---

This is actually quite tricky.
The drag layer intercepts a lot of events, so we first have to let them pass through, then the xpra window (an android view) will have to catch those and translate them into something the server can deal with.

Then there is also the issue of popping up the android on-screen keyboard: the view is not an input element so the keyboard is never shown at present.. not sure how that's done either. We probably want to have it shown only if the meny key is pressed as it uses a lot of screen space.

large windows on android will cause out-of-memory problems

Issue migrated from trac ticket # 28

component: android | priority: major | resolution: wontfix

2011-09-20 11:14:14: antoine created the issue

---

There are a number of things we can do here, some easier than others.

• do not request window damage data for off-screen regions. We can then make the local window buffer no bigger than the android device screen which should allow us many windows before we hit the oom.
• scale windows down. this may also be a nice feature associated with pinch to zoom in/out
• combining the two features above is probably quite hard

Useful link:

• Android: Strange out of memory issue

modifiers key get stuck (alt key generally)

Issue migrated from trac ticket # 13

component: client | priority: minor | resolution: fixed

2011-08-18 13:36:23: antoine created the issue

---

• Improve guessing/detection: code had already been improved, we probably could do better rather than just trying keys until we find one!
• assuming we have to keep guessing, at least cache the results

network read loop is highly inefficient

Issue migrated from trac ticket # 24

component: client | priority: major | resolution: fixed

2011-09-19 09:45:52: antoine created the issue

---

Whenever we read a bit of data from the socket (sometimes as small as just one character!) we schedule the main loop to call _handle_read. When it actually fires there may only be (sometimes less than) one real packet waiting there, yet it will fire as many times as the socket read loop originally fired.
We want to ensure we don't schedule it again if it is already pending, this should save a lot of context switches and reduce load significantly. Using an atomic loop counter should probably be enough to achieve this.

corrupted double-linked list

Issue migrated from trac ticket # 39

component: client | priority: major | resolution: invalid

2011-11-09 13:21:05: pmarek created the issue

---

Pressing "apply" when in the options window gave me this report.

winswitch 0.12.6-1, xpra 0.0.7.30+dfsg-1.

windows stay visible on the screen even if the server is killed

Issue migrated from trac ticket # 4

component: client | priority: major | resolution: duplicate

2011-07-05 08:57:19: lindi created the issue

---

Currently if the server is killed the _to_server thread exits and
closes both _client_conn and _server_conn. However, this does not
cause the _to_client thread to stop. As a result an extra "xpra"
process stays listed in the process list and users don't notice that
the server has died. Only if you try to interactive with any of the
windows will the proxy write something to the server socket and notice
the problem.

This patch stops _to_client thread when _to_server thread exits and
vice versa. Calling _Thread_stop() is bit ugly but the alternative
would probably be to use some sort of polling mechanism instead of
blocking read() in _copy_loop.

Xpra errors running Handbrake

Issue migrated from trac ticket # 40

component: core | priority: major | resolution: fixed | keywords: xpra, error, X, no window

2011-11-14 03:51:56: olmari created the issue

---

So, I try to run Handbrake (trunk version) with Xpra, but I get plenty Python errors in console, also no window shows... I know Last stable Handbrake 0.9.5 worked with xpra 0.0.6, but trunk doesn't work with either 0.0.6 "upstream", nor with 0.0.7.30... There is no stable available for Ubuntu Oneiric Ocelot...

I do get this error with client side of xpra:

Unhandled error while processing packet from peer
Traceback (most recent call last):
  File "/usr/lib/xpra/xpra/protocol.py", line 272, in _process_packet
    self._process_packet_cb(self, decoded)
  File "/usr/lib/xpra/xpra/client.py", line 860, in process_packet
    self._packet_handlers[packet_type](self, packet)
  File "/usr/lib/xpra/xpra/client.py", line 742, in _process_new_window
    self._process_new_common(packet, False)
  File "/usr/lib/xpra/xpra/client.py", line 736, in _process_new_common
    override_redirect)
  File "/usr/lib/xpra/xpra/client.py", line 83, in __init__
    self.update_metadata(metadata)
  File "/usr/lib/xpra/xpra/client.py", line 130, in update_metadata
    self.set_geometry_hints(None, **hints)
OverflowError: Python int too large to convert to C long

No matter do I connect by TCP or SSH. At server side log I see this:

Traceback (most recent call last):
  File "/usr/bin/xpra", line 7, in <module>
    xpra.scripts.main.main(__file__, sys.argv)
  File "/usr/lib/xpra/xpra/scripts/main.py", line 82, in main
    run_server(parser, options, mode, script_file, args)
  File "/usr/lib/xpra/xpra/scripts/server.py", line 258, in run_server
    wait_for_x_server(display_name, 3) # 3s timeout
  File "xpra.wait_for_x_server.pyx", line 33, in xpra.wait_for_x_server.wait_for_x_server
RuntimeError: could not connect to X server after 3 seconds

Without Xpra it works... I mean running Handbrake in ssh -X -session it works normally.

fast refresh (ie: fast scrolling) causes high cpu usage and no screen updates

Issue migrated from trac ticket # 23

component: client | priority: critical | resolution: worksforme

2011-09-14 11:33:47: antoine created the issue

---

Not sure why the screen does not update (I don't get that behaviour here), but in any case we need to deal with fast updates better.

Maybe we can detect when a window is causing bursts of damage requests and buffer them for a bit, by the time we get around to processing them we may be able to remove many duplicates for the same region, or if the total surface of the damage requests is close to the full window size then just do one full refresh instead.

The damage requests from the server end come via _contents_changed in server.py (from CompositeHelper and BaseWindowModel.setup()).
Currently this fires _protocol.source_has_more() which will write the packet if the write queue is empty.
Could it be that very large packets make the write queue appear empty (it is) when in fact there is still a large chunk of data still to be sent in _write_thread_loop?
Or do the packets go out faster than client can deal with?

More testing needed. Ideas and suggestions welcome.

a trick for transferring keyboard modifiers to xpra server

Issue migrated from trac ticket # 50

component: client | priority: minor | resolution: fixed

2011-11-28 08:30:50: Heroxbd created the issue

---

at present xpra client only transfers the output of "xmodmap -pke" to xpra server. this is enough for simple cases.

However if xmodmap_data contains modifications of keyboard modifiers like Shift_L Control_R, xmodmap in xpra server usually screws up.

We'd better clear the relavent modifiers and readd them after applying keymap table from "xmodmap -pke".

Unfortunately xmodmap do not have a "-pme" feature. I came up with a quick hack by make a wrapper of xmodmap to print "clear" and "add" clauses around keymap table.

keep hidden/minimized windows' pixels around so we don't need a roundtrip to the server to show them

Issue migrated from trac ticket # 47

component: client | priority: minor

2011-11-24 09:43:40: pmarek created the issue

---

The latency for xpra windows is much higher than for local windows; so, when switching the desktop, I can see the screen, and after some time (~0.3 secs for single SSH connection) the xpra windows refreshes.

Perhaps there might be an option to request auto-refresh - from every 1 second to every hour, or something like that.

typing the pipe symbol on finnish keyboard produces wrong character

Issue migrated from trac ticket # 7

component: client | priority: critical | resolution: fixed

2011-08-04 10:22:47: lindi created the issue

---

Steps to reproduce:
0) Use finnish keyboard layout

1. xpra start --no-daemon --start-child gnome-terminal --exit-with-children :7 -d all
2. xpra attach ssh:lindi1:7
3. hold altgr down
4. hit <
5. release altgr

Expected results:
5) gnome-terminal shows the pipe symbol

Actual results:
5) gnome-terminal shows some weird unicode character that resembles "i".

More info:

1. I'm using

   git-svn-id: http://xpra.devloop.org.uk/svn/Xpra/trunk@121 3bb7dfac-3a0b-4e04-842a-767bc560f471

2. relevant xpra debug output:

read thread: got data '"*E\x83\xfb\xab\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"*E\x83\xfb\xab\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'ISO_Level3_Shift', 1, []]
now 1pressing keycode=108, keyname=ISO_Level3_Shift
main thread: processed all read data

read thread: got data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'bar', 1, []]
now 1pressing keycode=31, keyname=bar
main thread: processed all read data
DamageNotify received
  event was delivered to window itself
  not forwarding to WindowModel handler, it has no wimpiggy-damage-event signal
  forwarding event to a CompositeHelper handler's wimpiggy-damage-event signal
damage 1 (88, 170, 20, 20)
writing ['draw', 1, 88, 170, 20, 20, 'rgb24', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...]
write thread: waiting for data to write
  forwarded
write thread: writing 'B.\xd7,F\xcb5"\x02r\xa0\xd2\x01\x91\xf6b\x1d\x8f$R/\xd6q\xbbQ\xbdX\xcbD\xb4`\x81\x07\x1d\xd6\xe0""Y\x8d\xb8\xba\x87\x980![M*\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x1b08310>>
write thread: waiting for data to write
read thread: got data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'bar', 0, []]
now 0pressing keycode=31, keyname=bar
main thread: processed all read data

read thread: got data '"\xca\x06\xb0[\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"\xca\x06\xb0[\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'ISO_Level3_Shift', 0, []]
now 0pressing keycode=108, keyname=ISO_Level3_Shift
main thread: processed all read data

Xpra sun.awt.X11.XlibWrapper.XGetAtomName issue

Issue migrated from trac ticket # 8

component: server | priority: major | resolution: fixed

2011-08-10 15:32:11: nicolyon created the issue

---

When trying to run http://www.mucommander.com/ on xpra i got an error about the atom name but on local X i don't have this.

I Try with the svn version of xpra.

jitter on link causes keys to repeat

Issue migrated from trac ticket # 21

component: client | priority: major | resolution: fixed

2011-09-08 10:27:38: antoine created the issue

---

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

system bell support for android, win32 and osx

Issue migrated from trac ticket # 32

component: android | priority: minor | resolution: fixed

2011-09-27 14:32:26: antoine created the issue

---

This has to be done using native code, r196 already added support for posix systems (Linux etc).

Pointers:

• win32: win32api Beep or winsound
• android: probably just use vibrate?
• osx: Python Sound "Bell"

show version information in about dialog

Issue migrated from trac ticket # 49

component: android | priority: minor | resolution: fixed

2011-11-25 19:47:06: totaam created the issue

---

Would be quite useful, could also show the remote (server) version too.

This would to be placed in a separate file, modified during do-build in a similar way to winswitch's build_info.py

clipboard support for OSX and win32

Issue migrated from trac ticket # 11

component: client | priority: major | resolution: duplicate

2011-08-18 12:42:58: antoine created the issue

---

Some pointers which may be useful:

• windows-clipboard-viewer
• win32clipboard
• Build a Shared Clipboard Utility in Python
• MS Windows Clipboard (comp.lang.python)

• manipulate-mac-os-clipboard (python)

• OSX NSPasteBoard
• Pasteboard Manager
• Copying and pasting in Python on Mac OS X

Notes: it doesn't look like OSX supports events... Carbon.Scrap.InfoScrap() has a serial number, so maybe we can poll/compare that?

windows stay visible on the screen even if the server is killed

Issue migrated from trac ticket # 5

component: server | priority: minor | resolution: fixed | keywords: proxy

2011-07-05 08:57:43: lindi created the issue

---

Currently if the server is killed the _to_server thread exits and
closes both _client_conn and _server_conn. However, this does not
cause the _to_client thread to stop. As a result an extra "xpra"
process stays listed in the process list and users don't notice that
the server has died. Only if you try to interactive with any of the
windows will the proxy write something to the server socket and notice
the problem.

This patch stops _to_client thread when _to_server thread exits and
vice versa. Calling _Thread_stop() is bit ugly but the alternative
would probably be to use some sort of polling mechanism instead of
blocking read() in _copy_loop.

android window dimensions and inner dimensions

Issue migrated from trac ticket # 30

component: android | priority: major | resolution: fixed

2011-09-20 11:22:11: antoine created the issue

---

The current implementation is just a hack with ugly (and hard-coded!) offsets for the window frame we draw ourselves.
This needs to be replaced with something that actually works properly!

Xdummy standalone and packaging

There are a number of issues that can only be solved by having a proper supported Xvfb server with modern extension support (randr, etc), ie: #1, #2 (and potentially others - original winswitch ticket)

Although this is not strictly an Xpra thing, and is unlikely to live in the this xpra source repository, it is best to record this somewhere.
There are number of tasks:

• create an xorg project based on xorg-server, but with the ability to specify absolute config paths and dummy defaults
• merge it upstream and/or package it
• add code to xpra so it will use randr to resize the virtual framebuffer to the exact screen dimension of the client (currently resizes to the nearest size bigger than the client's)

All the info should now be here: Xdummy]

tray icon and menu icons are blank

Issue migrated from trac ticket # 43

component: client | priority: major | resolution: fixed

2011-11-15 16:45:35: Norman Rasmussen created the issue

---

Using: Ubuntu 10.04 Lucid

Even though it the logs show the icon_file is detected, the icon does not show in my tray notification area. There's a smallish (10px) blank space which I can click to get the menu.

None of the menu items have icons either, some have a no-entry style icon, which I think means bad image, or similar.

I'm happy to help debug, but I'm not sure where to start.

Log:

$ xpra attach -d all |& head -n 20
parse_shortcuts(['meta+shift+F4:quit'])
parse_shortcuts(['meta+shift+F4:quit'])={'F4': (['meta', 'shift'], 'quit')}
get_icon_filename(xpra.png)=/usr/share/xpra/icons/xpra.png, exists=True
set default window icon to /usr/share/xpra/icons/xpra.png
get_icon_filename(information.png)=/usr/share/xpra/icons/information.png, exists=True
get_icon_filename(configure.png)=/usr/share/xpra/icons/configure.png, exists=False
get_icon_filename(slider.png)=/usr/share/xpra/icons/slider.png, exists=True
get_icon_filename(keyboard.png)=/usr/share/xpra/icons/keyboard.png, exists=True
get_icon_filename(retry.png)=/usr/share/xpra/icons/retry.png, exists=True
get_icon_filename(quit.png)=/usr/share/xpra/icons/quit.png, exists=True
get_icon_filename(close.png)=/usr/share/xpra/icons/close.png, exists=True
get_tray_icon_filename using default: /usr/share/xpra/icons/xpra.png
write thread: waiting for data to write
read thread: waiting for data to arrive
'setxkbmap -query' failed with exit code 255