From varvello at yahoo.com Sat Sep 1 11:06:23 2012 From: varvello at yahoo.com (Davide Varvello) Date: Sat, 1 Sep 2012 03:06:23 -0700 (PDT) Subject: [winswitch] Multiple xpra sessions on the same machine Message-ID: <1346493983.56898.YahooMailNeo@web160101.mail.bf1.yahoo.com> Hi there, ?I've a couple of xpra sessions on the same machine: one started on 100 and other started on 101. Every time I'm going to connect the machine via window-switch, I can only see the session on 100. How can I attach to display number 101? ? Cheers ?Davide From antoine at nagafix.co.uk Sat Sep 1 11:21:19 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 01 Sep 2012 17:21:19 +0700 Subject: [winswitch] Multiple xpra sessions on the same machine In-Reply-To: <1346493983.56898.YahooMailNeo@web160101.mail.bf1.yahoo.com> References: <1346493983.56898.YahooMailNeo@web160101.mail.bf1.yahoo.com> Message-ID: <5041E19F.2050903@nagafix.co.uk> On 09/01/2012 05:06 PM, Davide Varvello wrote: > Hi there, > I've a couple of xpra sessions on the same machine: one started on 100 and other started on 101. How did you start those sessions? Which versions do you have installed on each machine? How do you run them? etc.. > Every time I'm going to connect the machine via window-switch, > I can only see the session on 100. How can I attach to display number 101? You may want to stop the winswitch server (which may be running embedded in the applet on the 'server' machine, or the standalone winswitch_server command - I don't know enough about your setup), then try clearing the corresponding session directory: ~/.winswitch/server/sessions/101 Then it should re-detect it on restart (as long as you have: capture_external_sessions=True in your .winswitch/server/protocols/xpra.conf) Note: by doing this, you will lose the session name and other bits of information about this session. The other (better) option is to investigate why this session is hidden from view by looking at the session config file, log file, winswitch log file etc. Cheers Antoine > > Cheers > Davide > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Wed Sep 5 11:12:50 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 05 Sep 2012 17:12:50 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.3.8 EOL / 0.4.5 EOL / 0.5.3 - and 0.6.0 beta2 Message-ID: <504725A2.4000808@nagafix.co.uk> Hi, This update to the stable branches only fixes a single bug, but this is a fairly important one for compatibility with other versions. Unless anything major shows up, this is likely to be the last update to the 0.3.x and 0.4.x branches. All users are encouraged to upgrade to 0.5.x now. The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine From rdtennent at gmail.com Wed Sep 5 16:24:29 2012 From: rdtennent at gmail.com (Bob Tennent) Date: Wed, 05 Sep 2012 11:24:29 -0400 Subject: [winswitch] XPRA_SOCKET_DIR=~/.xpra: Command not found Message-ID: <50476ead.XnyBW7qgDcQ8C8eR%rdtennent@gmail.com> I'm trying to upgrade from xpra-0.3.2 to xpra-0.5.3 on Centos-6.3. When I do xpra --ssh="ssh -p2202" attach ssh:remotehost:100 (which worked before) I get XPRA_SOCKET_DIR=~/.xpra: Command not found. 2012-09-05 11:15:10,957 Connection lost Why? This is the output from xpra info on the remote system: Xlib: extension "RANDR" missing on display ":100.0". build_bit=32bit build_cpu=i686 build_date=2012-09-05 built_by=buildbot built_on=winswitch.org clients=0 clipboard=1 encodings=png,jpeg,rgb24,x264,vpx gtk_version=[2, 18, 9] local_modifications=0 max_desktop_size=[3840, 2560] password_file= platform=linux2 potential_clients=0 pulseaudio=1 pygtk_version=[2, 16, 0] python_version=[2, 6, 6] randr=0 revision=1481 root_window_size=[3840, 2560] session_name= start_time=1346858008 version=0.5.3 windows=0 Connection lost From antoine at nagafix.co.uk Thu Sep 6 06:02:51 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 06 Sep 2012 12:02:51 +0700 Subject: [winswitch] XPRA_SOCKET_DIR=~/.xpra: Command not found In-Reply-To: <50476ead.XnyBW7qgDcQ8C8eR%rdtennent@gmail.com> References: <50476ead.XnyBW7qgDcQ8C8eR%rdtennent@gmail.com> Message-ID: <50482E7B.1010807@nagafix.co.uk> On 09/05/2012 10:24 PM, Bob Tennent wrote: > I'm trying to upgrade from xpra-0.3.2 to xpra-0.5.3 on Centos-6.3. When > I do > > xpra --ssh="ssh -p2202" attach ssh:remotehost:100 > > (which worked before) I get > > XPRA_SOCKET_DIR=~/.xpra: Command not found. > 2012-09-05 11:15:10,957 Connection lost > > Why? I've just tried it with the same versions and I cannot reproduce your problem. I can connect just fine via ssh, before and after upgrading the server session to 0.5.3. You may be able to workaround the issue by using: xpra --socket-dir="" --ssh="ssh -p2202" attach ssh:remotehost:100 (but sine I do not understand the problem.. this is just a wild guess) Why does your system try to run the environment variable as if it was a command.. This is what xpra should execute in your case: ssh -p 2202 -T $rhost XPRA_SOCKET_DIR=~/.xpra .xpra/run-xpra _proxy :100 Can you try running this by hand? It won't work as an xpra client, but do you get the same error message from ssh? Here's something a little easier to understand that you can try: ssh -T $YOURHOST XYZ=1 "env | grep XYZ" You should see: "XYZ=1" And if you use an invalid command, it does print that command's name and not the environment setting: ssh -T $YOURHOST XYZ=1 invalid_foo bash: invalid_foo: command not found The only other option for debugging your problem is to post: xpra -d all attach (...) Please also post your /etc/xpra/xpra.conf (and ~/.xpra/xpra.conf if you have created one) Hope this helps! Cheers Antoine > This is the output from xpra info on the remote system: > > Xlib: extension "RANDR" missing on display ":100.0". > build_bit=32bit > build_cpu=i686 > build_date=2012-09-05 > built_by=buildbot > built_on=winswitch.org > clients=0 > clipboard=1 > encodings=png,jpeg,rgb24,x264,vpx > gtk_version=[2, 18, 9] > local_modifications=0 > max_desktop_size=[3840, 2560] > password_file= > platform=linux2 > potential_clients=0 > pulseaudio=1 > pygtk_version=[2, 16, 0] > python_version=[2, 6, 6] > randr=0 > revision=1481 > root_window_size=[3840, 2560] > session_name= > start_time=1346858008 > version=0.5.3 > windows=0 > Connection lost > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Thu Sep 6 08:01:09 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 06 Sep 2012 14:01:09 +0700 Subject: [winswitch] XPRA_SOCKET_DIR=~/.xpra: Command not found In-Reply-To: <50482E7B.1010807@nagafix.co.uk> References: <50476ead.XnyBW7qgDcQ8C8eR%rdtennent@gmail.com> <50482E7B.1010807@nagafix.co.uk> Message-ID: <50484A35.9060409@nagafix.co.uk> On 09/06/2012 12:02 PM, Antoine Martin wrote: > On 09/05/2012 10:24 PM, Bob Tennent wrote: >> I'm trying to upgrade from xpra-0.3.2 to xpra-0.5.3 on Centos-6.3. When >> I do >> >> xpra --ssh="ssh -p2202" attach ssh:remotehost:100 >> >> (which worked before) I get >> >> XPRA_SOCKET_DIR=~/.xpra: Command not found. >> 2012-09-05 11:15:10,957 Connection lost >> >> Why? (snip) Found a better explanation and a potential fix. Are you using a non-bash login shell with that user by any chance? I get the same error when I switch to tcsh for example. The simple fix is here: https://www.xpra.org/trac/changeset/1489 Can you try this beta package and see if the problem goes away: https://www.xpra.org/beta/CentOS/6.3/i386/xpra-0.6.0-1.el6.i386.rpm (if so, I'll update 0.5 asap) Cheers Antoine > > The only other option for debugging your problem is to post: > xpra -d all attach (...) > Please also post your /etc/xpra/xpra.conf (and ~/.xpra/xpra.conf if you > have created one) > > Hope this helps! > > Cheers > Antoine > > > >> This is the output from xpra info on the remote system: >> >> Xlib: extension "RANDR" missing on display ":100.0". >> build_bit=32bit >> build_cpu=i686 >> build_date=2012-09-05 >> built_by=buildbot >> built_on=winswitch.org >> clients=0 >> clipboard=1 >> encodings=png,jpeg,rgb24,x264,vpx >> gtk_version=[2, 18, 9] >> local_modifications=0 >> max_desktop_size=[3840, 2560] >> password_file= >> platform=linux2 >> potential_clients=0 >> pulseaudio=1 >> pygtk_version=[2, 16, 0] >> python_version=[2, 6, 6] >> randr=0 >> revision=1481 >> root_window_size=[3840, 2560] >> session_name= >> start_time=1346858008 >> version=0.5.3 >> windows=0 >> Connection lost >> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From rdtennent at gmail.com Thu Sep 6 12:46:28 2012 From: rdtennent at gmail.com (Bob Tennent) Date: Thu, 06 Sep 2012 07:46:28 -0400 Subject: [winswitch] XPRA_SOCKET_DIR=~/.xpra: Command not found Message-ID: <50488d14.Rfn0ueUvgaE6LzZD%rdtennent@gmail.com> >|On 09/06/2012 12:02 PM, Antoine Martin wrote: >|> On 09/05/2012 10:24 PM, Bob Tennent wrote: >|>> I'm trying to upgrade from xpra-0.3.2 to xpra-0.5.3 on Centos-6.3. When >|>> I do >|>> >|>> xpra --ssh="ssh -p2202" attach ssh:remotehost:100 >|>> >|>> (which worked before) I get >|>> >|>> XPRA_SOCKET_DIR=~/.xpra: Command not found. >|>> 2012-09-05 11:15:10,957 Connection lost >|>> >|>> Why? >|(snip) >|Found a better explanation and a potential fix. >|Are you using a non-bash login shell with that user by any chance? Yes: tcsh. >|The simple fix is here: >|https://www.xpra.org/trac/changeset/1489 >|Can you try this beta package and see if the problem goes away: >|https://www.xpra.org/beta/CentOS/6.3/i386/xpra-0.6.0-1.el6.i386.rpm That problem goes away but there seem to be new (unrelated?) problems. When I start on xterm on the remote server, the client crashes: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/xpra/client_window.py", line 210, in do_realize if self.is_toplevel(): AttributeError: 'ClientWindow' object has no attribute 'is_toplevel' Segmentation fault I tried to build a patched xpra-5.3.3 using the src.rpm but get ERROR: cannot find a valid pkg-config package for ['libswscale'] (even before patching). Bob T. From antoine at nagafix.co.uk Thu Sep 6 17:00:45 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 06 Sep 2012 23:00:45 +0700 Subject: [winswitch] object has no attribute 'is_toplevel' (was XPRA_SOCKET_DIR=..) In-Reply-To: <5048A351.6060901@nagafix.co.uk> References: <50476ead.XnyBW7qgDcQ8C8eR%rdtennent@gmail.com> <50482E7B.1010807@nagafix.co.uk> <50484A35.9060409@nagafix.co.uk> <50488c24.H0dLRjokEWIdj81m%rdt@cs.queensu.ca> <5048A351.6060901@nagafix.co.uk> Message-ID: <5048C8AD.5000406@nagafix.co.uk> >> Traceback (most recent call last): >> File "/usr/lib/python2.6/site-packages/xpra/client_window.py", line >> 210, in do_realize >> if self.is_toplevel(): >> AttributeError: 'ClientWindow' object has no attribute 'is_toplevel' Fix for old versions of PyGTK: https://www.xpra.org/trac/changeset/1498 New beta package with latest fix: https://www.xpra.org/beta/CentOS/6.3/i386/xpra-0.6.0-3.el6.i386.rpm Tested OK on CentOS 6.3 x86. Cheers Antoine From rdtennent at gmail.com Thu Sep 6 22:10:14 2012 From: rdtennent at gmail.com (Bob Tennent) Date: Thu, 06 Sep 2012 17:10:14 -0400 Subject: [winswitch] misaligned pointer Message-ID: <50491136.V0lyToy+Tt5KODTc%rdtennent@gmail.com> One issue I see with xpra-0.6.0-3 on Centos6.3 is that the window "pointer" is about 60 pixels above the point it's really pointing at. This is most evident when going down a menu and the highlighted entry is the one *below* the pointer. This is for a remote server. I don't think I'd had this with an earlier version but perhaps I never noticed it. Bob T. From antoine at nagafix.co.uk Fri Sep 7 10:04:41 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 07 Sep 2012 16:04:41 +0700 Subject: [winswitch] misaligned pointer In-Reply-To: <50491136.V0lyToy+Tt5KODTc%rdtennent@gmail.com> References: <50491136.V0lyToy+Tt5KODTc%rdtennent@gmail.com> Message-ID: <5049B8A9.5000606@nagafix.co.uk> Most of the recent bugs reported recently, by you and others, were due to some new code which tried to preserve the workspace that the window is shown on when resume. (it should be simple to do, but it is not) I have turned this feature off until I can make it work reliably: https://www.xpra.org/trac/changeset/1504 The updated package is here: https://www.xpra.org/beta/CentOS/6.3/i386/xpra-0.6.0-4.el6.i386.rpm Thanks! Antoine On 09/07/2012 04:10 AM, Bob Tennent wrote: > One issue I see with xpra-0.6.0-3 on Centos6.3 is that the window > "pointer" is about 60 pixels above the point it's really pointing at. > This is most evident when going down a menu and the highlighted entry is > the one *below* the pointer. This is for a remote server. I don't think > I'd had this with an earlier version but perhaps I never noticed it. > > Bob T. From antoine at nagafix.co.uk Sat Sep 8 13:49:08 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 08 Sep 2012 19:49:08 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.6.0 (and stable updates) Message-ID: <504B3EC4.5010004@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This new release does not bring any major new enhancements, but the code structure is much improved and lays some more solid foundations for the future. The only significant change that you may notice is that x264 (or vpx) are now the default encodings ahead of png, rgb24 and jpeg. You can obviously change this default in /etc/xpra/xpra.conf, or in each user's .xpra/xpra.conf I shouldn't say that this is the last update to the stable branches... because the last time I said this was just a few days ago, but I really mean it this time! (0.5.x will be maintained for a while still) The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ (the Windows installers are now also signed with my gpg key) Cheers Antoine Release notes for 0.6.0: * fix launcher: don't block the UI whilst connecting, and use a lower timeout, fix icon lookup on *nix * fix clipboard contents too big (was causing connection drops): try to compress them and just drop them if they are still too big * x264 or vpx are now the default encodings (if available) * compress rgb24 pixel data with zlib from the damage thread (rather than later in the network layer) * better build environment detection * experimental multi-user support (see --enable-sharing) * better, more accurate "xpra info" statistics (per encoding, etc) * tidy up main source directory * simplify video encoders/decoders setup and cleanup code * many debian build files updates * remove 'nogil' switch (as 'nogil' is much faster) * test all socket types with automated tests Stable fixes for all branches: * fix man page typo * fix non bash login shell compatibility * fix xpra screenshot argument parsing error handling Stable fixes in 0.5.4 only: * fix video encoding mismatch when switching encoding * fix ssh mode on OpenBSD -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBLPsQACgkQGK2zHPGK1rvBwACfbEx2bgRVzwbLsVObA/VNPxJD m88AnRwUMEv69mfVoH3XNx8hDB02OzWM =N+wB -----END PGP SIGNATURE----- From rogeriobastos at dcc.ufba.br Sat Sep 8 16:51:10 2012 From: rogeriobastos at dcc.ufba.br (Rogerio Bastos) Date: Sat, 8 Sep 2012 12:51:10 -0300 Subject: [winswitch] Wrong keyboard setting when resume NX session Message-ID: <20120908155110.GA4278@matrix> Hi guys, Any news about this [1] problem? [1] http://winswitch.org/trac/ticket/215 -- Rogerio Bastos From antoine at nagafix.co.uk Sun Sep 9 11:28:13 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 09 Sep 2012 17:28:13 +0700 Subject: [winswitch] Wrong keyboard setting when resume NX session In-Reply-To: <20120908155110.GA4278@matrix> References: <20120908155110.GA4278@matrix> Message-ID: <504C6F3D.80306@nagafix.co.uk> On 09/08/2012 10:51 PM, Rogerio Bastos wrote: > Hi guys, > > Any news about this [1] problem? > > [1] http://winswitch.org/trac/ticket/215 > Updated, please see: https://winswitch.org/trac/ticket/215#comment:13 works-for-me(tm) From antoine at nagafix.co.uk Mon Sep 10 13:29:18 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 10 Sep 2012 19:29:18 +0700 Subject: [winswitch] [ANNOUNCE] winswitch 0.12.16 Message-ID: <504DDD1E.9010908@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Version 0.12.16 is available now: http://winswitch.org/downloads/ This bug release contains many small fixes and improvements, but if you were not experiencing any problems with previous versions there is no urgency to upgrade. It also adds the latest Xpra 0.6.0 release to binary installers. As with Xpra, the MS Windows and OS X images now have gpg signatures. Cheers Antoine Full release notes: * fix log file rotation (auto-start on KDE, and other problems) * fix missing icon for system tray on some platforms/desktops * fix pre-loading and pre-connection of Xpra sessions * fix error notifications shown when stopping or disconnecting a server * fix NX keyboard mapping * preserve Xpra session options when capturing them * select more suitable server for start session dialogs * packaging fixes: dependencies updates, version and change detection * offer to install mDNS support via packagekit on Linux * source RPMs fixed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBN3R0ACgkQGK2zHPGK1rv1YwCfQ2GE8NSrlFBNnLhB9QLP6QNK JD4An3rrDwg+0ng6eWqVCV/jBzFkPiKd =hyHP -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Tue Sep 11 05:03:43 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 11 Sep 2012 11:03:43 +0700 Subject: [winswitch] [ANNOUNCE] winswitch 0.12.16 In-Reply-To: <504DDD1E.9010908@nagafix.co.uk> References: <504DDD1E.9010908@nagafix.co.uk> Message-ID: <504EB81F.7040701@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Those using the debian packages will want to grab the update I have just pushed out (0.12.16-2) to fix Xpra version detection. (absurd debian packaging strikes again) Sorry for the inconvenience. Antoine On 09/10/2012 07:29 PM, Antoine Martin wrote: > Hi, > > Version 0.12.16 is available now: http://winswitch.org/downloads/ > > This bug release contains many small fixes and improvements, but > if you were not experiencing any problems with previous versions > there is no urgency to upgrade. It also adds the latest Xpra 0.6.0 > release to binary installers. As with Xpra, the MS Windows and OS X > images now have gpg signatures. > > Cheers Antoine > > Full release notes: * fix log file rotation (auto-start on KDE, and > other problems) * fix missing icon for system tray on some > platforms/desktops * fix pre-loading and pre-connection of Xpra > sessions * fix error notifications shown when stopping or > disconnecting a server * fix NX keyboard mapping * preserve Xpra > session options when capturing them * select more suitable server > for start session dialogs * packaging fixes: dependencies updates, > version and change detection * offer to install mDNS support via > packagekit on Linux * source RPMs fixed > _______________________________________________ shifter-users > mailing list shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBOuB8ACgkQGK2zHPGK1rumOgCeNiEPg9UDvU7Gcfhch1Mvc+wO 2EoAnjhwVxRym4+6iGBTh9V+uHF+orV8 =ONNY -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Fri Sep 14 17:54:33 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 14 Sep 2012 23:54:33 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.6.1 Message-ID: <50536149.5020603@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This minor stable update to the 0.6 branch fixes just 2 small bugs: * compress or drop clipboard data (previous fix was ineffectual) * fix missing damage data queue statistics (was causing latency issues) The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBTYUkACgkQGK2zHPGK1ruYQQCfRFjyzE8Imxemm+N3x7XdH233 flAAnixxiOG6+XuhdA0uKOZxo4yo0r+3 =tK6n -----END PGP SIGNATURE----- From onlyjob at member.fsf.org Sat Sep 15 02:36:34 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sat, 15 Sep 2012 11:36:34 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <50536149.5020603@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> Message-ID: <201209151136.34382.onlyjob@member.fsf.org> Hi Antoine, Thank you for your work. I hope you don't mind some feedback: First of all I think changing default encoding from PNG wasn't such a good idea. By default visual quality is now degraded comparing to previous versions. (I know I can override in config but I would prefer high quality defaults). Personally I feel very uncomfortable with new defaults. Of course first thing I tried is to change encoding as soon as I connected to 0.6.1 instance using 0.6.1 as client. When I've chosen "vpx" as compression, xpra (client) crashed as soon as I moved mouse over remote application. The following was printed to console: Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.7/dist-packages/xpra/proxy.py", line 26, in _to_client_loop self._copy_loop("<-server", self._server_conn, self._client_conn) File "/usr/lib/python2.7/dist-packages/xpra/proxy.py", line 36, in _copy_loop buf = untilConcludes(from_conn.read, 4096) File "/usr/lib/python2.7/dist-packages/xpra/bytestreams.py", line 16, in untilConcludes return f(*a, **kw) File "/usr/lib/python2.7/dist-packages/xpra/bytestreams.py", line 66, in read return self._s.recv(n) error: [Errno 104] Connection reset by peer Exception in thread Thread-2: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.7/dist-packages/xpra/proxy.py", line 30, in _to_server_loop self._copy_loop("->server", self._client_conn, self._server_conn) File "/usr/lib/python2.7/dist-packages/xpra/proxy.py", line 43, in _copy_loop written = untilConcludes(to_conn.write, buf) File "/usr/lib/python2.7/dist-packages/xpra/bytestreams.py", line 16, in untilConcludes return f(*a, **kw) File "/usr/lib/python2.7/dist-packages/xpra/bytestreams.py", line 69, in write return self._s.send(buf) error: [Errno 32] Broken pipe 2012-09-15 11:26:24,544 Connection lost Reconnecting to server wasn't possible. Server log had only one error: [swscaler @ 0x3eca5e0] 1x1 -> 1x1 is invalid scaling dimension To fix I ran "xpra upgrade :N" on server and I was able to attach again. All the best, Dmitry. From antoine at nagafix.co.uk Sat Sep 15 06:11:20 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 15 Sep 2012 12:11:20 +0700 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <201209151136.34382.onlyjob@member.fsf.org> References: <50536149.5020603@nagafix.co.uk> <201209151136.34382.onlyjob@member.fsf.org> Message-ID: <50540DF8.3090707@nagafix.co.uk> On 09/15/2012 08:36 AM, Dmitry Smirnov wrote: > Hi Antoine, > > Thank you for your work. I hope you don't mind some feedback: No, quite the opposite, I welcome it! > First of all I think changing default encoding from PNG wasn't such a good > idea. By default visual quality is now degraded comparing to previous > versions. It shouldn't be. x264 (and to a lesser extent vpx) offer almost lossless visual quality, with much higher compression. > (I know I can override in config but I would prefer high quality > defaults). Personally I feel very uncomfortable with new defaults. Can you specify the application, and link characteristics? How do I get this lower visual quality you experienced? Note: there was a bug in the 0.6.0 server which caused quality to degrade (and not recover quickly enough), this is one of the reasons for the 0.6.1 release. (upgrading the client alone would not be enough to fix this issue) This undocumented debugging trick can dump all the encoding quality and batch delay calculation messages to the server log: start your server with: XPRA_DEBUG_LATENCY=1 xpra start ... > Of course first thing I tried is to change encoding as soon as I connected to > 0.6.1 instance using 0.6.1 as client. When I've chosen "vpx" as compression, > xpra (client) crashed as soon as I moved mouse over remote application. > The following was printed to console: > (snip) > 2012-09-15 11:26:24,544 Connection lost Both of those stacktraces show that the server crashed or disconnected, the real cause is in the server logs... > Reconnecting to server wasn't possible. Server log had only one error: > > [swscaler @ 0x3eca5e0] 1x1 -> 1x1 is invalid scaling dimension Hah, there is some code to avoid windows that small with x264 (it only handles even dimensions), looks like vpx needs a similar workaround for a different reason (YUV to RGB conversion with swscale seems to not support very small dimensions), so here is the fix: https://www.xpra.org/trac/changeset/1543 I cannot find the minimum dimensions specified anywhere, so I've used the same restrictions as x264: avoid 1 pixel wide or high dimensions. (will backport to old branches too) Cheers Antoine > > To fix I ran "xpra upgrade :N" on server and I was able to attach again. > > All the best, > Dmitry. > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From onlyjob at member.fsf.org Sat Sep 15 12:51:00 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sat, 15 Sep 2012 21:51:00 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <50540DF8.3090707@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209151136.34382.onlyjob@member.fsf.org> <50540DF8.3090707@nagafix.co.uk> Message-ID: <201209152151.00657.onlyjob@member.fsf.org> On Sat, 15 Sep 2012 15:11:20 Antoine Martin wrote: > > Thank you for your work. I hope you don't mind some feedback: > No, quite the opposite, I welcome it! Thank you. :) > > First of all I think changing default encoding from PNG wasn't such a > > good idea. By default visual quality is now degraded comparing to > > previous versions. > > It shouldn't be. x264 (and to a lesser extent vpx) offer almost lossless > visual quality, with much higher compression. Well my eyes are not lying. :) Perhaps "almost" is not good enough for me. > > > (I know I can override in config but I would prefer high quality > > defaults). Personally I feel very uncomfortable with new defaults. > > Can you specify the application, and link characteristics? > How do I get this lower visual quality you experienced? Any application, but most notably it can be seen with text. I use iceweasel (a.k.a. Firefox) or kmail or any text application -- text looks blurry in all of them, like if I have a dirty monitor. There are artefacts similar to low- qiality jpeg compression around letters. Looks like sometimes when window is not refreshed for some time (no scrolling or other activity) text quality improves a little for some time until I select text or scroll etc. This is very noticeable on thin black lines on white background. I'm surprised you didn't see it. I attached a screenshot do demonstrate the problem. Connection is local 1GB Ethernet. > Note: there was a bug in the 0.6.0 server which caused quality to > degrade (and not recover quickly enough), this is one of the reasons for > the 0.6.1 release. > (upgrading the client alone would not be enough to fix this issue) > > This undocumented debugging trick can dump all the encoding quality and > batch delay calculation messages to the server log: start your server with: > XPRA_DEBUG_LATENCY=1 xpra start ... I did that with "xpra upgrade" -- see some samples from log below. > > Of course first thing I tried is to change encoding as soon as I > > connected to 0.6.1 instance using 0.6.1 as client. When I've chosen > > "vpx" as compression, xpra (client) crashed as soon as I moved mouse > > over remote application. > > > Reconnecting to server wasn't possible. Server log had only one error: > > [swscaler @ 0x3eca5e0] 1x1 -> 1x1 is invalid scaling dimension > > Hah, there is some code to avoid windows that small with x264 (it only > handles even dimensions), looks like vpx needs a similar workaround for > a different reason (YUV to RGB conversion with swscale seems to not > support very small dimensions), so here is the fix: > https://www.xpra.org/trac/changeset/1543 > I cannot find the minimum dimensions specified anywhere, so I've used > the same restrictions as x264: avoid 1 pixel wide or high dimensions. > (will backport to old branches too) Thank you for the patch. I applied to both server and client but server crashed in exactly the same way with the same error logged. Anything else I can do to help? Regards, Dmitry. ############## 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.05, target_damage_latency=0.06, batch.delay=7.46, dam_lat=0.39, dec_lat=0.02, target=39, new_speed=34 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, batch_q=2.68, latency_q=0.77, target=77, new_quality=66 2012-09-15 21:37:21,286 update_batch_delay: wid=0, last updated 170.75 ms ago, decay=1.0, change factor=-4.9%, delay min=5.7, avg=7.2, max=10.7, cur=7.4, w. average=6.4, tot wgt=16.2, hist_w=8.1, new delay=7.0 ('damage processing latency: avg=0.039, recent=0.105, target=0.052, aim=0.8, aimed avg factor=2.285, div=1.0, s=', 1.51, 0.71) ('damage send latency: avg=0.044, recent=0.113, target=0.076, aim=0.8, aimed avg factor=1.944, div=1.0, s=', 1.39, 0.62) ('network send speed: avg=195351, recent=120187 (KBytes/s), div=9.87646281417', 1.39, 0.14) ('client decode speed: avg=34.8, recent=34.5 (MPixels/s)', 1.0, 0.0) ('delay not updated for 169.4 ms (skipped 4 times - highest latency is 113.4)', 0.0, 0.0) ('client latency: avg=0.037, recent=0.039, target=0.005, aim=0.8, aimed avg factor=1.559, div=1.0, s=', 1.24, 1.99) ('damage packet queue size: avg=0.109, recent=0.011, target=1.0, aim=0.25, aimed avg factor=0.007, div=1.0, s=', 0.08, 0.95) ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, aimed avg factor=0.0, div=894720, s=', 0.0, 1.0) ('damage data queue: avg=0.063, recent=0.006, target=1.0, aim=0.25, aimed avg factor=0.003, div=1.0, s=', 0.0, 0.99) 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.05, target_damage_latency=0.05, batch.delay=7.08, dam_lat=0.65, dec_lat=0.02, target=65, new_speed=43 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, batch_q=2.82, latency_q=0.5, target=50, new_quality=65 2012-09-15 21:37:21,286 update_batch_delay: wid=0, last updated 64.0 ms ago, decay=1.0, change factor=-2.5%, delay min=5.7, avg=7.1, max=10.7, cur=7.0, w. average=6.6, tot wgt=19.5, hist_w=9.7, new delay=6.9 ('damage processing latency: avg=0.043, recent=0.108, target=0.052, aim=0.8, aimed avg factor=2.173, div=1.0, s=', 1.47, 0.68) ('damage send latency: avg=0.047, recent=0.114, target=0.076, aim=0.8, aimed avg factor=1.851, div=1.0, s=', 1.36, 0.6) ('network send speed: avg=163578, recent=94808 (KBytes/s), div=9.53467132886', 1.44, 0.15) ('client decode speed: avg=34.9, recent=34.8 (MPixels/s)', 1.0, 0.0) ('delay not updated for 62.7 ms (skipped 1 times - highest latency is 114.6)', 0.0, 0.0) ('client latency: avg=0.036, recent=0.037, target=0.005, aim=0.8, aimed avg factor=1.453, div=1.0, s=', 1.2, 1.81) ('damage packet queue size: avg=0.107, recent=0.01, target=1.0, aim=0.25, aimed avg factor=0.006, div=1.0, s=', 0.07, 0.96) ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, aimed avg factor=0.0, div=894720, s=', 0.0, 1.0) ('damage data queue: avg=0.06, recent=0.004, target=1.0, aim=0.25, aimed avg factor=0.002, div=1.0, s=', 0.0, 0.99) 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.05, target_damage_latency=0.05, batch.delay=6.91, dam_lat=0.72, dec_lat=0.02, target=72, new_speed=51 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, batch_q=2.89, latency_q=0.53, target=53, new_quality=64 2012-09-15 21:37:21,286 update_batch_delay: wid=0, last updated 1531.75 ms ago, decay=1.0, change factor=6.6%, delay min=5.7, avg=7.0, max=10.7, cur=5.8, w. average=6.6, tot wgt=20.7, hist_w=10.3, new delay=6.1 ('damage processing latency: avg=0.015, recent=0.028, target=0.065, aim=0.8, aimed avg factor=1.201, div=1.0, s=', 1.09, 0.31) ('damage send latency: avg=0.017, recent=0.03, target=0.091, aim=0.8, aimed avg factor=0.947, div=1.0, s=', 0.97, 0.16) ('network send speed: avg=219612, recent=149175 (KBytes/s), div=10.1878876417', 1.3, 0.12) ('client decode speed: avg=17.2, recent=12.5 (MPixels/s)', 1.24, 0.24) ('delay not updated for 1530.3 ms (skipped 38 times - highest latency is 30.1)', 0.0, 0.0) ('client latency: avg=0.036, recent=0.033, target=0.005, aim=0.8, aimed avg factor=1.313, div=1.0, s=', 1.14, 1.52) ('damage packet queue size: avg=0.099, recent=0.006, target=1.0, aim=0.25, aimed avg factor=0.003, div=1.0, s=', 0.06, 0.96) ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, aimed avg factor=0.0, div=1160488, s=', 0.0, 1.0) ('damage data queue: avg=0.059, recent=0.004, target=1.0, aim=0.25, aimed avg factor=0.002, div=1.0, s=', 0.0, 0.99) 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.06, target_damage_latency=0.07, batch.delay=6.18, dam_lat=0.21, dec_lat=0.05, target=21, new_speed=20 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, batch_q=3.23, latency_q=0.6, target=60, new_quality=84 2012-09-15 21:37:21,287 update_batch_delay: wid=0, last updated 63.64 ms ago, decay=1.0, change factor=-2.4%, delay min=5.7, avg=6.9, max=10.7, cur=6.1, w. average=6.5, tot wgt=22.0, hist_w=11.0, new delay=6.0 ('damage processing latency: avg=0.014, recent=0.006, target=0.065, aim=0.8, aimed avg factor=0.272, div=1.0, s=', 0.52, 0.69) ('damage send latency: avg=0.015, recent=0.006, target=0.091, aim=0.8, aimed avg factor=0.22, div=1.0, s=', 0.46, 0.72) ('network send speed: avg=220731, recent=149838 (KBytes/s), div=10.1942764793', 1.3, 0.12) ('client decode speed: avg=17.2, recent=12.6 (MPixels/s)', 1.24, 0.24) ('delay not updated for 62.6 ms (skipped 1 times - highest latency is 15.8)', 0.0, 0.0) ('client latency: avg=0.035, recent=0.028, target=0.005, aim=0.8, aimed avg factor=1.146, div=1.0, s=', 1.07, 1.06) ('damage packet queue size: avg=0.098, recent=0.006, target=1.0, aim=0.25, aimed avg factor=0.003, div=1.0, s=', 0.06, 0.96) ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, aimed avg factor=0.0, div=1160488, s=', 0.0, 1.0) ('damage data queue: avg=0.058, recent=0.003, target=1.0, aim=0.25, aimed avg factor=0.002, div=1.0, s=', 0.0, 0.99) 2012-09-15 21:37:21,287 video encoder speed factors: min_damage_latency=0.06, target_damage_latency=0.07, batch.delay=6.03, dam_lat=0.19, dec_lat=0.05, target=19, new_speed=20 2012-09-15 21:37:21,287 video encoder quality factors: packets_bl=1.0, batch_q=3.31, latency_q=0.69, target=69, new_quality=82 2012-09-15 21:37:21,287 update_batch_delay: wid=0, last updated 160.24 ms ago, decay=1.0, change factor=-11.0%, delay min=5.7, avg=6.8, max=10.7, cur=6.9, w. average=6.4, tot wgt=25.6, hist_w=12.8, new delay=6.1 ('damage processing latency: avg=0.039, recent=0.068, target=0.052, aim=0.8, aimed avg factor=1.473, div=1.0, s=', 1.21, 0.46) ('damage send latency: avg=0.043, recent=0.072, target=0.076, aim=0.8, aimed avg factor=1.252, div=1.0, s=', 1.11, 0.34) ('network send speed: avg=257766, recent=245588 (KBytes/s), div=10.906633034', 1.03, 0.09) ('client decode speed: avg=34.9, recent=34.8 (MPixels/s)', 1.0, 0.0) ('delay not updated for 158.9 ms (skipped 3 times - highest latency is 72.7)', 0.0, 0.0) ('client latency: avg=0.034, recent=0.025, target=0.005, aim=0.8, aimed avg factor=1.015, div=1.0, s=', 1.0, 0.35) ('damage packet queue size: avg=0.093, recent=0.004, target=1.0, aim=0.25, aimed avg factor=0.002, div=1.0, s=', 0.05, 0.97) ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, aimed avg factor=0.0, div=894720, s=', 0.0, 1.0) ('damage data queue: avg=0.055, recent=0.002, target=1.0, aim=0.25, aimed avg factor=0.001, div=1.0, s=', 0.0, 0.99) 2012-09-15 21:37:21,287 video encoder speed factors: min_damage_latency=0.05, target_damage_latency=0.05, batch.delay=6.15, dam_lat=0.67, dec_lat=0.02, target=67, new_speed=56 2012-09-15 21:37:21,287 video encoder quality factors: packets_bl=1.0, batch_q=3.25, latency_q=0.79, target=79, new_quality=65 2012-09-15 21:37:21,287 update_batch_delay: wid=0, last updated 49.03 ms ago, decay=1.0, change factor=-3.1%, delay min=5.7, avg=6.7, max=10.2, cur=6.0, w. average=6.4, tot wgt=29.2, hist_w=14.6, new delay=5.8 ('damage processing latency: avg=0.012, recent=0.002, target=0.065, aim=0.8, aimed avg factor=0.134, div=1.0, s=', 0.36, 0.79) ('damage send latency: avg=0.013, recent=0.004, target=0.091, aim=0.8, aimed avg factor=0.148, div=1.0, s=', 0.38, 0.78) ('network send speed: avg=221556, recent=150346 (KBytes/s), div=10.1991576671', 1.3, 0.12) ('client decode speed: avg=17.3, recent=12.7 (MPixels/s)', 1.23, 0.23) ('delay not updated for 47.4 ms (skipped 1 times - highest latency is 13.9)', 0.0, 0.0) ('client latency: avg=0.033, recent=0.02, target=0.005, aim=0.8, aimed avg factor=0.83, div=1.0, s=', 0.91, 1.19) ('damage packet queue size: avg=0.091, recent=0.004, target=1.0, aim=0.25, aimed avg factor=0.002, div=1.0, s=', 0.05, 0.97) ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, aimed avg factor=0.0, div=1160488, s=', 0.0, 1.0) ('damage data queue: avg=0.053, recent=0.002, target=1.0, aim=0.25, aimed avg factor=0.001, div=1.0, s=', 0.0, 0.99) From antoine at nagafix.co.uk Sun Sep 16 13:20:47 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 16 Sep 2012 19:20:47 +0700 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <201209152151.00657.onlyjob@member.fsf.org> References: <50536149.5020603@nagafix.co.uk> <201209151136.34382.onlyjob@member.fsf.org> <50540DF8.3090707@nagafix.co.uk> <201209152151.00657.onlyjob@member.fsf.org> Message-ID: <5055C41F.9000301@nagafix.co.uk> (snip) >>> First of all I think changing default encoding from PNG wasn't such a >>> good idea. By default visual quality is now degraded comparing to >>> previous versions. >> >> It shouldn't be. x264 (and to a lesser extent vpx) offer almost lossless >> visual quality, with much higher compression. > > Well my eyes are not lying. :) Perhaps "almost" is not good enough for me. What you are seeing is a bug, when tuned properly (automagically and on a fast enough connection) x264 is indistinguishable from lossless encodings. >>> (I know I can override in config but I would prefer high quality >>> defaults). Personally I feel very uncomfortable with new defaults. >> >> Can you specify the application, and link characteristics? >> How do I get this lower visual quality you experienced? > > Any application, but most notably it can be seen with text. I use iceweasel > (a.k.a. Firefox) or kmail or any text application -- text looks blurry in all > of them, like if I have a dirty monitor. There are artefacts similar to low- > qiality jpeg compression around letters. Looks like sometimes when window is > not refreshed for some time (no scrolling or other activity) text quality > improves a little for some time until I select text or scroll etc. > > This is very noticeable on thin black lines on white background. > I'm surprised you didn't see it. I attached a screenshot do demonstrate the > problem. > > Connection is local 1GB Ethernet. Thanks, will take a look. I am currently re-working the latency and quality knobs, aiming to make it choose suitable delays and quality in all cases, but it may be that we end up having to give the user control over the quality vs latency tradeoff, as a simple spinner in Firefox is often enough to skew the statistics.. (snip) >>> Reconnecting to server wasn't possible. Server log had only one error: >>> [swscaler @ 0x3eca5e0] 1x1 -> 1x1 is invalid scaling dimension >> >> Hah, there is some code to avoid windows that small with x264 (it only >> handles even dimensions), looks like vpx needs a similar workaround for >> a different reason (YUV to RGB conversion with swscale seems to not >> support very small dimensions), so here is the fix: >> https://www.xpra.org/trac/changeset/1543 >> I cannot find the minimum dimensions specified anywhere, so I've used >> the same restrictions as x264: avoid 1 pixel wide or high dimensions. >> (will backport to old branches too) > > Thank you for the patch. I applied to both server and client but server > crashed in exactly the same way with the same error logged. > Anything else I can do to help? Hmm, I don't see how it is possible to get a 1x1 area with the patch applied, have you got a specific app that creates those 1x1 windows? (I can always cook one up, but would rather make sure I use the same one) Cheers Antoine > > > Regards, > Dmitry. > > ############## > 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.05, > target_damage_latency=0.06, batch.delay=7.46, dam_lat=0.39, dec_lat=0.02, > target=39, new_speed=34 > 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, > batch_q=2.68, latency_q=0.77, target=77, new_quality=66 > 2012-09-15 21:37:21,286 update_batch_delay: wid=0, last updated 170.75 ms ago, > decay=1.0, change factor=-4.9%, delay min=5.7, avg=7.2, max=10.7, cur=7.4, w. > average=6.4, tot wgt=16.2, hist_w=8.1, new delay=7.0 > ('damage processing latency: avg=0.039, recent=0.105, target=0.052, aim=0.8, > aimed avg factor=2.285, div=1.0, s=', 1.51, 0.71) > ('damage send latency: avg=0.044, recent=0.113, target=0.076, aim=0.8, aimed > avg factor=1.944, div=1.0, s=', 1.39, 0.62) > ('network send speed: avg=195351, recent=120187 (KBytes/s), > div=9.87646281417', 1.39, 0.14) > ('client decode speed: avg=34.8, recent=34.5 (MPixels/s)', 1.0, 0.0) > ('delay not updated for 169.4 ms (skipped 4 times - highest latency is > 113.4)', 0.0, 0.0) > ('client latency: avg=0.037, recent=0.039, target=0.005, aim=0.8, aimed avg > factor=1.559, div=1.0, s=', 1.24, 1.99) > ('damage packet queue size: avg=0.109, recent=0.011, target=1.0, aim=0.25, > aimed avg factor=0.007, div=1.0, s=', 0.08, 0.95) > ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, > aimed avg factor=0.0, div=894720, s=', 0.0, 1.0) > ('damage data queue: avg=0.063, recent=0.006, target=1.0, aim=0.25, aimed avg > factor=0.003, div=1.0, s=', 0.0, 0.99) > 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.05, > target_damage_latency=0.05, batch.delay=7.08, dam_lat=0.65, dec_lat=0.02, > target=65, new_speed=43 > 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, > batch_q=2.82, latency_q=0.5, target=50, new_quality=65 > 2012-09-15 21:37:21,286 update_batch_delay: wid=0, last updated 64.0 ms ago, > decay=1.0, change factor=-2.5%, delay min=5.7, avg=7.1, max=10.7, cur=7.0, w. > average=6.6, tot wgt=19.5, hist_w=9.7, new delay=6.9 > ('damage processing latency: avg=0.043, recent=0.108, target=0.052, aim=0.8, > aimed avg factor=2.173, div=1.0, s=', 1.47, 0.68) > ('damage send latency: avg=0.047, recent=0.114, target=0.076, aim=0.8, aimed > avg factor=1.851, div=1.0, s=', 1.36, 0.6) > ('network send speed: avg=163578, recent=94808 (KBytes/s), > div=9.53467132886', 1.44, 0.15) > ('client decode speed: avg=34.9, recent=34.8 (MPixels/s)', 1.0, 0.0) > ('delay not updated for 62.7 ms (skipped 1 times - highest latency is > 114.6)', 0.0, 0.0) > ('client latency: avg=0.036, recent=0.037, target=0.005, aim=0.8, aimed avg > factor=1.453, div=1.0, s=', 1.2, 1.81) > ('damage packet queue size: avg=0.107, recent=0.01, target=1.0, aim=0.25, > aimed avg factor=0.006, div=1.0, s=', 0.07, 0.96) > ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, > aimed avg factor=0.0, div=894720, s=', 0.0, 1.0) > ('damage data queue: avg=0.06, recent=0.004, target=1.0, aim=0.25, aimed avg > factor=0.002, div=1.0, s=', 0.0, 0.99) > 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.05, > target_damage_latency=0.05, batch.delay=6.91, dam_lat=0.72, dec_lat=0.02, > target=72, new_speed=51 > 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, > batch_q=2.89, latency_q=0.53, target=53, new_quality=64 > 2012-09-15 21:37:21,286 update_batch_delay: wid=0, last updated 1531.75 ms > ago, decay=1.0, change factor=6.6%, delay min=5.7, avg=7.0, max=10.7, cur=5.8, > w. average=6.6, tot wgt=20.7, hist_w=10.3, new delay=6.1 > ('damage processing latency: avg=0.015, recent=0.028, target=0.065, aim=0.8, > aimed avg factor=1.201, div=1.0, s=', 1.09, 0.31) > ('damage send latency: avg=0.017, recent=0.03, target=0.091, aim=0.8, aimed > avg factor=0.947, div=1.0, s=', 0.97, 0.16) > ('network send speed: avg=219612, recent=149175 (KBytes/s), > div=10.1878876417', 1.3, 0.12) > ('client decode speed: avg=17.2, recent=12.5 (MPixels/s)', 1.24, 0.24) > ('delay not updated for 1530.3 ms (skipped 38 times - highest latency is > 30.1)', 0.0, 0.0) > ('client latency: avg=0.036, recent=0.033, target=0.005, aim=0.8, aimed avg > factor=1.313, div=1.0, s=', 1.14, 1.52) > ('damage packet queue size: avg=0.099, recent=0.006, target=1.0, aim=0.25, > aimed avg factor=0.003, div=1.0, s=', 0.06, 0.96) > ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, > aimed avg factor=0.0, div=1160488, s=', 0.0, 1.0) > ('damage data queue: avg=0.059, recent=0.004, target=1.0, aim=0.25, aimed avg > factor=0.002, div=1.0, s=', 0.0, 0.99) > 2012-09-15 21:37:21,286 video encoder speed factors: min_damage_latency=0.06, > target_damage_latency=0.07, batch.delay=6.18, dam_lat=0.21, dec_lat=0.05, > target=21, new_speed=20 > 2012-09-15 21:37:21,286 video encoder quality factors: packets_bl=1.0, > batch_q=3.23, latency_q=0.6, target=60, new_quality=84 > 2012-09-15 21:37:21,287 update_batch_delay: wid=0, last updated 63.64 ms ago, > decay=1.0, change factor=-2.4%, delay min=5.7, avg=6.9, max=10.7, cur=6.1, w. > average=6.5, tot wgt=22.0, hist_w=11.0, new delay=6.0 > ('damage processing latency: avg=0.014, recent=0.006, target=0.065, aim=0.8, > aimed avg factor=0.272, div=1.0, s=', 0.52, 0.69) > ('damage send latency: avg=0.015, recent=0.006, target=0.091, aim=0.8, aimed > avg factor=0.22, div=1.0, s=', 0.46, 0.72) > ('network send speed: avg=220731, recent=149838 (KBytes/s), > div=10.1942764793', 1.3, 0.12) > ('client decode speed: avg=17.2, recent=12.6 (MPixels/s)', 1.24, 0.24) > ('delay not updated for 62.6 ms (skipped 1 times - highest latency is 15.8)', > 0.0, 0.0) > ('client latency: avg=0.035, recent=0.028, target=0.005, aim=0.8, aimed avg > factor=1.146, div=1.0, s=', 1.07, 1.06) > ('damage packet queue size: avg=0.098, recent=0.006, target=1.0, aim=0.25, > aimed avg factor=0.003, div=1.0, s=', 0.06, 0.96) > ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, > aimed avg factor=0.0, div=1160488, s=', 0.0, 1.0) > ('damage data queue: avg=0.058, recent=0.003, target=1.0, aim=0.25, aimed avg > factor=0.002, div=1.0, s=', 0.0, 0.99) > 2012-09-15 21:37:21,287 video encoder speed factors: min_damage_latency=0.06, > target_damage_latency=0.07, batch.delay=6.03, dam_lat=0.19, dec_lat=0.05, > target=19, new_speed=20 > 2012-09-15 21:37:21,287 video encoder quality factors: packets_bl=1.0, > batch_q=3.31, latency_q=0.69, target=69, new_quality=82 > 2012-09-15 21:37:21,287 update_batch_delay: wid=0, last updated 160.24 ms ago, > decay=1.0, change factor=-11.0%, delay min=5.7, avg=6.8, max=10.7, cur=6.9, w. > average=6.4, tot wgt=25.6, hist_w=12.8, new delay=6.1 > ('damage processing latency: avg=0.039, recent=0.068, target=0.052, aim=0.8, > aimed avg factor=1.473, div=1.0, s=', 1.21, 0.46) > ('damage send latency: avg=0.043, recent=0.072, target=0.076, aim=0.8, aimed > avg factor=1.252, div=1.0, s=', 1.11, 0.34) > ('network send speed: avg=257766, recent=245588 (KBytes/s), > div=10.906633034', 1.03, 0.09) > ('client decode speed: avg=34.9, recent=34.8 (MPixels/s)', 1.0, 0.0) > ('delay not updated for 158.9 ms (skipped 3 times - highest latency is > 72.7)', 0.0, 0.0) > ('client latency: avg=0.034, recent=0.025, target=0.005, aim=0.8, aimed avg > factor=1.015, div=1.0, s=', 1.0, 0.35) > ('damage packet queue size: avg=0.093, recent=0.004, target=1.0, aim=0.25, > aimed avg factor=0.002, div=1.0, s=', 0.05, 0.97) > ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, > aimed avg factor=0.0, div=894720, s=', 0.0, 1.0) > ('damage data queue: avg=0.055, recent=0.002, target=1.0, aim=0.25, aimed avg > factor=0.001, div=1.0, s=', 0.0, 0.99) > 2012-09-15 21:37:21,287 video encoder speed factors: min_damage_latency=0.05, > target_damage_latency=0.05, batch.delay=6.15, dam_lat=0.67, dec_lat=0.02, > target=67, new_speed=56 > 2012-09-15 21:37:21,287 video encoder quality factors: packets_bl=1.0, > batch_q=3.25, latency_q=0.79, target=79, new_quality=65 > 2012-09-15 21:37:21,287 update_batch_delay: wid=0, last updated 49.03 ms ago, > decay=1.0, change factor=-3.1%, delay min=5.7, avg=6.7, max=10.2, cur=6.0, w. > average=6.4, tot wgt=29.2, hist_w=14.6, new delay=5.8 > ('damage processing latency: avg=0.012, recent=0.002, target=0.065, aim=0.8, > aimed avg factor=0.134, div=1.0, s=', 0.36, 0.79) > ('damage send latency: avg=0.013, recent=0.004, target=0.091, aim=0.8, aimed > avg factor=0.148, div=1.0, s=', 0.38, 0.78) > ('network send speed: avg=221556, recent=150346 (KBytes/s), > div=10.1991576671', 1.3, 0.12) > ('client decode speed: avg=17.3, recent=12.7 (MPixels/s)', 1.23, 0.23) > ('delay not updated for 47.4 ms (skipped 1 times - highest latency is 13.9)', > 0.0, 0.0) > ('client latency: avg=0.033, recent=0.02, target=0.005, aim=0.8, aimed avg > factor=0.83, div=1.0, s=', 0.91, 1.19) > ('damage packet queue size: avg=0.091, recent=0.004, target=1.0, aim=0.25, > aimed avg factor=0.002, div=1.0, s=', 0.05, 0.97) > ('damage packet queue pixels: avg=0.0, recent=0.0, target=1.0, aim=0.25, > aimed avg factor=0.0, div=1160488, s=', 0.0, 1.0) > ('damage data queue: avg=0.053, recent=0.002, target=1.0, aim=0.25, aimed avg > factor=0.001, div=1.0, s=', 0.0, 0.99) > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From onlyjob at member.fsf.org Mon Sep 17 02:52:09 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Mon, 17 Sep 2012 11:52:09 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <5055C41F.9000301@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209152151.00657.onlyjob@member.fsf.org> <5055C41F.9000301@nagafix.co.uk> Message-ID: <201209171152.10016.onlyjob@member.fsf.org> On Sun, 16 Sep 2012 22:20:47 Antoine Martin wrote: > Thanks, will take a look. > I am currently re-working the latency and quality knobs, aiming to make > it choose suitable delays and quality in all cases, but it may be that > we end up having to give the user control over the quality vs latency > tradeoff, as a simple spinner in Firefox is often enough to skew the > statistics.. Great but until it's proven to work well I think PNG encoding as default would be better. > > Thank you for the patch. I applied to both server and client but server > > crashed in exactly the same way with the same error logged. > > Anything else I can do to help? > > Hmm, I don't see how it is possible to get a 1x1 area with the patch > applied, have you got a specific app that creates those 1x1 windows? > (I can always cook one up, but would rather make sure I use the same one) With patch applied I tested again and found that patch is actually may be helping a bit at the cost of visual distortion of ~2...4 pixels at right hand side of some windows. I tried to connect to two different xpra instances and couldn't crash both of them by switching to 'VPX' encoding. However third session where I have iceweasel, kmail and reportbug-ng running is crashing reliably. Regards, Dmitry. From onlyjob at member.fsf.org Mon Sep 17 03:00:55 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Mon, 17 Sep 2012 12:00:55 +1000 Subject: [winswitch] 0.6.1 -- little improvement idea Message-ID: <201209171200.55414.onlyjob@member.fsf.org> Hi Antoine, For those (like myself) who connecting to more than one xpra instance at the same time one tiny improvement could be very valuable: At the moment xpra tray icon do not provide any information about which server we're connected to or to which screen number. When running two or more xpra client instances it is impossible to distinguish one from another and therefore very hard to find the one you want to disconnect from. Would it be easy to implement a tiny helper message with server info on mouse hover and add one more line to Session info dialog? I'd like to have line like "Connected to deblab (192.168.0.4) :11" in session info and something similar on mouse hover above xpra tray icon. Also console message "Attached (press Control-C to detach)" could be improved to include this information. Thank you very much. Regards, Dmitry. From onlyjob at member.fsf.org Mon Sep 17 03:09:49 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Mon, 17 Sep 2012 12:09:49 +1000 Subject: [winswitch] 0.6.1 -- server-side clipboard problem Message-ID: <201209171209.50614.onlyjob@member.fsf.org> Hi Antoine, I've noticed another server-side problem with clipboard in 0.6.1: if I connect to server-0.6.1 using client-0.3.6 clipboard content is not pasting from local clipboard to remote application. Knowing about all those fixes you recently introduced this is more or less expected. However the real serious problem is that after I connected to server-0.6.1 from old client-0.3.6 (I didn't test other versions) clipboard doesn't work even if I connect from the very same client-0.6.1. Clipboard entry in tray icon menu become inactive and unticked like if there is no support for clipboard whatsoever. I was able to fix this issue temporarily by "xpra upgrade :8" on server side. It would be very nice if server could be slightly improved to avoid clipboard degradation from talking to older clients. Thank you. Cheers, Dmitry. From antoine at nagafix.co.uk Mon Sep 17 09:09:26 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 17 Sep 2012 15:09:26 +0700 Subject: [winswitch] 0.6.1 -- server-side clipboard problem In-Reply-To: <201209171209.50614.onlyjob@member.fsf.org> References: <201209171209.50614.onlyjob@member.fsf.org> Message-ID: <5056DAB6.50200@nagafix.co.uk> On 09/17/2012 09:09 AM, Dmitry Smirnov wrote: > Hi Antoine, > > I've noticed another server-side problem with clipboard in 0.6.1: > > if I connect to server-0.6.1 using client-0.3.6 clipboard content is not > pasting from local clipboard to remote application. > Knowing about all those fixes you recently introduced this is more or less > expected. Actually, this had nothing to do with the clipboard fixes, this bug was introduced by the experimental multi-client support. > However the real serious problem is that after I connected to server-0.6.1 > from old client-0.3.6 (I didn't test other versions) clipboard doesn't work > even if I connect from the very same client-0.6.1. Clipboard entry in tray > icon menu become inactive and unticked like if there is no support for > clipboard whatsoever. FYI: this has nothing to do with what versions you use to connect. > I was able to fix this issue temporarily by "xpra upgrade :8" on server side. > > It would be very nice if server could be slightly improved to avoid clipboard > degradation from talking to older clients. Fixed in: https://www.xpra.org/trac/changeset/1559 (will apply to 0.6 shortly) Cheers Antoine > > Thank you. > > Cheers, > Dmitry. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Mon Sep 17 09:10:27 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 17 Sep 2012 15:10:27 +0700 Subject: [winswitch] 0.6.1 -- little improvement idea In-Reply-To: <201209171200.55414.onlyjob@member.fsf.org> References: <201209171200.55414.onlyjob@member.fsf.org> Message-ID: <5056DAF3.5030500@nagafix.co.uk> On 09/17/2012 09:00 AM, Dmitry Smirnov wrote: > Hi Antoine, > > For those (like myself) who connecting to more than one xpra instance at the > same time one tiny improvement could be very valuable: > > At the moment xpra tray icon do not provide any information about which server > we're connected to or to which screen number. When running two or more xpra > client instances it is impossible to distinguish one from another and > therefore very hard to find the one you want to disconnect from. > > Would it be easy to implement a tiny helper message with server info on mouse > hover and add one more line to Session info dialog? > > I'd like to have line like > > "Connected to deblab (192.168.0.4) :11" Done. > in session info and something similar on mouse hover above xpra tray icon. Done. > Also console message "Attached (press Control-C to detach)" could be improved > to include this information. Done. Please try trunk and let me know. Cheers Antoine > > Thank you very much. > > Regards, > Dmitry. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Mon Sep 17 09:24:27 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 17 Sep 2012 15:24:27 +0700 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <201209171152.10016.onlyjob@member.fsf.org> References: <50536149.5020603@nagafix.co.uk> <201209152151.00657.onlyjob@member.fsf.org> <5055C41F.9000301@nagafix.co.uk> <201209171152.10016.onlyjob@member.fsf.org> Message-ID: <5056DE3B.8030700@nagafix.co.uk> On 09/17/2012 08:52 AM, Dmitry Smirnov wrote: > On Sun, 16 Sep 2012 22:20:47 Antoine Martin wrote: >> Thanks, will take a look. >> I am currently re-working the latency and quality knobs, aiming to make >> it choose suitable delays and quality in all cases, but it may be that >> we end up having to give the user control over the quality vs latency >> tradeoff, as a simple spinner in Firefox is often enough to skew the >> statistics.. > > Great but until it's proven to work well I think PNG encoding as default would > be better. No, sorry, x264 is the way forward, I'd rather fix the remaining latency and quality issues than use a slow and outdated encoding. >>> Thank you for the patch. I applied to both server and client but server >>> crashed in exactly the same way with the same error logged. >>> Anything else I can do to help? >> >> Hmm, I don't see how it is possible to get a 1x1 area with the patch >> applied, have you got a specific app that creates those 1x1 windows? >> (I can always cook one up, but would rather make sure I use the same one) > > With patch applied I tested again and found that patch is actually may be > helping a bit at the cost of visual distortion of ~2...4 pixels at right hand > side of some windows. I tried to connect to two different xpra instances and > couldn't crash both of them by switching to 'VPX' encoding. This visual distortion is probably from the colourspace conversion (I think), x264 is not affected because the size is rounded down to the nearest even number, I will try to find a better solution for vpx but we may end up taking the same approach.. AFAICT this is not related to this patch or other recent changes either. > However third session where I have iceweasel, kmail and reportbug-ng running > is crashing reliably. Downloaded and installed iceweasel, cannot reproduce... Cheers Antoine > > Regards, > Dmitry. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From onlyjob at member.fsf.org Mon Sep 17 13:18:07 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Mon, 17 Sep 2012 22:18:07 +1000 Subject: [winswitch] 0.6.1 -- little improvement idea In-Reply-To: <5056DAF3.5030500@nagafix.co.uk> References: <201209171200.55414.onlyjob@member.fsf.org> <5056DAF3.5030500@nagafix.co.uk> Message-ID: <201209172218.08416.onlyjob@member.fsf.org> On Mon, 17 Sep 2012 18:10:27 Antoine Martin wrote: > Please try trunk and let me know. Antoine, it is *perfect*. :) I'm in your debt mate. :) Thank you so much. Cheers, Dmitry. From onlyjob at member.fsf.org Mon Sep 17 13:33:11 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Mon, 17 Sep 2012 22:33:11 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <5056DE3B.8030700@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209171152.10016.onlyjob@member.fsf.org> <5056DE3B.8030700@nagafix.co.uk> Message-ID: <201209172233.12180.onlyjob@member.fsf.org> On Mon, 17 Sep 2012 18:24:27 Antoine Martin wrote: > > No, sorry, x264 is the way forward, I'd rather fix the remaining latency > and quality issues than use a slow and outdated encoding. No worries but please-please keep PNG encoding for high-speed connections. :) Just thinking: how about choosing the encoding dynamically on attaching? Something like when attaching, if bandwidth is high, choose PNG from very beginning but if connection is slow choose x264? I think it could be measured as number of KiB per sec for first 2-10 seconds after attaching.... I would try PNG first (because it's for highest quality) and see how fast we can pull the data. After few seconds xpra may decide to change encoding if data is coming too slow. Obviously we will need to calibrate but that's not difficult. Also in configuration file instead of "encoding = png" we could put something like "encoding = png,x264,jpg" to specify list of allowed encodings in the order of preference. Important thing would be to choose encoding only in the beginning but then allow user to switch while adjusting chosen encoding parameters dynamically as it is now. > > Downloaded and installed iceweasel, cannot reproduce... > Interesting... I was trying it too and now I took away https://www.xpra.org/trac/changeset/1543 and found that it has no effect whatsoever. I couldn't crash new sessions and one of the old ones which was not affected anyway. I still can crash one session where I initially fount the problem. I'll find out how to reproduce and will let you know. Cheers, Dmitry. From onlyjob at member.fsf.org Mon Sep 17 13:43:40 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Mon, 17 Sep 2012 22:43:40 +1000 Subject: [winswitch] 0.6.1 -- server-side clipboard problem In-Reply-To: <5056DAB6.50200@nagafix.co.uk> References: <201209171209.50614.onlyjob@member.fsf.org> <5056DAB6.50200@nagafix.co.uk> Message-ID: <201209172243.40802.onlyjob@member.fsf.org> On Mon, 17 Sep 2012 18:09:26 Antoine Martin wrote: > Actually, this had nothing to do with the clipboard fixes, this bug was > introduced by the experimental multi-client support. > Thanks, good to know. > > FYI: this has nothing to do with what versions you use to connect. > ACK. > > Fixed in: > https://www.xpra.org/trac/changeset/1559 > (will apply to 0.6 shortly) I tested it and I'm happy to report that this fixes the problem. Thank you. Regards, Dmitry. From antoine at nagafix.co.uk Mon Sep 17 14:21:07 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 17 Sep 2012 20:21:07 +0700 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <201209172233.12180.onlyjob@member.fsf.org> References: <50536149.5020603@nagafix.co.uk> <201209171152.10016.onlyjob@member.fsf.org> <5056DE3B.8030700@nagafix.co.uk> <201209172233.12180.onlyjob@member.fsf.org> Message-ID: <505723C3.3040202@nagafix.co.uk> On 09/17/2012 07:33 PM, Dmitry Smirnov wrote: > On Mon, 17 Sep 2012 18:24:27 Antoine Martin wrote: >> >> No, sorry, x264 is the way forward, I'd rather fix the remaining latency >> and quality issues than use a slow and outdated encoding. > > No worries but please-please keep PNG encoding for high-speed connections. :) PNG, rgb24, jpeg (and mmap!) are not deprecated and I have no intention of removing them. > Just thinking: how about choosing the encoding dynamically on attaching? winswitch does this a little bit better because it knows what command is being run, so it can pre-select x264 or vpx for video apps, etc.. > Something like when attaching, if bandwidth is high, choose PNG from very > beginning but if connection is slow choose x264? I think it could be measured > as number of KiB per sec for first 2-10 seconds after attaching.... > I would try PNG first (because it's for highest quality) and see how fast we > can pull the data. After few seconds xpra may decide to change encoding if > data is coming too slow. > Obviously we will need to calibrate but that's not difficult. > > Also in configuration file instead of "encoding = png" we could put something > like "encoding = png,x264,jpg" to specify list of allowed encodings in the > order of preference. Could do... but: > Important thing would be to choose encoding only in the beginning but then > allow user to switch while adjusting chosen encoding parameters dynamically as > it is now. This was originally planned, but x264 does all that and better: at high quality it is indistinguishable from lossless encodings (png or rgb24), at lower quality settings it is an order of magnitude more efficient than jpeg (and still with much better quality) All that's needed is to properly tune the quality based on bandwidth availability. Sounds simple, but it isn't. Bandwidth availability varies widely, and so does our "framerate" - which isn't necessarily a full-frame rate (from 0fps when idle to up to 200 updates per second). Then there are latency issues, etc.. >> Downloaded and installed iceweasel, cannot reproduce... >> > > Interesting... I was trying it too and now I took away > > https://www.xpra.org/trac/changeset/1543 > > and found that it has no effect whatsoever. I couldn't crash new sessions and > one of the old ones which was not affected anyway. > I still can crash one session where I initially fount the problem. > I'll find out how to reproduce and will let you know. I'll try to make a 1x1 window and see if it happens again. Cheers Antoine > > Cheers, > Dmitry. > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From onlyjob at member.fsf.org Mon Sep 17 16:45:10 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 18 Sep 2012 01:45:10 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <505723C3.3040202@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209172233.12180.onlyjob@member.fsf.org> <505723C3.3040202@nagafix.co.uk> Message-ID: <201209180145.10975.onlyjob@member.fsf.org> On Mon, 17 Sep 2012 23:21:07 Antoine Martin wrote: > This was originally planned, but x264 does all that and better: at high > quality it is indistinguishable from lossless encodings (png or rgb24), > at lower quality settings it is an order of magnitude more efficient > than jpeg (and still with much better quality) > All that's needed is to properly tune the quality based on bandwidth > availability. Sounds simple, but it isn't. > Bandwidth availability varies widely, and so does our "framerate" - > which isn't necessarily a full-frame rate (from 0fps when idle to up to > 200 updates per second). Then there are latency issues, etc.. I know how tricky it could be to do that kind of fine tuning. Maybe it's all not as important as to give user a way to choose quality like it is done for JPEG encoding. Since it is all about perception, there is no way to satisfy all situations automatically. I can always switch to a different encoding if necessary but the choice will depend on traffic conditions which are varies widely, as you've said. Personally at the moment I'm worried about current situation when new default to x264 is totally unusable in the ideal situation (low-latency gigabit ethernet with server several meters away from client connected to the same switch). We can't/shouldn't optimise to slow connection only by default. Especially because this wasn't the case for previous versions. I'm sure you know what you're doing but let's try to be a bit more conservative please. All the best, Dmitry. From dougdoole at gmail.com Mon Sep 17 14:25:11 2012 From: dougdoole at gmail.com (Douglas Doole) Date: Mon, 17 Sep 2012 09:25:11 -0400 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <5056DE3B.8030700@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209152151.00657.onlyjob@member.fsf.org> <5055C41F.9000301@nagafix.co.uk> <201209171152.10016.onlyjob@member.fsf.org> <5056DE3B.8030700@nagafix.co.uk> Message-ID: > > > Great but until it's proven to work well I think PNG encoding as default > would > > be better. > No, sorry, x264 is the way forward, I'd rather fix the remaining latency > and quality issues than use a slow and outdated encoding. I have to second the concerns about the rendering quality with x264. As the attached screenshot shows, text frequently degrades to the point where it is not easily readable. -- Doug Doole aibohphobia - The irrational fear of palindromes From antoine at nagafix.co.uk Mon Sep 17 17:44:06 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 17 Sep 2012 23:44:06 +0700 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <201209180145.10975.onlyjob@member.fsf.org> References: <50536149.5020603@nagafix.co.uk> <201209172233.12180.onlyjob@member.fsf.org> <505723C3.3040202@nagafix.co.uk> <201209180145.10975.onlyjob@member.fsf.org> Message-ID: <50575356.7060105@nagafix.co.uk> On 09/17/2012 10:45 PM, Dmitry Smirnov wrote: > On Mon, 17 Sep 2012 23:21:07 Antoine Martin wrote: >> This was originally planned, but x264 does all that and better: at high >> quality it is indistinguishable from lossless encodings (png or rgb24), >> at lower quality settings it is an order of magnitude more efficient >> than jpeg (and still with much better quality) >> All that's needed is to properly tune the quality based on bandwidth >> availability. Sounds simple, but it isn't. >> Bandwidth availability varies widely, and so does our "framerate" - >> which isn't necessarily a full-frame rate (from 0fps when idle to up to >> 200 updates per second). Then there are latency issues, etc.. > > I know how tricky it could be to do that kind of fine tuning. > Maybe it's all not as important as to give user a way to choose quality like > it is done for JPEG encoding. > > Since it is all about perception, there is no way to satisfy all situations > automatically. > > I can always switch to a different encoding if necessary but the choice will > depend on traffic conditions which are varies widely, as you've said. > > Personally at the moment I'm worried about current situation when new default > to x264 is totally unusable in the ideal situation (low-latency gigabit > ethernet with server several meters away from client connected to the same > switch). > > We can't/shouldn't optimise to slow connection only by default. Especially > because this wasn't the case for previous versions. > > I'm sure you know what you're doing but let's try to be a bit more > conservative please. Those who wish to stick with the more conservative code and use PNG as default encoding can stick with the stable 0.5 branch until all the problems are resolved. Cheers Antoine > > All the best, > Dmitry. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From onlyjob at member.fsf.org Tue Sep 18 02:19:42 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 18 Sep 2012 11:19:42 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <50575356.7060105@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209180145.10975.onlyjob@member.fsf.org> <50575356.7060105@nagafix.co.uk> Message-ID: <201209181119.43148.onlyjob@member.fsf.org> On Tue, 18 Sep 2012 02:44:06 Antoine Martin wrote: > Those who wish to stick with the more conservative code and use PNG as > default encoding can stick with the stable 0.5 branch until all the > problems are resolved. Absolutely -- use stable or override in configuration file. I'm on your side, just trying to test and provide some feedback. Sorry if I use a too strong language to speak about the problems. You're doing a truly great job. All the best, Dmitry. From onlyjob at member.fsf.org Tue Sep 18 08:39:32 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 18 Sep 2012 17:39:32 +1000 Subject: [winswitch] xpra 0.6.1 -- feedback In-Reply-To: <505723C3.3040202@nagafix.co.uk> References: <50536149.5020603@nagafix.co.uk> <201209172233.12180.onlyjob@member.fsf.org> <505723C3.3040202@nagafix.co.uk> Message-ID: <201209181739.33205.onlyjob@member.fsf.org> Hi Antoine, > I'll try to make a 1x1 window and see if it happens again. Looks like I can't reproduce the issue after Xdummy restart. Whatever it was it seems to be some kind of degradation in X server but not in xpra. This is all without changeset your recommended. I had this server running for weeks and I think it survived multiple "xpra upgrade" including some with new xpra versions. Thank you for your attention and sorry for the noise. Regards, Dmitry. From antoine at nagafix.co.uk Wed Sep 26 07:14:22 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 Sep 2012 13:14:22 +0700 Subject: [winswitch] [ANNOUNCE] stable updates and v0.7.0 beta Message-ID: <50629D3E.70709@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are important bug fixes for all stable branches. You can find a link to each version's release notes at the bottom of this email. v0.4.x and v0.5.x will not receive any more updates, please upgrade. Note: v0.3.10 drops support for servers older than v0.3.0, so we can start removing some of the really old crufty code in v0.7.0 The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine 0.3.10: https://www.xpra.org/svn/Xpra/tags/v0.3.x/src/NEWS 0.4.7 https://www.xpra.org/svn/Xpra/tags/v0.4.x/src/NEWS 0.5.5: https://www.xpra.org/svn/Xpra/tags/v0.5.x/src/NEWS 0.6.2: https://www.xpra.org/svn/Xpra/tags/v0.6.x/src/NEWS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBinT4ACgkQGK2zHPGK1ruQ4QCfcDtwOWJxcURbASd06kOtIz0x YsoAnA3UyqAoQyUeV6UC303ZeeLtLc5n =TZEs -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Thu Sep 27 17:30:49 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 27 Sep 2012 23:30:49 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.6.3 (stable) and new 0.7.0 (beta) Message-ID: <50647F39.6080602@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are only a few bug fixes, but they were important enough to warrant an update just 2 days after the previous release: * fix memory leak in server after client disconnection * fix launcher: clear socket timeout once connected and add missing options * fix potential bug in network code (prevent disconnection) * enable auto-refresh by default since we now use a lossy encoder by default The 0.7.0 release is getting closer and you can find a Mac OS x86 DMG and an Android APK as well as the usual RPMs and DEBs in the beta area: https://xpra.org/beta/ The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBkfzkACgkQGK2zHPGK1rtt1wCfa64QTTEVPLtbgFy315KEj+3L JLIAn2NjMWNr9JJemKdWqDF1DK/WBifB =/hzZ -----END PGP SIGNATURE-----