xpra-org / xpra Goto Github PK
View Code? Open in Web Editor NEWPersistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
Home Page: https://xpra.org/
License: GNU General Public License v2.0
Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
Home Page: https://xpra.org/
License: GNU General Public License v2.0
Issue migrated from trac ticket # 19
component: client | priority: major | resolution: fixed
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.
Issue migrated from trac ticket # 39
component: client | priority: major | resolution: invalid
Pressing "apply" when in the options window gave me this report.
winswitch 0.12.6-1, xpra 0.0.7.30+dfsg-1.
Issue migrated from trac ticket # 28
component: android | priority: major | resolution: wontfix
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:
Issue migrated from trac ticket # 44
component: server | priority: major | resolution: fixed
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)
Issue migrated from trac ticket # 14
component: client | priority: major | resolution: worksforme
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.
Issue migrated from trac ticket # 33
component: server | priority: major
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)
Issue migrated from trac ticket # 11
component: client | priority: major | resolution: duplicate
Some pointers which may be useful:
- windows-clipboard-viewer
- win32clipboard
- Build a Shared Clipboard Utility in Python
- MS Windows Clipboard (comp.lang.python)
Notes: it doesn't look like OSX supports events...
Carbon.Scrap.InfoScrap()
has a serial number, so maybe we can poll/compare that?
Issue migrated from trac ticket # 40
component: core | priority: major | resolution: fixed | keywords: xpra, error, X, no window
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.
Issue migrated from trac ticket # 8
component: server | priority: major | resolution: fixed
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.
Issue migrated from trac ticket # 45
component: android | priority: minor | resolution: duplicate
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
andPULSE_ID
Also, should the property name be using
latin1
?
Issue migrated from trac ticket # 47
component: client | priority: minor
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.
Issue migrated from trac ticket # 5
component: server | priority: minor | resolution: fixed | keywords: proxy
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.
Issue migrated from trac ticket # 37
component: platforms | priority: minor | resolution: fixed
Hello,
There's a typo (overriden instead of overridden) in xpra manpage, the attached patch fixes this typo
Issue migrated from trac ticket # 6
component: client | priority: major | resolution: worksforme
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)
Issue migrated from trac ticket # 22
component: server | priority: major | resolution: worksforme | keywords: dbus
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 ...)
Issue migrated from trac ticket # 15
component: client | priority: minor | resolution: fixed
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..
Issue migrated from trac ticket # 48
component: android | priority: major | resolution: fixed
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?
Issue migrated from trac ticket # 30
component: android | priority: major | resolution: fixed
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!
Issue migrated from trac ticket # 26
component: platforms | priority: minor | resolution: fixed
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 (returningNone
until implemented).
Issue migrated from trac ticket # 42
component: client | priority: minor | resolution: fixed | keywords: suggestion
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 :-)
Issue migrated from trac ticket # 3
component: server | priority: major | resolution: fixed
xpra has crashed a few times. It's always the same setting:
- I'm running gnome-terminal from a remote machine with xpra.
- 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
- 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.
Issue migrated from trac ticket # 20
component: client | priority: major | resolution: fixed
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!
Issue migrated from trac ticket # 24
component: client | priority: major | resolution: fixed
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.
Issue migrated from trac ticket # 49
component: android | priority: minor | resolution: fixed
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'sbuild_info.py
Issue migrated from trac ticket # 17
component: client | priority: major | resolution: wontfix
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.
Issue migrated from trac ticket # 12
component: core | priority: major | resolution: fixed
Need a way to detect which cursor is used (when changed) and ensure the client also changes the cursor.
Issue migrated from trac ticket # 46
component: server | priority: minor | resolution: fixed
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.
Issue migrated from trac ticket # 35
component: client | priority: major | resolution: fixed
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.
Issue migrated from trac ticket # 43
component: client | priority: major | resolution: fixed
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
Issue migrated from trac ticket # 18
component: client | priority: minor | resolution: fixed
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.
Issue migrated from trac ticket # 36
component: client | priority: minor | resolution: fixed
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.
Issue migrated from trac ticket # 9
component: client | priority: major | resolution: worksforme
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
Issue migrated from trac ticket # 7
component: client | priority: critical | resolution: fixed
Steps to reproduce:
0) Use finnish keyboard layout
- xpra start --no-daemon --start-child gnome-terminal --exit-with-children :7 -d all
- xpra attach ssh:lindi1:7
- hold altgr down
- hit <
- release altgr
Expected results:
5) gnome-terminal shows the pipe symbolActual results:
5) gnome-terminal shows some weird unicode character that resembles "i".More info:
I'm using
git-svn-id: http://xpra.devloop.org.uk/svn/Xpra/trunk@121 3bb7dfac-3a0b-4e04-842a-767bc560f471
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
Issue migrated from trac ticket # 29
component: android | priority: major | resolution: wontfix
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.
Issue migrated from trac ticket # 23
component: client | priority: critical | resolution: worksforme
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
inserver.py
(fromCompositeHelper
andBaseWindowModel.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.
Issue migrated from trac ticket # 13
component: client | priority: minor | resolution: fixed
- 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
Issue migrated from trac ticket # 2
component: client | priority: major | resolution: wontfix
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.
Issue migrated from trac ticket # 38
component: client | priority: major | resolution: fixed
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 lostAlso I noticed once that the window I am trying to attach appears momentarily then disappears and the error message appeared.
Issue migrated from trac ticket # 21
component: client | priority: major | resolution: fixed
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
Issue migrated from trac ticket # 1
component: client | priority: major | resolution: wontfix
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.
Issue migrated from trac ticket # 27
component: android | priority: minor | resolution: fixed
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.
Issue migrated from trac ticket # 31
component: android | priority: minor | resolution: fixed
in the settings pane, provide an option. depends on #27
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:
All the info should now be here: Xdummy]
Issue migrated from trac ticket # 16
component: client | priority: minor | resolution: fixed
Hyphen is used as minus sign in xpra manpage.
Issue migrated from trac ticket # 50
component: client | priority: minor | resolution: fixed
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.
Issue migrated from trac ticket # 4
component: client | priority: major | resolution: duplicate
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.
Issue migrated from trac ticket # 34
component: client | priority: critical | resolution: fixed
I'm using r259
Steps to reproduce:
- open gnome-terminal
- run "cat"
- press and hold ctrl
- 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:
- xev also shows that ctrl is released and pressed multiple times even though I never release the physical key.
Issue migrated from trac ticket # 25
component: server | priority: minor | resolution: fixed
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?
Issue migrated from trac ticket # 41
component: server | priority: minor | resolution: fixed | keywords: wishlist
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)
Issue migrated from trac ticket # 32
component: android | priority: minor | resolution: fixed
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"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.