From nick at sqrt.co.uk Sun Mar 3 12:26:07 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sun, 3 Mar 2013 12:26:07 +0000 Subject: [winswitch] Reducing the colour depth (client side) Message-ID: Hi, Is it possible to reduce the colour depth client side when performing xpra attach? I'm attempting to use xpra over a 3G modem link where the X server is 140ms away. For a while, I've been using a VNC setup in exactly this way and found that reducing the colour from 24bits to 8bits had a considerable impact on usability. Xvfb has a -pixdepths option, which appears to be a list of supported colour depths. I just would like to get the client to allow the choice to be determined at connection time. Regards, Nick. From antoine at nagafix.co.uk Mon Mar 4 09:00:41 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 04 Mar 2013 16:00:41 +0700 Subject: [winswitch] Reducing the colour depth (client side) In-Reply-To: References: Message-ID: <513462B9.2080902@nagafix.co.uk> Hi Nick, xpra is a compositing window manager, and AFAIK this requires 24bpp or higher. I've tried launching Xvfb/Xdummy with 8bpp and Composite gets turned off. The -pixdepths switch does not help here. FYI: xpra seems to crash rather than exit gracefully, but that's another problem. As for achieving bandwidth savings by reducing the colour depth, x264 and vpx encodings use colour subsampling when the quality is lowered (switching from 4:4:4 to 4:2:2 and 4:2:0), this is in the chroma+luma space rather than plain RGB, but it does save about 50% on image size. Also note that newer encodings (x264, webp, etc) are vastly superior to the encodings found in VNC, so the bandwidth usage should already be much lower (even without colour subsampling). If you find that the quality/bandwidth/framerate/latency isn't good enough for you use case, let me know - it is quite possible that recent versions have focused a little bit too much on the LAN usage scenario.. Cheers Antoine On 03/03/2013 07:26 PM, Nick Burrett wrote: > Hi, > > Is it possible to reduce the colour depth client side when performing > xpra attach? > > I'm attempting to use xpra over a 3G modem link where the X server is > 140ms away. For a while, I've been using a VNC setup in exactly this > way and found that reducing the colour from 24bits to 8bits had a > considerable impact on usability. > > Xvfb has a -pixdepths option, which appears to be a list of supported > colour depths. I just would like to get the client to allow the > choice to be determined at connection time. > > Regards, > > Nick. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From nick at sqrt.co.uk Mon Mar 4 10:42:56 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Mon, 4 Mar 2013 10:42:56 +0000 Subject: [winswitch] Reducing the colour depth (client side) In-Reply-To: <513462B9.2080902@nagafix.co.uk> References: <513462B9.2080902@nagafix.co.uk> Message-ID: On 4 March 2013 09:00, Antoine Martin wrote: > Hi Nick, > > xpra is a compositing window manager, and AFAIK this requires 24bpp or > higher. I've tried launching Xvfb/Xdummy with 8bpp and Composite gets > turned off. The -pixdepths switch does not help here. FYI: xpra seems to > crash rather than exit gracefully, but that's another problem. > > As for achieving bandwidth savings by reducing the colour depth, x264 > and vpx encodings use colour subsampling when the quality is lowered > (switching from 4:4:4 to 4:2:2 and 4:2:0), this is in the chroma+luma > space rather than plain RGB, but it does save about 50% on image size. > Also note that newer encodings (x264, webp, etc) are vastly superior to > the encodings found in VNC, so the bandwidth usage should already be > much lower (even without colour subsampling). Alright, that makes sense. My gnome-terminal data transfer showed as 420Mbytes for around 6 hours of operation (using x264). I'll have a go at tuning the quality some more and extend the time between full window refreshes. I wonder if there's some efficiency to be gained by pre-processing the image before compression (at the expense of quality) -- perhaps by masking out the bottom 3 bits of R, G and B values so that the compressors don't have to try to handle subtle colour variations. > > If you find that the quality/bandwidth/framerate/latency isn't good > enough for you use case, let me know - it is quite possible that recent > versions have focused a little bit too much on the LAN usage scenario.. It's not great at the moment -- it can take 2-3 seconds to switch a tab in gnome-terminal, for example. But I'd rather ensure that I've exhausted my client option settings first. Regards, Nick > > > On 03/03/2013 07:26 PM, Nick Burrett wrote: >> Hi, >> >> Is it possible to reduce the colour depth client side when performing >> xpra attach? >> >> I'm attempting to use xpra over a 3G modem link where the X server is >> 140ms away. For a while, I've been using a VNC setup in exactly this >> way and found that reducing the colour from 24bits to 8bits had a >> considerable impact on usability. >> >> Xvfb has a -pixdepths option, which appears to be a list of supported >> colour depths. I just would like to get the client to allow the >> choice to be determined at connection time. >> >> Regards, >> >> Nick. >> _______________________________________________ >> 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 antoine at nagafix.co.uk Mon Mar 4 10:55:25 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 04 Mar 2013 17:55:25 +0700 Subject: [winswitch] Reducing the colour depth (client side) In-Reply-To: References: <513462B9.2080902@nagafix.co.uk> Message-ID: <51347D9D.4060505@nagafix.co.uk> On 03/04/2013 05:42 PM, Nick Burrett wrote: > On 4 March 2013 09:00, Antoine Martin wrote: >> Hi Nick, >> >> xpra is a compositing window manager, and AFAIK this requires 24bpp or >> higher. I've tried launching Xvfb/Xdummy with 8bpp and Composite gets >> turned off. The -pixdepths switch does not help here. FYI: xpra seems to >> crash rather than exit gracefully, but that's another problem. >> >> As for achieving bandwidth savings by reducing the colour depth, x264 >> and vpx encodings use colour subsampling when the quality is lowered >> (switching from 4:4:4 to 4:2:2 and 4:2:0), this is in the chroma+luma >> space rather than plain RGB, but it does save about 50% on image size. >> Also note that newer encodings (x264, webp, etc) are vastly superior to >> the encodings found in VNC, so the bandwidth usage should already be >> much lower (even without colour subsampling). > > Alright, that makes sense. My gnome-terminal data transfer showed as > 420Mbytes for around 6 hours of operation (using x264). I'll have a > go at tuning the quality some more and extend the time between full > window refreshes. > > I wonder if there's some efficiency to be gained by pre-processing the > image before compression (at the expense of quality) -- perhaps by > masking out the bottom 3 bits of R, G and B values so that the > compressors don't have to try to handle subtle colour variations. > >> >> If you find that the quality/bandwidth/framerate/latency isn't good >> enough for you use case, let me know - it is quite possible that recent >> versions have focused a little bit too much on the LAN usage scenario.. > > It's not great at the moment -- it can take 2-3 seconds to switch a > tab in gnome-terminal, for example. But I'd rather ensure that I've > exhausted my client option settings first. 2 to 3 seconds is way too high, I doubt you can find enough options to lower that enough to make it bearable. There is a lot of information for debugging such problems here: https://www.xpra.org/trac/wiki/WindowRefresh#Debugging Let me know what you find and I can make sure this gets auto-tuned properly. Cheers Antoine > > Regards, > > Nick > >> >> >> On 03/03/2013 07:26 PM, Nick Burrett wrote: >>> Hi, >>> >>> Is it possible to reduce the colour depth client side when performing >>> xpra attach? >>> >>> I'm attempting to use xpra over a 3G modem link where the X server is >>> 140ms away. For a while, I've been using a VNC setup in exactly this >>> way and found that reducing the colour from 24bits to 8bits had a >>> considerable impact on usability. >>> >>> Xvfb has a -pixdepths option, which appears to be a list of supported >>> colour depths. I just would like to get the client to allow the >>> choice to be determined at connection time. >>> >>> Regards, >>> >>> Nick. >>> _______________________________________________ >>> 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 antoine at nagafix.co.uk Wed Mar 6 18:17:06 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 07 Mar 2013 01:17:06 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.8.8 critical bugs Message-ID: <51378822.7010400@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This stable update fixes some critical bugs: * fix server deadlock on dead connections * fix compatibility with older versions of Python * fix sound capture script usage via command line * fix screen number preserve code * fix error in logs in shadow mode Although most of the fixes are server-side, the MS Windows and OSX installers have also been updated. 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.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3iCIACgkQGK2zHPGK1rtw1ACfRGAbTDTlLP9Elu8mPCIj7+05 QTsAniW2Sxkngkw+rw6zIUgkWuXqn6cj =pxlp -----END PGP SIGNATURE----- From RCunningham at nsmsurveillance.com Wed Mar 6 23:18:11 2013 From: RCunningham at nsmsurveillance.com (Cunningham, Robert) Date: Wed, 6 Mar 2013 23:18:11 +0000 Subject: [winswitch] Winswitch server on a headless system? Message-ID: <8D5812289502B448AD36E6780A069B8D011C2B5FA5@ashexcmb01.corp.solutionpoint-intl.com> I have a bunch of quick'n'dirty Python/Tkinter apps designed to test instrumentation/m2m protocols on various platforms (Win7/Mac/Linux, x86/ARM). Python/Tkinter is ideal for this, but now I need to run the apps on a headless Ubuntu (quantal) ARM (arm-hf) system, with the GUI shown remotely. >From a Linux remote system, I login via "ssh -Y" and start the app from the command line. I do the same thing from Win7 after installing the Cygwin Xserver. I'd like to have a "one-click" approach for others who would like to run the remote test apps, but don't (and shouldn't) know a thing about ssh or X11. I'd like it to be as easy as launching a local program, or opening a web page from a shortcut. Is this a good job for WinSwitch? If so, any hints before I dive in? TIA, -BobC From antoine at nagafix.co.uk Thu Mar 7 04:04:32 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 07 Mar 2013 11:04:32 +0700 Subject: [winswitch] Winswitch server on a headless system? In-Reply-To: <8D5812289502B448AD36E6780A069B8D011C2B5FA5@ashexcmb01.corp.solutionpoint-intl.com> References: <8D5812289502B448AD36E6780A069B8D011C2B5FA5@ashexcmb01.corp.solutionpoint-intl.com> Message-ID: <513811D0.9070101@nagafix.co.uk> On 03/07/2013 06:18 AM, Cunningham, Robert wrote: > I have a bunch of quick'n'dirty Python/Tkinter apps designed to test instrumentation/m2m protocols on various platforms (Win7/Mac/Linux, x86/ARM). Python/Tkinter is ideal for this, but now I need to run the apps on a headless Ubuntu (quantal) ARM (arm-hf) system, with the GUI shown remotely. > > From a Linux remote system, I login via "ssh -Y" and start the app from the command line. I do the same thing from Win7 after installing the Cygwin Xserver. > > I'd like to have a "one-click" approach for others who would like to run the remote test apps, but don't (and shouldn't) know a thing about ssh or X11. I'd like it to be as easy as launching a local program, or opening a web page from a shortcut. > > Is this a good job for WinSwitch? > > If so, any hints before I dive in? Winswitch can do this, and starting with version 0.9.0 xpra can do this too: xpra start ssh:HOST:DISPLAY --start-child=yourcommand With xpra, you still have to choose a free display number, whereas winswitch will find one for you. Best thing is to try it out and see what works best. Cheers Antoine > > > TIA, > > -BobC > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From troycauble at gmail.com Thu Mar 7 04:23:14 2013 From: troycauble at gmail.com (Troy Cauble) Date: Wed, 6 Mar 2013 23:23:14 -0500 Subject: [winswitch] Winswitch server on a headless system? In-Reply-To: <8D5812289502B448AD36E6780A069B8D011C2B5FA5@ashexcmb01.corp.solutionpoint-intl.com> References: <8D5812289502B448AD36E6780A069B8D011C2B5FA5@ashexcmb01.corp.solutionpoint-intl.com> Message-ID: > I'd like to have a "one-click" approach for others who would like to run the remote test apps, but don't (and shouldn't) know a thing about ssh or X11. I'd like it to be as easy as launching a local program, or opening a web page from a shortcut. Personally, I prefer using just xpra instead of winswitch. I have a small number of shell scripts like the one below, with the three initial settings changed. My client is OSX, my server Ubuntu. -troy #!/bin/sh RDISPLAY=111 RAPP=calibre RHOST=myhome.no-ip.com ROUT=`basename $RAPP`.out ssh $RHOST xpra -d all start :$RDISPLAY --start-child="$RAPP" --exit-with-children cd / /Applications/Window-Switch.app/Contents/Helpers/xpra -d all attach ssh:$RHOST:$RDISPLAY > $HOME/.xpra/client.$RDISPLAY.output 2>&1 From totaam at gmail.com Thu Mar 7 04:31:46 2013 From: totaam at gmail.com (Antoine Martin) Date: Thu, 7 Mar 2013 11:31:46 +0700 Subject: [winswitch] Winswitch server on a headless system? In-Reply-To: References: <8D5812289502B448AD36E6780A069B8D011C2B5FA5@ashexcmb01.corp.solutionpoint-intl.com> Message-ID: On Thu, Mar 7, 2013 at 11:23 AM, Troy Cauble wrote: > > I'd like to have a "one-click" approach for others who would like to run > the remote test apps, but don't (and shouldn't) know a thing about ssh or > X11. I'd like it to be as easy as launching a local program, or opening a > web page from a shortcut. > > Personally, I prefer using just xpra instead of winswitch. I have a > small number of shell scripts like the one below, with the three > initial settings changed. My client is OSX, my server Ubuntu. > FYI: there are OSX Xpra DMGs now, these are kept more up to date than the winswitch one you seem to be using. http://xpra.org/dists/osx/x86/ Antoine > > -troy > > > #!/bin/sh > > RDISPLAY=111 > RAPP=calibre > RHOST=myhome.no-ip.com > > ROUT=`basename $RAPP`.out > > ssh $RHOST xpra -d all start :$RDISPLAY --start-child="$RAPP" > --exit-with-children > > cd / > /Applications/Window-Switch.app/Contents/Helpers/xpra -d all attach > ssh:$RHOST:$RDISPLAY > $HOME/.xpra/client.$RDISPLAY.output 2>&1 > _______________________________________________ > 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 Sat Mar 16 14:35:03 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 16 Mar 2013 21:35:03 +0700 Subject: [winswitch] testing required: OpenGL client rendering Message-ID: <51448317.20209@nagafix.co.uk> Hi, The OpenGL client rendering has been enabled again, and this time it looks like it should work in almost all cases (the "nouveau" driver on Linux is blacklisted however - and OSX is unlikely to be supported). Please give it a whirl and report any display visual artifacts / bugs so that the 0.9.0 release can include it enabled by default, more details here: http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes Updated beta packages here: http://xpra.org/beta/ Thanks Antoine From ndbecker2 at gmail.com Sat Mar 16 19:45:17 2013 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 16 Mar 2013 15:45:17 -0400 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: <51448317.20209@nagafix.co.uk> References: <51448317.20209@nagafix.co.uk> Message-ID: It's much more convenient for me to use the fedora rpm package. If you provided betas in this form, I'd be more motivated to try them. google-chrome does this by providing a choice of: google-chrome-stable google-chrome-beta google-chrome-unstable On Sat, Mar 16, 2013 at 10:35 AM, Antoine Martin wrote: > Hi, > > The OpenGL client rendering has been enabled again, and this time it > looks like it should work in almost all cases (the "nouveau" driver on > Linux is blacklisted however - and OSX is unlikely to be supported). > Please give it a whirl and report any display visual artifacts / bugs so > that the 0.9.0 release can include it enabled by default, more details > here: > http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > Updated beta packages here: > http://xpra.org/beta/ > > Thanks > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From michael at klitgaard.dk Tue Mar 19 14:01:42 2013 From: michael at klitgaard.dk (Michael Klitgaard) Date: Tue, 19 Mar 2013 15:01:42 +0100 Subject: [winswitch] Installing on CentOS 6.3 Message-ID: Hello, I'm trying to install winswitch on my frontend, which runs Rocks Clusters 6.1 (rocksclusters.org). The underlaying OS is CentOS 6.3, and I'm trying to follow the guide: http://winswitch.org/downloads/rpm-repository.html?dist_select=CentOS6 In step 3, i did this: http://rpmfusion.org/Configuration Command Line Setup using rpm: RHEL 6 or compatible like CentOS: su -c 'yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/el/updates/6/i386/rpmfusion-free-release-6-1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/6/i386/rpmfusion-nonfree-release-6-1.noarch.rpm' And then tried yum install winswitch but it says: --> Finished Dependency Resolution You could try using --skip-broken to work around the problem ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Client) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Core) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Delta) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Ra) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(Time::HiRes) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(YAML::Any) The whole log is at the bottom of the email. What am I doing wrong? Sincerely Michael Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package winswitch.x86_64 0:0.12.18-2 will be installed --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nautilus-python for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: xpra for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-imaging for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-twisted for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 --> Running transaction check ---> Package winswitch.x86_64 0:0.12.18-2 will be installed --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nautilus-python for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-imaging for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-twisted for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 ---> Package xpra.x86_64 0:0.8.8-1.el6 will be installed --> Processing Dependency: python-imaging for package: xpra-0.8.8-1.el6.x86_64 --> Processing Dependency: xorg-x11-server-Xvfb for package: xpra-0.8.8-1.el6.x86_64 --> Running transaction check ---> Package winswitch.x86_64 0:0.12.18-2 will be installed --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nautilus-python for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-imaging for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-twisted for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 ---> Package xorg-x11-server-Xvfb.x86_64 0:1.10.6-1.1el6.3 will be installed --> Processing Dependency: xorg-x11-server-common >= 1.10.6-1.1el6.3 for package: xorg-x11-server-Xvfb-1.10.6-1.1el6.3.x86_64 ---> Package xpra.x86_64 0:0.8.8-1.el6 will be installed --> Processing Dependency: python-imaging for package: xpra-0.8.8-1.el6.x86_64 --> Running transaction check ---> Package winswitch.x86_64 0:0.12.18-2 will be installed --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nautilus-python for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-imaging for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: python-twisted for package: winswitch-0.12.18-2.x86_64 --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 ---> Package xorg-x11-server-common.x86_64 0:1.10.6-1.el6.centos will be updated ---> Package xorg-x11-server-common.x86_64 0:1.10.6-1.1el6.3 will be an update ---> Package xpra.x86_64 0:0.8.8-1.el6 will be installed --> Processing Dependency: python-imaging for package: xpra-0.8.8-1.el6.x86_64 --> Finished Dependency Resolution You could try using --skip-broken to work around the problem ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Client) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Core) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Delta) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Ra) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(Time::HiRes) foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(YAML::Any) From antoine at nagafix.co.uk Tue Mar 19 14:06:50 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 19 Mar 2013 21:06:50 +0700 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> Message-ID: <514870FA.3040407@nagafix.co.uk> On 03/17/2013 02:45 AM, Neal Becker wrote: > It's much more convenient for me to use the fedora rpm package. If you > provided betas in this form, I'd be more motivated to try them. > > google-chrome does this by providing a choice of: > > google-chrome-stable > google-chrome-beta > google-chrome-unstable Well, that would be good to have, unfortunately xpra is in python which makes it many orders of magnitude harder to allow side-by-side installation. And that would have to be done for source installs, RPMs, DEBs, etc.. On top of that, the installation would be so different from what we have now that it is likely to create more bugs than it is worth. I really don't have the time to dedicate to this task, sorry. Antoine > > > > > On Sat, Mar 16, 2013 at 10:35 AM, Antoine Martin > wrote: > > Hi, > > The OpenGL client rendering has been enabled again, and this time it > looks like it should work in almost all cases (the "nouveau" driver on > Linux is blacklisted however - and OSX is unlikely to be supported). > Please give it a whirl and report any display visual artifacts / bugs so > that the 0.9.0 release can include it enabled by default, more > details here: > http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > Updated beta packages here: > http://xpra.org/beta/ > > Thanks > Antoine > _______________________________________________ > 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 Tue Mar 19 14:09:46 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 19 Mar 2013 21:09:46 +0700 Subject: [winswitch] Installing on CentOS 6.3 In-Reply-To: References: Message-ID: <514871AA.5070203@nagafix.co.uk> On 03/19/2013 09:01 PM, Michael Klitgaard wrote: > Hello, > > I'm trying to install winswitch on my frontend, which runs Rocks > Clusters 6.1 (rocksclusters.org). > The underlaying OS is CentOS 6.3, and I'm trying to follow the guide: > > http://winswitch.org/downloads/rpm-repository.html?dist_select=CentOS6 > > In step 3, i did this: > http://rpmfusion.org/Configuration > > Command Line Setup using rpm: > RHEL 6 or compatible like CentOS: > su -c 'yum localinstall --nogpgcheck > http://download1.rpmfusion.org/free/el/updates/6/i386/rpmfusion-free-release-6-1.noarch.rpm > http://download1.rpmfusion.org/nonfree/el/updates/6/i386/rpmfusion-nonfree-release-6-1.noarch.rpm' > > And then tried yum install winswitch > > but it says: > --> Finished Dependency Resolution > You could try using --skip-broken to work around the problem > ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Client) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Core) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Delta) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Ra) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(Time::HiRes) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(YAML::Any) > > > The whole log is at the bottom of the email. > > What am I doing wrong? I don't know, but AFAICT this has absolutely nothing to do with winswitch. These are generic rpm errors for packages which are not required, or even used by winswitch at all. Cheers Antoine > > > Sincerely > Michael > > > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package winswitch.x86_64 0:0.12.18-2 will be installed > --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nautilus-python for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: xpra for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-imaging for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-twisted for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 > --> Running transaction check > ---> Package winswitch.x86_64 0:0.12.18-2 will be installed > --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nautilus-python for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-imaging for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-twisted for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 > ---> Package xpra.x86_64 0:0.8.8-1.el6 will be installed > --> Processing Dependency: python-imaging for package: xpra-0.8.8-1.el6.x86_64 > --> Processing Dependency: xorg-x11-server-Xvfb for package: > xpra-0.8.8-1.el6.x86_64 > --> Running transaction check > ---> Package winswitch.x86_64 0:0.12.18-2 will be installed > --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nautilus-python for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-imaging for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-twisted for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 > ---> Package xorg-x11-server-Xvfb.x86_64 0:1.10.6-1.1el6.3 will be installed > --> Processing Dependency: xorg-x11-server-common >= 1.10.6-1.1el6.3 > for package: xorg-x11-server-Xvfb-1.10.6-1.1el6.3.x86_64 > ---> Package xpra.x86_64 0:0.8.8-1.el6 will be installed > --> Processing Dependency: python-imaging for package: xpra-0.8.8-1.el6.x86_64 > --> Running transaction check > ---> Package winswitch.x86_64 0:0.12.18-2 will be installed > --> Processing Dependency: python-crypto for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: xfreerdp for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-pyasn1 for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nautilus-python for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: rdesktop for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-xlib for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-imaging for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: avahi-tools for package: winswitch-0.12.18-2.x86_64 > --> Processing Dependency: python-twisted for package: > winswitch-0.12.18-2.x86_64 > --> Processing Dependency: nx for package: winswitch-0.12.18-2.x86_64 > ---> Package xorg-x11-server-common.x86_64 0:1.10.6-1.el6.centos will be updated > ---> Package xorg-x11-server-common.x86_64 0:1.10.6-1.1el6.3 will be an update > ---> Package xpra.x86_64 0:0.8.8-1.el6 will be installed > --> Processing Dependency: python-imaging for package: xpra-0.8.8-1.el6.x86_64 > --> Finished Dependency Resolution > You could try using --skip-broken to work around the problem > ** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows: > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Client) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Core) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Delta) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(SVN::Ra) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(Time::HiRes) > foundation-git-1.7.11.4-0.x86_64 has missing requires of perl(YAML::Any) > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From ndbecker2 at gmail.com Tue Mar 19 18:18:36 2013 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 19 Mar 2013 14:18:36 -0400 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: <514870FA.3040407@nagafix.co.uk> References: <51448317.20209@nagafix.co.uk> <514870FA.3040407@nagafix.co.uk> Message-ID: I understand - I hope you know I appreciate all your efforts and I'm not asking for more free work. I have limited resources as well. I'm always nervous to switch back and forth between rpm and raw installs - can often cause problems. On Tue, Mar 19, 2013 at 10:06 AM, Antoine Martin wrote: > On 03/17/2013 02:45 AM, Neal Becker wrote: > > It's much more convenient for me to use the fedora rpm package. If you > > provided betas in this form, I'd be more motivated to try them. > > > > google-chrome does this by providing a choice of: > > > > google-chrome-stable > > google-chrome-beta > > google-chrome-unstable > Well, that would be good to have, unfortunately xpra is in python which > makes it many orders of magnitude harder to allow side-by-side > installation. And that would have to be done for source installs, RPMs, > DEBs, etc.. > On top of that, the installation would be so different from what we have > now that it is likely to create more bugs than it is worth. > I really don't have the time to dedicate to this task, sorry. > > Antoine > > > > > > > > > > > > > On Sat, Mar 16, 2013 at 10:35 AM, Antoine Martin > > wrote: > > > > Hi, > > > > The OpenGL client rendering has been enabled again, and this time it > > looks like it should work in almost all cases (the "nouveau" driver > on > > Linux is blacklisted however - and OSX is unlikely to be supported). > > Please give it a whirl and report any display visual artifacts / > bugs so > > that the 0.9.0 release can include it enabled by default, more > > details here: > > http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > > Updated beta packages here: > > http://xpra.org/beta/ > > > > Thanks > > Antoine > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > From thejunk.b at gmail.com Fri Mar 29 19:19:45 2013 From: thejunk.b at gmail.com (Randy) Date: Fri, 29 Mar 2013 15:19:45 -0400 Subject: [winswitch] xpra issuses Message-ID: <201303291519.45144.thejunk.b@gmail.com> I recently install winswitch on 2 debian wheezy machines and I am having issues getting apps to move to/from either of those 2 machines to the other tow machine on my local network. Two of the machines work together flawlessly, they were both install quite some time ago. The 2 most recient installs (last 3 months) don't work at all with the older installs. They also don't work with each other, although the apps will briefly open remotly before they close, but on the older installs they don't open at all. Only 1 machine in the older pair has an active firewall, neither of the newer do. The 2 machines that work together have these versions xpra 0.3.11+dfsg-1 winswitch 0.12.18-1 both are 64bit The 2 machines that will not work with any other xpra 0.8.8 winswitch 0.12.18-1 one is 64bit the other 32 I do not understand why the machines with the older version of xpra install have not been updated to 0.8.8 I am very patictular about keeping my machines updated. All the machines have the same repo for winswitch set up in sources.list so why has "apt-get upgrade" not udated xpra to 0.8.8 I have not pinned it and my default version is testing. I have looked at the logs in ~/.winswitch/...... and don't see any thing that tells me why it is failling. On the 2 machines that don't work the app will launch locally and remotely, but it will only display locally. It seams to be problem with xpra and not winswitch its self. I hesitate to force the update of xpra on the two older installs and have it brake that fuctionality untill I can get the other two working together. -- If it ain't broke tweek it From antoine at nagafix.co.uk Sat Mar 30 11:35:20 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 30 Mar 2013 12:35:20 +0100 Subject: [winswitch] xpra issuses In-Reply-To: <201303291519.45144.thejunk.b@gmail.com> References: <201303291519.45144.thejunk.b@gmail.com> Message-ID: <5156CDF8.70501@nagafix.co.uk> On 03/29/2013 08:19 PM, Randy wrote: > I recently install winswitch on 2 debian wheezy machines and I am having > issues getting apps to move to/from either of those 2 machines to the other > tow machine on my local network. Two of the machines work together > flawlessly, they were both install quite some time ago. The 2 most recient > installs (last 3 months) don't work at all with the older installs. They also > don't work with each other, although the apps will briefly open remotly before > they close, but on the older installs they don't open at all. Only 1 machine > in the older pair has an active firewall, neither of the newer do. > > The 2 machines that work together have these versions > xpra 0.3.11+dfsg-1 > winswitch 0.12.18-1 > both are 64bit xpra 0.3.x is broken and unsupported, and may well cause problems when connecting to/from newer versions. > The 2 machines that will not work with any other > xpra 0.8.8 > winswitch 0.12.18-1 > one is 64bit the other 32 > > I do not understand why the machines with the older version of xpra install > have not been updated to 0.8.8 I am very patictular about keeping my machines > updated. All the machines have the same repo for winswitch set up in > sources.list so why has "apt-get upgrade" not udated xpra to 0.8.8 I have not > pinned it and my default version is testing. Sorry, I have no idea. My test wheezy systems do get the updates. > I have looked at the logs in ~/.winswitch/...... and don't see any thing that > tells me why it is failling. > > On the 2 machines that don't work the app will launch locally and remotely, > but it will only display locally. It seams to be problem with xpra and not > winswitch its self. I hesitate to force the update of xpra on the two older > installs and have it brake that fuctionality untill I can get the other two > working together. Does the session terminate completely? (no longer shown in the tray menu) If so, then something is telling winswitch that the application has terminated and winswitch closes the session. The "session debugging" documentation may help you to solve this. Cheers Antoine From nick at sqrt.co.uk Sat Mar 30 13:25:27 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sat, 30 Mar 2013 13:25:27 +0000 Subject: [winswitch] Reducing the colour depth (client side) In-Reply-To: <51347D9D.4060505@nagafix.co.uk> References: <513462B9.2080902@nagafix.co.uk> <51347D9D.4060505@nagafix.co.uk> Message-ID: On 4 March 2013 10:55, Antoine Martin wrote: > On 03/04/2013 05:42 PM, Nick Burrett wrote: > > On 4 March 2013 09:00, Antoine Martin wrote: > >> Hi Nick, > >> > >> xpra is a compositing window manager, and AFAIK this requires 24bpp or > >> higher. I've tried launching Xvfb/Xdummy with 8bpp and Composite gets > >> turned off. The -pixdepths switch does not help here. FYI: xpra seems to > >> crash rather than exit gracefully, but that's another problem. > >> > >> As for achieving bandwidth savings by reducing the colour depth, x264 > >> and vpx encodings use colour subsampling when the quality is lowered > >> (switching from 4:4:4 to 4:2:2 and 4:2:0), this is in the chroma+luma > >> space rather than plain RGB, but it does save about 50% on image size. > >> Also note that newer encodings (x264, webp, etc) are vastly superior to > >> the encodings found in VNC, so the bandwidth usage should already be > >> much lower (even without colour subsampling). > > > > Alright, that makes sense. My gnome-terminal data transfer showed as > > 420Mbytes for around 6 hours of operation (using x264). I'll have a > > go at tuning the quality some more and extend the time between full > > window refreshes. > > > > I wonder if there's some efficiency to be gained by pre-processing the > > image before compression (at the expense of quality) -- perhaps by > > masking out the bottom 3 bits of R, G and B values so that the > > compressors don't have to try to handle subtle colour variations. > > > >> > >> If you find that the quality/bandwidth/framerate/latency isn't good > >> enough for you use case, let me know - it is quite possible that recent > >> versions have focused a little bit too much on the LAN usage scenario.. > > > > It's not great at the moment -- it can take 2-3 seconds to switch a > > tab in gnome-terminal, for example. But I'd rather ensure that I've > > exhausted my client option settings first. > 2 to 3 seconds is way too high, I doubt you can find enough options to > lower that enough to make it bearable. > There is a lot of information for debugging such problems here: > https://www.xpra.org/trac/wiki/WindowRefresh#Debugging > Let me know what you find and I can make sure this gets auto-tuned properly > After some experimentation, I found that the refresh delays of 2-3 seconds are really just down to the amount of data transferred to render a full window. For an x264 encoding, setting min-quality to 25 and auto-refresh-delay to 25+ seconds made a considerable difference to the usability of xpra over a 110ms+ latency link. I suspect that further improvements could be possible by supporting bframes, at a small cost to latency. For PNG encodings, I would have thought that changing the encoding in PIL_encode() from 'RGB' to 'P' (palette indexed) may reap some rewards, since the actual size of the resultant PNG image should be smaller the number of colours in the image to be encoded is small enough. For terminals/emacs etc, I'd imagine that there'd certainly be less than 256. Additionally setting optimize=1 on the im.save() call may help. I'll have to experiment with this next week > > > > > > > Regards, > > > > Nick > > > >> > >> > >> On 03/03/2013 07:26 PM, Nick Burrett wrote: > >>> Hi, > >>> > >>> Is it possible to reduce the colour depth client side when performing > >>> xpra attach? > >>> > >>> I'm attempting to use xpra over a 3G modem link where the X server is > >>> 140ms away. For a while, I've been using a VNC setup in exactly this > >>> way and found that reducing the colour from 24bits to 8bits had a > >>> considerable impact on usability. > >>> > >>> Xvfb has a -pixdepths option, which appears to be a list of supported > >>> colour depths. I just would like to get the client to allow the > >>> choice to be determined at connection time. > >>> > >>> Regards, > >>> > >>> Nick. > >>> _______________________________________________ > >>> 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 thejunk.b at gmail.com Sun Mar 31 02:57:11 2013 From: thejunk.b at gmail.com (Randy) Date: Sat, 30 Mar 2013 21:57:11 -0400 Subject: [winswitch] xpra issuses In-Reply-To: <5156CDF8.70501@nagafix.co.uk> References: <201303291519.45144.thejunk.b@gmail.com> <5156CDF8.70501@nagafix.co.uk> Message-ID: <201303302157.11866.thejunk.b@gmail.com> > > On the 2 machines that don't work the app will launch locally and > > remotely, but it will only display locally. It seams to be problem with > > xpra and not winswitch its self. I hesitate to force the update of xpra > > on the two older installs and have it brake that fuctionality untill I > > can get the other two working together. > > Does the session terminate completely? (no longer shown in the tray menu) > If so, then something is telling winswitch that the application has > terminated and winswitch closes the session. > The "session debugging" documentation may help you to solve this. > > Cheers > Antoine > The session only terminates remotly but remains avalible locally. I have noticed that the xpra icon does not show in the system tray, one for each session that is running. As per your instructions I will try to better understand the "session debugging" instructions so I can supply better info. Thanks Randy -- If it ain't broke tweek it From antoine at nagafix.co.uk Sun Mar 31 10:40:59 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 31 Mar 2013 11:40:59 +0200 Subject: [winswitch] Reducing the colour depth (client side) In-Reply-To: References: <513462B9.2080902@nagafix.co.uk> <51347D9D.4060505@nagafix.co.uk> Message-ID: <515804AB.3010007@nagafix.co.uk> On 03/30/2013 02:25 PM, Nick Burrett wrote: > On 4 March 2013 10:55, Antoine Martin wrote: > >> On 03/04/2013 05:42 PM, Nick Burrett wrote: >>> On 4 March 2013 09:00, Antoine Martin wrote: >>>> Hi Nick, >>>> >>>> xpra is a compositing window manager, and AFAIK this requires 24bpp or >>>> higher. I've tried launching Xvfb/Xdummy with 8bpp and Composite gets >>>> turned off. The -pixdepths switch does not help here. FYI: xpra seems to >>>> crash rather than exit gracefully, but that's another problem. >>>> >>>> As for achieving bandwidth savings by reducing the colour depth, x264 >>>> and vpx encodings use colour subsampling when the quality is lowered >>>> (switching from 4:4:4 to 4:2:2 and 4:2:0), this is in the chroma+luma >>>> space rather than plain RGB, but it does save about 50% on image size. >>>> Also note that newer encodings (x264, webp, etc) are vastly superior to >>>> the encodings found in VNC, so the bandwidth usage should already be >>>> much lower (even without colour subsampling). >>> Alright, that makes sense. My gnome-terminal data transfer showed as >>> 420Mbytes for around 6 hours of operation (using x264). I'll have a >>> go at tuning the quality some more and extend the time between full >>> window refreshes. >>> >>> I wonder if there's some efficiency to be gained by pre-processing the >>> image before compression (at the expense of quality) -- perhaps by >>> masking out the bottom 3 bits of R, G and B values so that the >>> compressors don't have to try to handle subtle colour variations. Possibly, this is a pretty narrow use case. Masking out before passing the data to colourspace conversion / x264 would be a little bit wasteful, ideally we could find a way to tell x264 to do this for us. I haven't found any option to allow us to do this yet. >>>> If you find that the quality/bandwidth/framerate/latency isn't good >>>> enough for you use case, let me know - it is quite possible that recent >>>> versions have focused a little bit too much on the LAN usage scenario.. >>> It's not great at the moment -- it can take 2-3 seconds to switch a >>> tab in gnome-terminal, for example. But I'd rather ensure that I've >>> exhausted my client option settings first. >> 2 to 3 seconds is way too high, I doubt you can find enough options to >> lower that enough to make it bearable. >> There is a lot of information for debugging such problems here: >> https://www.xpra.org/trac/wiki/WindowRefresh#Debugging >> Let me know what you find and I can make sure this gets auto-tuned properly >> > After some experimentation, I found that the refresh delays of 2-3 seconds > are really just down to the amount of data transferred to render a full > window. 2-3 seconds to render a window?? What application are we dealing with here? How many frames per second? Using png or rgb24 on a 100Mbit/s LAN, a 1080p frame can reach the client fast enough that you should not be able to notice any lag. Even low-powered clients can render it very quickly too (and even quicker in the 0.9.0 beta with OpenGL) And even with x264/vpx, on a fairly modern CPU the encoding should be fast enough (~60ms) > For an x264 encoding, setting min-quality to 25 and auto-refresh-delay to > 25+ seconds made a considerable difference to the usability of xpra over a > 110ms+ latency link. I suspect that further improvements could be possible > by supporting bframes, at a small cost to latency. OK, I'll see if I can lower the min-quality without getting too many complaints about "bad picture quality". As for auto-refresh and high latency, the code is supposed to take the latency into account to prevent the auto-refresh from kicking in too early, I'll have to verify that this works as it should. I can't imagine why you would ever need to set auto-refresh to values greater than a few seconds. B-frames could be used, but this would require some changes to ensure that we do send an I-frame no later than N milliseconds after it (with N calculated in a similar way to auto-refresh), by triggering an I-frame even if no changes have occurred. Not extremely difficult, but probably not worth the effort in most cases, and also likely to cause other problems similar to the one you encountered with auto-refresh. > For PNG encodings, I would have thought that changing the encoding in > PIL_encode() from 'RGB' to 'P' (palette indexed) may reap some rewards, > since the actual size of the resultant PNG image should be smaller the > number of colours in the image to be encoded is small enough. For > terminals/emacs etc, I'd imagine that there'd certainly be less than 256. > Additionally setting optimize=1 on the im.save() call may help. Indeed, PNG 8-bit would probably save a fair amount of bandwidth, this would need to be a separate encoding option from the current "png" option, I'll see what I can do for the next release: https://www.xpra.org/trac/ticket/305 I'm less convinced about the "optimize=1" option, having run hundreds of benchmarks comparing different releases I have always found the PNG encoding to be a CPU pig (and also pretty bad for latency), the optimize flag is unlikely to improve this situation, but I'll run some automated tests and see what the impact is. > I'll have to experiment with this next week Keep us posted! Thanks Antoine > > >> >> >>> Regards, >>> >>> Nick >>> >>>> >>>> On 03/03/2013 07:26 PM, Nick Burrett wrote: >>>>> Hi, >>>>> >>>>> Is it possible to reduce the colour depth client side when performing >>>>> xpra attach? >>>>> >>>>> I'm attempting to use xpra over a 3G modem link where the X server is >>>>> 140ms away. For a while, I've been using a VNC setup in exactly this >>>>> way and found that reducing the colour from 24bits to 8bits had a >>>>> considerable impact on usability. >>>>> >>>>> Xvfb has a -pixdepths option, which appears to be a list of supported >>>>> colour depths. I just would like to get the client to allow the >>>>> choice to be determined at connection time. >>>>> >>>>> Regards, >>>>> >>>>> Nick. >>>>> _______________________________________________ >>>>> 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 thejunk.b at gmail.com Sun Mar 31 19:23:25 2013 From: thejunk.b at gmail.com (Randy) Date: Sun, 31 Mar 2013 14:23:25 -0400 Subject: [winswitch] xpra issuses In-Reply-To: <5156CDF8.70501@nagafix.co.uk> References: <201303291519.45144.thejunk.b@gmail.com> <5156CDF8.70501@nagafix.co.uk> Message-ID: <201303311423.25114.thejunk.b@gmail.com> > > I do not understand why the machines with the older version of xpra > > install have not been updated to 0.8.8 I am very patictular about > > keeping my machines updated. All the machines have the same repo for > > winswitch set up in sources.list so why has "apt-get upgrade" not udated > > xpra to 0.8.8 I have not pinned it and my default version is testing. > > Sorry, I have no idea. > My test wheezy systems do get the updates. In synaptic I had distribution set to "testing" When I changed it to "Wheezy" it did grab the update. I was right, upgrading the two older install did break every thing. Now non of the work with each other. :( > > Does the session terminate completely? (no longer shown in the tray menu) > If so, then something is telling winswitch that the application has > terminated and winswitch closes the session. > The "session debugging" documentation may help you to solve this. > > Cheers > Antoine I have tried to enable debugging but I am not sure that I am doing it right. I edited the server config files. But i am still not getting a nx.log file as per the online docs. I have attached the server log files and config.txt from trying to remotly run a session. And also the client session log. Said session is an XPvm in virtual box that was automatically setup when I installed winswitch. Both system are 64bit. I have tried other sessions but they all do the same thing. Thanks Randy -- If it ain't broke tweek it -------------- next part -------------- # Window Switch Configuration File winswitch_software_version="0.12.18" # Identification: ID="e1bf0240e36541f896078e445f88084b" display=":68" name="Hardware Lister" user="kingbee" session_type="xpra" start_time=1364751249 # Connection point: host="127.0.0.1" port=15069 password="ce84aba48755480d922064284168700cd9d3cb48d2da48afbeb26be1ca513601" encrypted_password="" # ownership: owner="fd3e6af00f2b446190575907314235cb" actor="" # command details: command="su-to-root -X -c lshw-gtk" commands=[] arguments="" command_uuid="fb0d11cb7fe24f853aa70c2f923ecca8" # virtualization settings: full_desktop=False shared_desktop=False read_only=False shadowed_display="" # screen settings: screen_size="" # status: status="available" preload=False # sound options: can_export_sound=True can_import_sound=True can_clone_sound=False uses_sound_out=False uses_sound_in=False ipp_pid=-1 ipp_address="" xauth_file="" xauth_cookie="ce84aba48755480d922064284168700cd9d3cb48d2da48afbeb26be1ca513601" dbus_pid=30071 dbus_address="unix:abstract=/tmp/dbus-MZGUCTNRtM,guid=270b94fe0ea96dac579d9fe051587391" pulse_pid=30079 pulse_address="unix:/tmp/pulse-68/native" server_process_pid=30089 command_process_pid=-1 onexit_kill_pids["00-pulse"]=30079 onexit_kill_pids["99-server-process"]=30089 onexit_kill_pids["10-dbus"]=30071 onexit_kill_pids["40-gnome-keyring-daemon"]=30115 options["read_only"]=False options["mmap"]=True options["keyboard_sync"]=True options["clipboard"]=True options["encoding"]="" gst_export_plugin="pulsesrc" gst_export_plugin_options["server"]=unix:/tmp/pulse-68/native gst_import_plugin="pulsesink" gst_import_plugin_options["server"]=unix:/tmp/pulse-68/native gst_clone_plugin="" gst_clone_plugin_options={} From antoine at nagafix.co.uk Sun Mar 31 22:00:06 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 31 Mar 2013 23:00:06 +0200 Subject: [winswitch] xpra issuses In-Reply-To: <201303311423.25114.thejunk.b@gmail.com> References: <201303291519.45144.thejunk.b@gmail.com> <5156CDF8.70501@nagafix.co.uk> <201303311423.25114.thejunk.b@gmail.com> Message-ID: <5158A3D6.80607@nagafix.co.uk> > I have tried to enable debugging but I am not sure that I am doing it right. > I edited the server config files. But i am still not getting a nx.log file as > per the online docs. Wait, ... are you trying to use NX or Xpra sessions? Either way, there should not be any nx.log files, winswitch creates server log files in its per-session directory. > I have attached the server log files and config.txt from trying to remotly run a > session. And also the client session log. Said session is an XPvm in virtual > box that was automatically setup when I installed winswitch. Both system are > 64bit. The mailing list must have scrubbed some of the attachments. BTW, please subscribe to the list so I don't have to login and forward your messages individually. VirtualBox sessions use VNC, so that's yet another protocol.. > I have tried other sessions but they all do the same thing. I'll try testing on wheezy again as soon as I get a chance. Antoine > > Thanks > Randy > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From thejunk.b at gmail.com Sun Mar 31 23:15:39 2013 From: thejunk.b at gmail.com (Randy) Date: Sun, 31 Mar 2013 18:15:39 -0400 Subject: [winswitch] Fwd: Welcome to the "shifter-users" mailing list Message-ID: <201303311815.39570.thejunk.b@gmail.com> I have subscribed to the list. On the last post I did get a over size notice, some thing about >The reason it is being held: > > Message body is too big: 1669374 bytes with a limit of 40 KB I reattached the xpra.log but I think it is a different session -- If it ain't broke tweek it