From antoine at nagafix.co.uk Fri Oct 5 20:48:05 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 06 Oct 2012 02:48:05 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.6.4 (stable) and 0.7.0rc1 Message-ID: <506F3975.4000702@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are a number of important fixes in this release, full details below. The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine The older branches have also been updated: 0.3.11, 0.4.8 and 0.5.6. 0.6.4 release notes: * fix bencoder to properly handle dicts with non-string keys * fix swscale bug with windows that are too small by switch encoding * fix locking of video encoder resizing leading to missing video frames * fix lack of locking sometimes causing errors with "xpra info" * fix password file handling: exceptions and ignore carriage returns * prevent races during setup and cleanup of network connections * take shortcut if there is nothing to send -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBvOXUACgkQGK2zHPGK1rtrkACffzW9WXprJj9G7GFZ9EMi0PxI WrAAni4oTLWyKa/VKROrBHGL+5t5oneD =piZI -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Mon Oct 8 19:31:29 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 09 Oct 2012 01:31:29 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.7.0 Message-ID: <50731C01.4060203@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This new major release is our best release yet. There are many enhancement and many fixes all over the place. We now have much lower latency, support 'webp' picture compression, better keyboard mapping support, more stable, Android/Mac OSX installers, etc.. Mac OSX Xpra DMG image (x86 only): http://xpra.org/dists/osx/x86/Xpra.dmg Android APK (beta): http://xpra.org/dists/Android/Xpra.apk The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine Full release notes: * Mac DMG client download * Android APK download * fix "AltGr" key handling with MS Windows clients (and others) * fix crash with x264 encoding * fix crash with fast disappearing tooltip windows * avoid storing password in a file when using the launcher * many latency fixes and improvements: lower latency, better line congestion handling, etc * lower client latency: decompress pictures in a dedicated thread (including rgb24+zlib) * better launcher command feedback * better automatic compression heuristics * support for Xdummy on platforms with only a suid binary installed * support for 'webp' lossy picture encoding (better/faster than jpeg) * support fixed picture quality with x264, webp and jpeg (via command line and tray menu) * support for multiple "start-child" options in config files/command * more reliable auto-refresh * performance optimizations: caching results, avoid unnecessary video encoder re-initialization * faster re-connection (skip keyboard re-configuration) * better isolation of the virtual display process and child processes * show performance statistics graphs on session info dialog * start with compression enabled, even for initial packet * show more version and client information in logs and via "xpra info" * client launcher improvements: prevent logging conflict, add info * large source layout cleanup, compilation warnings fixed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBzHAEACgkQGK2zHPGK1rt5nwCeK+/0z7xVHO9+RLknIDA0HMMV cwwAn0+yuZRdAMpclvoo5BqplTeBAgVm =6n9M -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Mon Oct 8 19:31:36 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 09 Oct 2012 01:31:36 +0700 Subject: [winswitch] [ANNOUNCE] winswitch 0.12.17 Message-ID: <50731C08.5070808@nagafix.co.uk> Hi, Version 0.12.17 is available now: http://winswitch.org/downloads/ This minor update is timed to coincide with xpra 0.7.0 to bring the new features to MS Windows and Mac OSX users and only contains minor fixes. Cheers Antoine Full release notes: * fix for platforms without a known installer tool or packagekit * fix for long keyboard layout names with nx * fix for log rotation: don't log after rotating! * fix for xpra v0.7.0 log format * update debian packaging files * rename main unix display session using the user's full name * refactor most tests to use common code * build warnings, missing description strings, fewer errors in logs, etc From varvello at yahoo.com Wed Oct 10 23:10:54 2012 From: varvello at yahoo.com (Davide Varvello) Date: Wed, 10 Oct 2012 15:10:54 -0700 (PDT) Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> Message-ID: <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> ? >________________________________ > From: Davide Varvello >To: Antoine Martin >Sent: Thursday, October 11, 2012 12:10 AM >Subject: Main problems with xpra 0.7.0 and winswitch 0.12.17 > > >Hi Antoine, >I've a main issue witn xpra 0.7.0 (server on linux lucid) and winswitch 0.12.17 (client?on osx lion): >"ctrl" does not work. >"shift" does not work. >"a" key ?does not work. >Moreover mouse right click is extremely slow. > > >Finally >$> xpra version :100 > > >/usr/lib/pymodules/python2.6/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display >? warnings.warn(str(e), _gtk.Warning) >0.7.0 >Connection lost > > >and log file on display 100 is: > > >[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! >[dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! >/usr/lib/pymodules/python2.6/xpra/server_source.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead >? import md5 >2012-10-10 23:28:01,660 using notification forwarder: DBUSNotificationsForwarder(org.freedesktop.Notifications) >2012-10-10 23:28:01,670 xpra server version 0.7.0 >2012-10-10 23:28:01,753 xpra is ready. >2012-10-10 23:28:37,485 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >2012-10-10 23:28:37,488 Connection lost >2012-10-10 23:28:37,568 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >2012-10-10 23:28:37,575 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >2012-10-10 23:28:37,702 Connection lost >2012-10-10 23:28:37,713 Connection lost >2012-10-10 23:28:38,089 Lost WM selection, exiting >2012-10-10 23:28:38,089 xpra is terminating. >2012-10-10 23:28:38,116 xpra end of gtk.main(). >2012-10-10 23:28:38,116 upgrading: not cleaning up Xvfb or socket > > > > >Can you help me, please? >Thanks >?Davide >? > > > > > > > >>________________________________ >> From: Antoine Martin >>To: "shifter-users at lists.devloop.org.uk" >>Sent: Monday, October 8, 2012 8:31 PM >>Subject: [winswitch] [ANNOUNCE] xpra 0.7.0 >> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Hi, >> >>This new major release is our best release yet. >>There are many enhancement and many fixes all over the place. >>We now have much lower latency, support 'webp' picture compression, >>better keyboard mapping support, more stable, Android/Mac OSX >>installers, etc.. >> >>Mac OSX Xpra DMG image (x86 only): >>http://xpra.org/dists/osx/x86/Xpra.dmg >>Android APK (beta): >>http://xpra.org/dists/Android/Xpra.apk >> >>The source: >>https://xpra.org/src/ >>Binaries/repositories: >>https://winswitch.org/downloads/ >>Direct binary downloads: >>https://xpra.org/dists/ >> >>Cheers >>Antoine >> >>Full release notes: >>* Mac DMG client download >>* Android APK download >>* fix "AltGr" key handling with MS Windows clients (and others) >>* fix crash with x264 encoding >>* fix crash with fast disappearing tooltip windows >>* avoid storing password in a file when using the launcher >>* many latency fixes and improvements: lower latency, better line >>congestion handling, etc >>* lower client latency: decompress pictures in a dedicated thread >>(including rgb24+zlib) >>* better launcher command feedback >>* better automatic compression heuristics >>* support for Xdummy on platforms with only a suid binary installed >>* support for 'webp' lossy picture encoding (better/faster than jpeg) >>* support fixed picture quality with x264, webp and jpeg (via command >>line and tray menu) >>* support for multiple "start-child" options in config files/command >>* more reliable auto-refresh >>* performance optimizations: caching results, avoid unnecessary video >>encoder re-initialization >>* faster re-connection (skip keyboard re-configuration) >>* better isolation of the virtual display process and child processes >>* show performance statistics graphs on session info dialog >>* start with compression enabled, even for initial packet >>* show more version and client information in logs and via "xpra info" >>* client launcher improvements: prevent logging conflict, add info >>* large source layout cleanup, compilation warnings fixed >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.12 (GNU/Linux) >>Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >> >>iEYEARECAAYFAlBzHAEACgkQGK2zHPGK1rt5nwCeK+/0z7xVHO9+RLknIDA0HMMV >>cwwAn0+yuZRdAMpclvoo5BqplTeBAgVm >>=6n9M >>-----END PGP SIGNATURE----- >>_______________________________________________ >>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 Oct 11 11:41:38 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 11 Oct 2012 17:41:38 +0700 Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> Message-ID: <5076A262.2080000@nagafix.co.uk> Hi Davide, > Hi Antoine, > I've a main issue witn xpra 0.7.0 (server on linux lucid) FYI: support for lucid will be dropped soon, as it is just too old to bother.. > and winswitch 0.12.17 (client on osx lion): > "ctrl" does not work. > "shift" does not work. > "a" key does not work. Hah, back to that old 'a' key problem... sorry about that. In fixing "AltGr" for many users (mostly MS Windows), it seems we've made it worse for Mac OS X.. Will fix ASAP and build new DMGs. > Moreover mouse right click is extremely slow. It isn't here. What application are you using? Is it just the right click? > Finally > $> xpra version :100 > > /usr/lib/pymodules/python2.6/gtk-2.0/gtk/__init__.py:57: GtkWarning: > could not open display That's fixed now - thanks for reporting this. http://xpra.org/trac/changeset/1912 > warnings.warn(str(e), _gtk.Warning) > 0.7.0 > Connection lost > > and log file on display 100 is: > > [dix] Could not init font path element > /usr/share/fonts/X11/cyrillic, removing from list! > [dix] Could not init font path element > /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! > /usr/lib/pymodules/python2.6/xpra/server_source.py:12: > DeprecationWarning: the md5 module is deprecated; use hashlib instead > import md5 This md5 deprecation warning is fixed already: http://xpra.org/trac/changeset/1878 > 2012-10-10 23:28:01,660 using notification forwarder: > DBUSNotificationsForwarder(org.freedesktop.Notifications) > 2012-10-10 23:28:01,670 xpra server version 0.7.0 > 2012-10-10 23:28:01,753 xpra is ready. > 2012-10-10 23:28:37,485 New connection received: > SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-10 23:28:37,488 Connection lost > 2012-10-10 23:28:37,568 New connection received: > SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-10 23:28:37,575 New connection received: > SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-10 23:28:37,702 Connection lost > 2012-10-10 23:28:37,713 Connection lost > 2012-10-10 23:28:38,089 Lost WM selection, exiting Looks like you are running another window manager (or "xpra upgrade"?) on this display so Xpra exited. This is normal, you can only have one window manager at a time. Cheers Antoine > 2012-10-10 23:28:38,089 xpra is terminating. > 2012-10-10 23:28:38,116 xpra end of gtk.main(). > 2012-10-10 23:28:38,116 upgrading: not cleaning up Xvfb or socket > > > Can you help me, please? > Thanks > Davide > > > > > ------------------------------------------------------------------------ > *From:* Antoine Martin > *To:* "shifter-users at lists.devloop.org.uk" > > *Sent:* Monday, October 8, 2012 8:31 PM > *Subject:* [winswitch] [ANNOUNCE] xpra 0.7.0 > > Hi, > > This new major release is our best release yet. > There are many enhancement and many fixes all over the place. > We now have much lower latency, support 'webp' picture compression, > better keyboard mapping support, more stable, Android/Mac OSX > installers, etc.. > > Mac OSX Xpra DMG image (x86 only): > http://xpra.org/dists/osx/x86/Xpra.dmg > Android APK (beta): > http://xpra.org/dists/Android/Xpra.apk > > The source: > https://xpra.org/src/ > Binaries/repositories: > https://winswitch.org/downloads/ > Direct binary downloads: > https://xpra.org/dists/ > > Cheers > Antoine > > Full release notes: > * Mac DMG client download > * Android APK download > * fix "AltGr" key handling with MS Windows clients (and others) > * fix crash with x264 encoding > * fix crash with fast disappearing tooltip windows > * avoid storing password in a file when using the launcher > * many latency fixes and improvements: lower latency, better line > congestion handling, etc > * lower client latency: decompress pictures in a dedicated thread > (including rgb24+zlib) > * better launcher command feedback > * better automatic compression heuristics > * support for Xdummy on platforms with only a suid binary installed > * support for 'webp' lossy picture encoding (better/faster than > jpeg) > * support fixed picture quality with x264, webp and jpeg (via > command > line and tray menu) > * support for multiple "start-child" options in config files/command > * more reliable auto-refresh > * performance optimizations: caching results, avoid unnecessary > video > encoder re-initialization > * faster re-connection (skip keyboard re-configuration) > * better isolation of the virtual display process and child > processes > * show performance statistics graphs on session info dialog > * start with compression enabled, even for initial packet > * show more version and client information in logs and via "xpra > info" > * client launcher improvements: prevent logging conflict, add info > * large source layout cleanup, compilation warnings fixed > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > From varvello at yahoo.com Thu Oct 11 13:13:11 2012 From: varvello at yahoo.com (Davide Varvello) Date: Thu, 11 Oct 2012 05:13:11 -0700 (PDT) Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <5076A262.2080000@nagafix.co.uk> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> Message-ID: <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> Hi Antoine, > >Hi Davide, > >>? ???Hi Antoine, >>? ???I've a main issue witn xpra 0.7.0 (server on linux lucid) >FYI: support for lucid will be dropped soon, as it is just too old to >bother.. ok, tx > >> and winswitch 0.12.17 (client on osx lion): >>? ???"ctrl" does not work. >>? ???"shift" does not work. >>? ???"a" key? does not work. >Hah, back to that old 'a' key problem... sorry about that. >In fixing "AltGr" for many users (mostly MS Windows), it seems we've >made it worse for Mac OS X.. >Will fix ASAP and build new DMGs. > Thanks >>? ???Moreover mouse right click is extremely slow. >It isn't here. What application are you using? >Is it just the right click? > It seemed to me. I tried 0.7.0 for a such limited amount of time because it was useless to me, I couldn't do anything with keyboard so I tried to copy and paste via right click and I noticed it was very slow. Then I rollbacked to xpra version 0.6.2 but I kept ?winswitch (v 0.12.17) client on osx lion and it's fine >>? ???Finally >>? ???$> xpra version :100 >> >>? ???/usr/lib/pymodules/python2.6/gtk-2.0/gtk/__init__.py:57: GtkWarning: >>? ???could not open display >That's fixed now - thanks for reporting this. >http://xpra.org/trac/changeset/1912 >>? ? ???warnings.warn(str(e), _gtk.Warning) >>? ???0.7.0 >>? ???Connection lost >> >>? ???and log file on display 100 is: >> >>? ???[dix] Could not init font path element >>? ???/usr/share/fonts/X11/cyrillic, removing from list! >>? ???[dix] Could not init font path element >>? ???/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! >>? ???/usr/lib/pymodules/python2.6/xpra/server_source.py:12: >>? ???DeprecationWarning: the md5 module is deprecated; use hashlib instead >>? ? ???import md5 >This md5 deprecation warning is fixed already: >http://xpra.org/trac/changeset/1878 > >>? ???2012-10-10 23:28:01,660 using notification forwarder: >>? ???DBUSNotificationsForwarder(org.freedesktop.Notifications) >>? ???2012-10-10 23:28:01,670 xpra server version 0.7.0 >>? ???2012-10-10 23:28:01,753 xpra is ready. >>? ???2012-10-10 23:28:37,485 New connection received: >>? ???SocketConnection(/home/davide/.xpra/machine-100 - ) >>? ???2012-10-10 23:28:37,488 Connection lost >>? ???2012-10-10 23:28:37,568 New connection received: >>? ???SocketConnection(/home/davide/.xpra/machine-100 - ) >>? ???2012-10-10 23:28:37,575 New connection received: >>? ???SocketConnection(/home/davide/.xpra/machine-100 - ) >>? ???2012-10-10 23:28:37,702 Connection lost >>? ???2012-10-10 23:28:37,713 Connection lost >>? ???2012-10-10 23:28:38,089 Lost WM selection, exiting >Looks like you are running another window manager (or "xpra upgrade"?) >on this display so Xpra exited. This is normal, you can only have one >window manager at a time. > Tell me more, how can I spot it? Anyway following is the log I have now using 0.6.2: [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! 2012-10-11 07:47:35,895 using notification forwarder: DBUSNotificationsForwarder(org.freedesktop.Notifications) 2012-10-11 07:47:35,895 xpra server version 0.6.2 2012-10-11 07:47:35,926 xpra is ready. 2012-10-11 07:47:45,404 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) 2012-10-11 07:47:45,552 Connection lost 2012-10-11 07:48:27,072 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) 2012-10-11 07:48:27,073 Connection lost 2012-10-11 07:48:27,148 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) 2012-10-11 07:48:27,150 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) 2012-10-11 07:48:27,283 Connection lost 2012-10-11 07:48:27,285 Connection lost 2012-10-11 07:48:27,711 Lost WM selection, exiting 2012-10-11 07:48:27,711 xpra is terminating. 2012-10-11 07:48:27,733 xpra end of gtk.main(). upgrading: not cleaning up Xvfb or socket Finally, just for your info, when I rollbacked to 0.6.2, apt forced me to revert?python-wimpiggy to 0.6.2, but probably?something was missing because /usr/bin/winswitch_server --daemon didn't started, so I followed your faq (http://winswitch.org/downloads/debian-repository.html?dist_select=lucid) and installed winswitch.? Cheers ?Davide >Cheers >Antoine > From antoine at nagafix.co.uk Thu Oct 11 13:26:11 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 11 Oct 2012 19:26:11 +0700 Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> Message-ID: <5076BAE3.9050307@nagafix.co.uk> (snip) >>> Moreover mouse right click is extremely slow. >> It isn't here. What application are you using? >> Is it just the right click? >> > > It seemed to me. I tried 0.7.0 for a such limited amount of time because it was useless to me, I couldn't do anything with keyboard so I tried to copy and paste via right click and I noticed it was very slow. OK, so it's not the actual right click that is slow but the clipboard lookup. What was the app you were testing with? Copying from one app to another? (there is no clipboard support on macos due to lack of a usable clipboard api on osx) > Then I rollbacked to xpra version 0.6.2 but I kept winswitch (v 0.12.17) client on osx lion and it's fine Good. (snip) >>> SocketConnection(/home/davide/.xpra/machine-100 - ) >>> 2012-10-10 23:28:37,702 Connection lost >>> 2012-10-10 23:28:37,713 Connection lost >>> 2012-10-10 23:28:38,089 Lost WM selection, exiting >> Looks like you are running another window manager (or "xpra upgrade"?) >> on this display so Xpra exited. This is normal, you can only have one >> window manager at a time. >> > > Tell me more, how can I spot it? You should be able to spot it with a simple process list, or using: DISPLAY:100 xlsclients I bet this is just another xpra instance doing an upgrade since you are using winswitch: it will capture all the xpra sessions it finds to make them available to you via winswitch. You can turn off this behaviour in .winswitch/server/protocols/xpra.conf by setting: capture_external_sessions=False Or stop winswitch when testing pure xpra sessions. > Anyway following is the log I have now using 0.6.2: > > [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! > [dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! > 2012-10-11 07:47:35,895 using notification forwarder: DBUSNotificationsForwarder(org.freedesktop.Notifications) > 2012-10-11 07:47:35,895 xpra server version 0.6.2 > 2012-10-11 07:47:35,926 xpra is ready. > 2012-10-11 07:47:45,404 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-11 07:47:45,552 Connection lost > 2012-10-11 07:48:27,072 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-11 07:48:27,073 Connection lost > 2012-10-11 07:48:27,148 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-11 07:48:27,150 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) > 2012-10-11 07:48:27,283 Connection lost > 2012-10-11 07:48:27,285 Connection lost > 2012-10-11 07:48:27,711 Lost WM selection, exiting > 2012-10-11 07:48:27,711 xpra is terminating. > 2012-10-11 07:48:27,733 xpra end of gtk.main(). > upgrading: not cleaning up Xvfb or socket > > Finally, just for your info, when I rollbacked to 0.6.2, apt forced me to revert python-wimpiggy to 0.6.2, but probably something was missing because /usr/bin/winswitch_server --daemon didn't started, so I followed your faq (http://winswitch.org/downloads/debian-repository.html?dist_select=lucid) and installed winswitch. Where did you install winswitch from previously? I haven't tested latest winswitch with xpra 0.6.2, it should work, but there are some debian packaging tricks in there so maybe that's the problem. Cheers Antoine > > Cheers > Davide > > >> Cheers >> Antoine >> From varvello at yahoo.com Thu Oct 11 13:46:22 2012 From: varvello at yahoo.com (Davide Varvello) Date: Thu, 11 Oct 2012 05:46:22 -0700 (PDT) Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <5076BAE3.9050307@nagafix.co.uk> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5076BAE3.9050307@nagafix.co.uk> Message-ID: <1349959582.21867.YahooMailNeo@web160106.mail.bf1.yahoo.com> >(snip) >>>>? ? ? Moreover mouse right click is extremely slow. >>> It isn't here. What application are you using? >>> Is it just the right click? >>> >> >> It seemed to me. I tried 0.7.0 for a such limited amount of time because it was useless to me, I couldn't do anything with keyboard so I tried to copy and paste via right click and I noticed it was very slow. >OK, so it's not the actual right click that is slow but the clipboard >lookup. What was the app you were testing with? Copying from one app to >another? (there is no clipboard support on macos due to lack of a usable >clipboard api on osx) No, I copied chars in the same app because shift and ctrl didn't work. I had to write "(" and I couldn't because shift had no effect so I copied from another (? > >> Then I rollbacked to xpra version 0.6.2 but I kept? winswitch (v 0.12.17) client on osx lion and it's fine >Good. > >(snip) >>>>? ? ? SocketConnection(/home/davide/.xpra/machine-100 - ) >>>>? ? ? 2012-10-10 23:28:37,702 Connection lost >>>>? ? ? 2012-10-10 23:28:37,713 Connection lost >>>>? ? ? 2012-10-10 23:28:38,089 Lost WM selection, exiting >>> Looks like you are running another window manager (or "xpra upgrade"?) >>> on this display so Xpra exited. This is normal, you can only have one >>> window manager at a time. >>> >> >> Tell me more, how can I spot it? >You should be able to spot it with a simple process list, or using: >DISPLAY:100 xlsclients DISPLAY:100 xlsclients returns "command not found" > >I bet this is just another xpra instance doing an upgrade since you are >using winswitch: it will capture all the xpra sessions it finds to make >them available to you via winswitch. >You can turn off this behaviour in .winswitch/server/protocols/xpra.conf >by setting: >capture_external_sessions=False > >Or stop winswitch when testing pure xpra sessions. > >> Anyway following is the log I have now using 0.6.2: >> >> [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! >> [dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! >> 2012-10-11 07:47:35,895 using notification forwarder: DBUSNotificationsForwarder(org.freedesktop.Notifications) >> 2012-10-11 07:47:35,895 xpra server version 0.6.2 >> 2012-10-11 07:47:35,926 xpra is ready. >> 2012-10-11 07:47:45,404 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >> 2012-10-11 07:47:45,552 Connection lost >> 2012-10-11 07:48:27,072 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >> 2012-10-11 07:48:27,073 Connection lost >> 2012-10-11 07:48:27,148 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >> 2012-10-11 07:48:27,150 New connection received: SocketConnection(/home/davide/.xpra/machine-100 - ) >> 2012-10-11 07:48:27,283 Connection lost >> 2012-10-11 07:48:27,285 Connection lost >> 2012-10-11 07:48:27,711 Lost WM selection, exiting >> 2012-10-11 07:48:27,711 xpra is terminating. >> 2012-10-11 07:48:27,733 xpra end of gtk.main(). >> upgrading: not cleaning up Xvfb or socket >> >> Finally, just for your info, when I rollbacked to 0.6.2, apt forced me to revert python-wimpiggy to 0.6.2, but probably something was missing because /usr/bin/winswitch_server --daemon didn't started, so I followed your faq (http://winswitch.org/downloads/debian-repository.html?dist_select=lucid) and installed winswitch.? >Where did you install winswitch from previously? I installed it a long time ago using the same instructions here?http://winswitch.org/downloads/debian-repository.html?dist_select=lucid Davide >I haven't tested latest winswitch with xpra 0.6.2, it should work, but >there are some debian packaging tricks in there so maybe that's the problem. > >Cheers >Antoine > > >> >> Cheers >>? Davide >> >> >>> Cheers >>> Antoine >>> > > > >? From antoine at nagafix.co.uk Thu Oct 11 14:08:12 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 11 Oct 2012 20:08:12 +0700 Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <1349959582.21867.YahooMailNeo@web160106.mail.bf1.yahoo.com> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5076BAE3.9050307@nagafix.co.uk> <1349959582.21867.YahooMailNeo@web160106.mail.bf1.yahoo.com> Message-ID: <5076C4BC.60408@nagafix.co.uk> (snip) > > No, I copied chars in the same app because shift and ctrl didn't work. I had to write "(" and I couldn't because shift had no effect so I copied from another ( OK, I will check this use case, it should work fast. What was the app that you were using? (snip) > > DISPLAY:100 xlsclients returns "command not found" A quick google search tells me debian packages this in "x11-utils" (snip) >>> >>> Finally, just for your info, when I rollbacked to 0.6.2, apt forced me to revert python-wimpiggy to 0.6.2, but probably something was missing because /usr/bin/winswitch_server --daemon didn't started, so I followed your faq (http://winswitch.org/downloads/debian-repository.html?dist_select=lucid) and installed winswitch. > >> Where did you install winswitch from previously? > I installed it a long time ago using the same instructions here http://winswitch.org/downloads/debian-repository.html?dist_select=lucid If you already installed the repo, doing it again should not make any difference.. Antoine (snip) From antoine at nagafix.co.uk Thu Oct 11 20:20:56 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Oct 2012 02:20:56 +0700 Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <5076C4BC.60408@nagafix.co.uk> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5076BAE3.9050307@nagafix.co.uk> <1349959582.21867.YahooMailNeo@web160106.mail.bf1.yahoo.com> <5076C4BC.60408@nagafix.co.uk> Message-ID: <50771C18.4040208@nagafix.co.uk> The problem with MacOSX keyboards losing the ability to use some modifiers (ie: Shift and/or Control) with 0.7.0 servers should be fixed in 0.7.1. Only an xpra server-side upgrade is needed, you can find beta packages with the fix here: http://winswitch.org/beta/ Please do let me know if this solves the problem for you so I can validate those changes more quickly and get the fix released sooner. Thanks Antoine PS: I am unable to reproduce the right-click clipboard slowness you reported, please provide mode details as requested earlier: which application, etc.. PS2: "AltGr" does not work with Mac OSX. On 10/11/2012 08:08 PM, Antoine Martin wrote: > (snip) >> >> No, I copied chars in the same app because shift and ctrl didn't work. I had to write "(" and I couldn't because shift had no effect so I copied from another ( > OK, I will check this use case, it should work fast. > What was the app that you were using? > > (snip) >> >> DISPLAY:100 xlsclients returns "command not found" > A quick google search tells me debian packages this in "x11-utils" > > (snip) >>>> >>>> Finally, just for your info, when I rollbacked to 0.6.2, apt forced me to revert python-wimpiggy to 0.6.2, but probably something was missing because /usr/bin/winswitch_server --daemon didn't started, so I followed your faq (http://winswitch.org/downloads/debian-repository.html?dist_select=lucid) and installed winswitch. >> >>> Where did you install winswitch from previously? >> I installed it a long time ago using the same instructions here http://winswitch.org/downloads/debian-repository.html?dist_select=lucid > If you already installed the repo, doing it again should not make any > difference.. > > Antoine > > (snip) > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From varvello at yahoo.com Fri Oct 12 08:00:57 2012 From: varvello at yahoo.com (Davide Varvello) Date: Fri, 12 Oct 2012 00:00:57 -0700 (PDT) Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <50771C18.4040208@nagafix.co.uk> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5076BAE3.9050307@nagafix.co.uk> <1349959582.21867.YahooMailNeo@web160106.mail.bf1.yahoo.com> <5076C4BC.60408@nagafix.co.uk> <50771C18.4040208@nagafix.co.uk> Message-ID: <1350025257.62753.YahooMailNeo@web160105.mail.bf1.yahoo.com> Hi Antoine ----- Original Message ----- > From: Antoine Martin > To: shifter-users at lists.devloop.org.uk > Cc: > Sent: Thursday, October 11, 2012 9:20 PM > Subject: Re: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 > >T he problem with MacOSX keyboards losing the ability to use some > modifiers (ie: Shift and/or Control) with 0.7.0 servers should be fixed > in 0.7.1. Only an xpra server-side upgrade is needed, you can find beta > packages with the fix here: > http://winswitch.org/beta/ > Please do let me know if this solves the problem for you so I can > validate those changes more quickly and get the fix released sooner. Probably I can put a glance on 0.7.1 in the weekend > > Thanks > Antoine > > PS: I am unable to reproduce the right-click clipboard slowness you > reported, please provide mode details as requested earlier: which > application, etc.. It's a smalltalk application. Basically instead of X11 forwarding I use xpra (http://www.asmalltalkbytheseaside.com/#remotedevelopmentonpharowithoutvnc) Cheers ?Davide > PS2: "AltGr" does not work with Mac OSX. > From onlyjob at member.fsf.org Fri Oct 12 08:42:23 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Fri, 12 Oct 2012 18:42:23 +1100 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles Message-ID: <201210121842.23716.onlyjob@member.fsf.org> Hi, Just reporting an interesting issue with 0.7.0: On Debian Wheezy some keys may stop working after switching to non-English keyboard. For example I switch from English using Alt+Shift and then back to English by pressing Alt+Shift again. This breaks keypad '*' key (letter and number keys work as expected). When I repeat Alt+Shift/Alt+Shift combination keypad '*' works again. In non-English mode Keypad '*' do not work at all. Although this is only of minor inconvenience I'm reporting as it may be a symptom of something more serious. Today I tried trunk r1944 but it is broken in regards to keyboard: it is not possible to switch to non-English layout using Alt+Shift. -- Regards, Dmitry. From antoine at nagafix.co.uk Fri Oct 12 08:50:01 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Oct 2012 14:50:01 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210121842.23716.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> Message-ID: <5077CBA9.5050206@nagafix.co.uk> On 10/12/2012 02:42 PM, Dmitry Smirnov wrote: > Hi, > > Just reporting an interesting issue with 0.7.0: > > On Debian Wheezy some keys may stop working after switching to non-English > keyboard. > For example I switch from English using Alt+Shift and then back to English by > pressing Alt+Shift again. This breaks keypad '*' key (letter and number keys > work as expected). > When I repeat Alt+Shift/Alt+Shift combination keypad '*' works again. > In non-English mode Keypad '*' do not work at all. The keyboard code is an endless source of pain, the only way of making it work with all configurations and platforms -if at all possible- would be to support the Xkb api rather than using "core" as we do at present. > Although this is only of minor inconvenience I'm reporting as it may be a > symptom of something more serious. It's a symptom of the X11 keyboard API being a major PITA to use. ;) > Today I tried trunk r1944 but it is broken in regards to keyboard: > it is not possible to switch to non-English layout using Alt+Shift. > Can you try the latest from the 0.7.x branch? I fear that the Mac OSX keyboard fix I have added there (present in trunk) might have had that effect. It would be best to know this before releasing this stable update. I would rather leave OSX broken then break something new.. Cheers Antoine From onlyjob at member.fsf.org Fri Oct 12 11:15:50 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Fri, 12 Oct 2012 21:15:50 +1100 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <5077CBA9.5050206@nagafix.co.uk> References: <201210121842.23716.onlyjob@member.fsf.org> <5077CBA9.5050206@nagafix.co.uk> Message-ID: <201210122115.50778.onlyjob@member.fsf.org> On Fri, 12 Oct 2012 18:50:01 Antoine Martin wrote: > Can you try the latest from the 0.7.x branch? I fear that the Mac OSX > keyboard fix I have added there (present in trunk) might have had that > effect. It would be best to know this before releasing this stable > update. I would rather leave OSX broken then break something new.. Tried minutes ago -- it's the same thing as in trunk i.e. I can't switch to non-English layout using Alt+Shift. Sorry. By the way why are you using tag-branches instead of normal branches? ;) -- Regards, Dmitry. From antoine at nagafix.co.uk Fri Oct 12 11:25:15 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Oct 2012 17:25:15 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210122115.50778.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> <5077CBA9.5050206@nagafix.co.uk> <201210122115.50778.onlyjob@member.fsf.org> Message-ID: <5077F00B.7050702@nagafix.co.uk> On 10/12/2012 05:15 PM, Dmitry Smirnov wrote: > On Fri, 12 Oct 2012 18:50:01 Antoine Martin wrote: >> Can you try the latest from the 0.7.x branch? I fear that the Mac OSX >> keyboard fix I have added there (present in trunk) might have had that >> effect. It would be best to know this before releasing this stable >> update. I would rather leave OSX broken then break something new.. > > Tried minutes ago -- it's the same thing as in trunk i.e. I can't switch to > non-English layout using Alt+Shift. Sorry. Damn. > By the way why are you using tag-branches instead of normal branches? ;) The difference is only in naming and semantics, branches and tags are the same thing in svn. Maybe the "tags" tree should have been called "branches", but since each tag looks like: "v0.N.x", it's pretty obvious what is in it. I'm not fond of actual version "tags", because it happens far too often that I find a minor distribution or platform specific issue that needs fixing during the release builds - and quite often this can be fixed after some of the packages have already been generated (since they may not use the modified file(s) at all), which means that the binary builds are not all exactly from the same revision - which is fine. Tagging would only increase the burden on me for little or no benefit. Cheers Antoine From antoine at nagafix.co.uk Sat Oct 13 18:06:15 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 14 Oct 2012 00:06:15 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210122115.50778.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> <5077CBA9.5050206@nagafix.co.uk> <201210122115.50778.onlyjob@member.fsf.org> Message-ID: <50799F87.1000607@nagafix.co.uk> On 10/12/2012 05:15 PM, Dmitry Smirnov wrote: > On Fri, 12 Oct 2012 18:50:01 Antoine Martin wrote: >> Can you try the latest from the 0.7.x branch? I fear that the Mac OSX >> keyboard fix I have added there (present in trunk) might have had that >> effect. It would be best to know this before releasing this stable >> update. I would rather leave OSX broken then break something new.. > > Tried minutes ago -- it's the same thing as in trunk i.e. I can't switch to > non-English layout using Alt+Shift. Sorry. Could you do me a favour and try to revert this patch to see if Alt+Shift is restored? http://xpra.org/trac/changeset/1924 And assuming it does, re-instating the first half then the other half, to see which one is making a difference. I am hoping that I can selectively apply this workaround for old servers only (ie: CentOS) Thanks Antoine This is the only other changeset that may have caused this: http://xpra.org/trac/changeset/1941 From onlyjob at member.fsf.org Sun Oct 14 07:07:40 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sun, 14 Oct 2012 17:07:40 +1100 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <50799F87.1000607@nagafix.co.uk> References: <201210121842.23716.onlyjob@member.fsf.org> <201210122115.50778.onlyjob@member.fsf.org> <50799F87.1000607@nagafix.co.uk> Message-ID: <201210141707.40712.onlyjob@member.fsf.org> On Sun, 14 Oct 2012 04:06:15 Antoine Martin wrote: > Could you do me a favour and try to revert this patch to see if > Alt+Shift is restored? > http://xpra.org/trac/changeset/1924 Reverting 1924 (completely or partially) did not have any effect on the issue with switching to non-English layout. > > This is the only other changeset that may have caused this: > http://xpra.org/trac/changeset/1941 It's good that you're know where is the issue now. :) -- Regards, Dmitry. From antoine at nagafix.co.uk Sun Oct 14 08:04:10 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 14 Oct 2012 14:04:10 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210141707.40712.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> <201210122115.50778.onlyjob@member.fsf.org> <50799F87.1000607@nagafix.co.uk> <201210141707.40712.onlyjob@member.fsf.org> Message-ID: <507A63EA.8010702@nagafix.co.uk> On 10/14/2012 01:07 PM, Dmitry Smirnov wrote: > On Sun, 14 Oct 2012 04:06:15 Antoine Martin wrote: >> Could you do me a favour and try to revert this patch to see if >> Alt+Shift is restored? >> http://xpra.org/trac/changeset/1924 > > Reverting 1924 (completely or partially) did not have any effect on the issue > with switching to non-English layout. Oh, that's very odd. > >> >> This is the only other changeset that may have caused this: >> http://xpra.org/trac/changeset/1941 > > It's good that you're know where is the issue now. :) Would you mind trying to revert this one to confirm? Thanks Antoine From onlyjob at member.fsf.org Sun Oct 14 11:35:39 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sun, 14 Oct 2012 21:35:39 +1100 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <507A63EA.8010702@nagafix.co.uk> References: <201210121842.23716.onlyjob@member.fsf.org> <201210141707.40712.onlyjob@member.fsf.org> <507A63EA.8010702@nagafix.co.uk> Message-ID: <201210142135.40308.onlyjob@member.fsf.org> On Sun, 14 Oct 2012 18:04:10 Antoine Martin wrote: > >> This is the only other changeset that may have caused this: > >> http://xpra.org/trac/changeset/1941 > > > > It's good that you're know where is the issue now. :) > > Would you mind trying to revert this one to confirm? Sure, I knew you would ask but I couldn't try right away due to lack of time. I'm not sure how to revert a particular patch (other than manually) so I've checked out v0.7.x/r1940. It works well, I can't see any regressions so far. Please let me know if/when you need to test whatever solution you may find. Thanks. All the best, Dmitry. From antoine at nagafix.co.uk Mon Oct 15 08:15:50 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 15 Oct 2012 14:15:50 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210142135.40308.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> <201210141707.40712.onlyjob@member.fsf.org> <507A63EA.8010702@nagafix.co.uk> <201210142135.40308.onlyjob@member.fsf.org> Message-ID: <507BB826.1080503@nagafix.co.uk> On 10/14/2012 05:35 PM, Dmitry Smirnov wrote: > On Sun, 14 Oct 2012 18:04:10 Antoine Martin wrote: >>>> This is the only other changeset that may have caused this: >>>> http://xpra.org/trac/changeset/1941 >>> >>> It's good that you're know where is the issue now. :) >> >> Would you mind trying to revert this one to confirm? > > Sure, I knew you would ask but I couldn't try right away due to lack of time. > > I'm not sure how to revert a particular patch (other than manually) so I've > checked out v0.7.x/r1940. > > It works well, I can't see any regressions so far. Would you mind trying r1941 to confirm that it is this changeset that is causing the regression? (there's nothing else keyboard related after this one - but better make sure) And if so, can you try each half separately (ignoring the win32 changes): * the changes to xpra/xkbhelper.py (to do with zero keycodes) * the changes to xpra/server_source.py ( Please be aware that due to some unfortunate asymmetry in the code X11 keyboard API, it is possible for the keyboard mappings to degrade every time you connect. This makes it much harder to pinpoint issues as it may take 2 or more connections before the problems manifest themselves. (as I found out at my expense when fixing Mac OS/win32 "AltGr" support) Cheers Antoine > > Please let me know if/when you need to test whatever solution you may find. > > Thanks. > > 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 Mon Oct 15 23:10:05 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 16 Oct 2012 09:10:05 +1100 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <507BB826.1080503@nagafix.co.uk> References: <201210121842.23716.onlyjob@member.fsf.org> <201210142135.40308.onlyjob@member.fsf.org> <507BB826.1080503@nagafix.co.uk> Message-ID: <201210160910.05668.onlyjob@member.fsf.org> On Mon, 15 Oct 2012 18:15:50 Antoine Martin wrote: > Would you mind trying r1941 to confirm that it is this changeset that is > causing the regression? (there's nothing else keyboard related after > this one - but better make sure) If you think it's necessary... (I already tried r1944)... > > And if so, can you try each half separately (ignoring the win32 changes): > * the changes to xpra/xkbhelper.py (to do with zero keycodes) > * the changes to xpra/server_source.py ( In r1941 regression is manifested so it is positive that r1941 is broken. When I tried r1941 with xpra/server_source.py from r1940 I couldn't reproduce the issue. > Please be aware that due to some unfortunate asymmetry in the code X11 > keyboard API, it is possible for the keyboard mappings to degrade every > time you connect. This makes it much harder to pinpoint issues as it may > take 2 or more connections before the problems manifest themselves. (as > I found out at my expense when fixing Mac OS/win32 "AltGr" support) Interesting but I never experienced this. However you're right, something like this is there, for example (as I reported earlier) some keys like keypad '*' (and some others) may not work after switching from non-English keyboard layout and back, but start working again after switching layout one more time (to non-English and back again). It is a bit weird to notice keyboard problems after odd layout switch but not after even. :) All the best, Dmitry. From antoine at nagafix.co.uk Tue Oct 16 13:23:19 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 16 Oct 2012 19:23:19 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.7.0 In-Reply-To: <507C1CB4.5030307@med.uni-frankfurt.de> References: <50731C01.4060203@nagafix.co.uk> <507C1CB4.5030307@med.uni-frankfurt.de> Message-ID: <507D51B7.8010405@nagafix.co.uk> On 10/15/2012 09:24 PM, Thomas Sattler wrote: > Hi Antoine, > >> * support for Xdummy on platforms with only a suid binary installed > > On Gentoo 'xpra_Xdummy' fails to copy "Xorg" as it is installed > without read permissions: > > $ ls -la `which Xorg` > -rws--x--x 1 root root 1773704 21. Sep 07:41 /usr/bin/Xorg Can you please try with this change: https://www.xpra.org/trac/changeset/1984 And let me know if that works for you, I can then apply this change to the stable branch. Note: it will fallback to using Xvfb instead of Xdummy, which is far from optimal, but I cannot see any way around that. Cheers Antoine > > Thomas From sattler at med.uni-frankfurt.de Tue Oct 16 14:07:01 2012 From: sattler at med.uni-frankfurt.de (Thomas Sattler) Date: Tue, 16 Oct 2012 15:07:01 +0200 Subject: [winswitch] [ANNOUNCE] xpra 0.7.0 In-Reply-To: <507D51B7.8010405@nagafix.co.uk> References: <50731C01.4060203@nagafix.co.uk> <507C1CB4.5030307@med.uni-frankfurt.de> <507D51B7.8010405@nagafix.co.uk> Message-ID: <507D5BF5.6050509@med.uni-frankfurt.de> Hi Antoine, On 10/16/2012 02:23 PM, Antoine Martin wrote: > Can you please try with this change: > https://www.xpra.org/trac/changeset/1984 > > And let me know if that works for you, I can > then apply this change to the stable branch. The given changeset allows starting a server. Thomas From antoine at nagafix.co.uk Fri Oct 19 03:18:07 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 19 Oct 2012 09:18:07 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210160910.05668.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> <201210142135.40308.onlyjob@member.fsf.org> <507BB826.1080503@nagafix.co.uk> <201210160910.05668.onlyjob@member.fsf.org> Message-ID: <5080B85F.2040209@nagafix.co.uk> (snip) >> And if so, can you try each half separately (ignoring the win32 changes): >> * the changes to xpra/xkbhelper.py (to do with zero keycodes) >> * the changes to xpra/server_source.py ( > In r1941 regression is manifested so it is positive that r1941 is broken. > > When I tried r1941 with xpra/server_source.py from r1940 I couldn't reproduce > the issue. Can you please try the attached patch on top of trunk or 0.7.x r1941 or later, and send me the output? (no need for debug mode) I need to understand where my assumptions are wrong, because this changeset looks innocuous. Thanks Antoine (snip) From antoine at nagafix.co.uk Fri Oct 19 04:23:55 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 19 Oct 2012 10:23:55 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <5080B85F.2040209@nagafix.co.uk> References: <201210121842.23716.onlyjob@member.fsf.org> <201210142135.40308.onlyjob@member.fsf.org> <507BB826.1080503@nagafix.co.uk> <201210160910.05668.onlyjob@member.fsf.org> <5080B85F.2040209@nagafix.co.uk> Message-ID: <5080C7CB.1080304@nagafix.co.uk> Missing patch attached. Antoine On 10/19/2012 09:18 AM, Antoine Martin wrote: > (snip) >>> And if so, can you try each half separately (ignoring the win32 >>> changes): >>> * the changes to xpra/xkbhelper.py (to do with zero keycodes) >>> * the changes to xpra/server_source.py ( >> In r1941 regression is manifested so it is positive that r1941 is >> broken. >> >> When I tried r1941 with xpra/server_source.py from r1940 I couldn't >> reproduce >> the issue. > Can you please try the attached patch on top of trunk or 0.7.x r1941 > or later, and send me the output? (no need for debug mode) > I need to understand where my assumptions are wrong, because this > changeset looks innocuous. > > Thanks > Antoine > > (snip) > _______________________________________________ > 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 Fri Oct 19 06:43:55 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Fri, 19 Oct 2012 16:43:55 +1100 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <5080C7CB.1080304@nagafix.co.uk> References: <201210121842.23716.onlyjob@member.fsf.org> <5080B85F.2040209@nagafix.co.uk> <5080C7CB.1080304@nagafix.co.uk> Message-ID: <201210191643.56162.onlyjob@member.fsf.org> On Fri, 19 Oct 2012 14:23:55 Antoine Martin wrote: > Missing patch attached. Sorry I still don't see an attachment. Feel free to send directly to me if mail list software drop attachments for whatever reason. Thanks. -- Regards, Dmitry. From antoine at nagafix.co.uk Fri Oct 19 10:06:04 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 19 Oct 2012 16:06:04 +0700 Subject: [winswitch] xpra 0.7.0 and little keyboard troubles In-Reply-To: <201210191643.56162.onlyjob@member.fsf.org> References: <201210121842.23716.onlyjob@member.fsf.org> <5080B85F.2040209@nagafix.co.uk> <5080C7CB.1080304@nagafix.co.uk> <201210191643.56162.onlyjob@member.fsf.org> Message-ID: <508117FC.3000106@nagafix.co.uk> On 10/19/2012 12:43 PM, Dmitry Smirnov wrote: > On Fri, 19 Oct 2012 14:23:55 Antoine Martin wrote: >> Missing patch attached. > Sorry I still don't see an attachment. > Feel free to send directly to me if mail list software drop attachments for > whatever reason. > > Thanks. > You're right, it does seem to have scrubbed it, here it is inlined: Index: src/xpra/server_source.py =================================================================== --- src/xpra/server_source.py (revision 1982) +++ src/xpra/server_source.py (working copy) @@ -134,6 +134,7 @@ except: log.error("error setting new keymap", exc_info=True) self.make_modifiers_match = (client_platform and not client_platform.startswith("win")) or (self.xkbmap_print!="" or self.xkbmap_query!="") + log.info("make_modifiers_match=%s, ", self.make_modifiers_match) try: #first clear all existing modifiers: clean_keyboard_state() @@ -559,8 +560,10 @@ log.info("ignoring keycode since keyboard is turned off") return -1 server_keycode = self.keyboard_config.keycode_translation.get((client_keycode, keyname)) + log.info("get_keycode: (%s,%s)=%s", client_keycode, keyname, server_keycode) if not server_keycode: server_keycode = self.keyboard_config.keycode_translation.get(keyname, client_keycode) + log.info("get_keycode: (%s)=%s", keyname, server_keycode) return server_keycode From onlyjob at member.fsf.org Sun Oct 21 01:05:21 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Sun, 21 Oct 2012 11:05:21 +1100 Subject: [winswitch] Fwd: Re: xpra 0.7.0 and little keyboard troubles In-Reply-To: <5082AB2B.8080009@nagafix.co.uk> References: <201210191643.56162.onlyjob@member.fsf.org> <201210202042.06447.onlyjob@member.fsf.org> <5082AB2B.8080009@nagafix.co.uk> Message-ID: <201210211105.22474.onlyjob@member.fsf.org> Hi Antoine, On Sun, 21 Oct 2012 00:46:19 Antoine Martin wrote: > Please try trunk as of: > https://www.xpra.org/trac/changeset/1985 > And let me know if this helps so I can finally release 0.7.1 with this fix. > It is good, keyboard layout switching is working again. :) Thanks. Regards, Dmitry. P.S. Would you like me to open a ticket for "little keyboard troubles" issue? From varvello at yahoo.com Mon Oct 15 14:43:12 2012 From: varvello at yahoo.com (Davide Varvello) Date: Mon, 15 Oct 2012 06:43:12 -0700 (PDT) Subject: [winswitch] Main problems with xpra 0.7.0 and winswitch 0.12.17 In-Reply-To: <1350025257.62753.YahooMailNeo@web160105.mail.bf1.yahoo.com> References: <50731C01.4060203@nagafix.co.uk> <1349907021.66142.YahooMailNeo@web160101.mail.bf1.yahoo.com> <1349907054.67971.YahooMailNeo@web160101.mail.bf1.yahoo.com> <5076A262.2080000@nagafix.co.uk> <1349957591.92622.YahooMailNeo@web160103.mail.bf1.yahoo.com> <5076BAE3.9050307@nagafix.co.uk> <1349959582.21867.YahooMailNeo@web160106.mail.bf1.yahoo.com> <5076C4BC.60408@nagafix.co.uk> <50771C18.4040208@nagafix.co.uk> <1350025257.62753.YahooMailNeo@web160105.mail.bf1.yahoo.com> Message-ID: <1350308592.46134.YahooMailNeo@web160105.mail.bf1.yahoo.com> Hi Antoine, ?I switched to 0.7.1 and everything is fine but... I'm not really sure my machine is running on 0.7.1 :-) xpra --version returns v0.7.1 but clicking on about section returns 0.7.0 (see attach) I add also xpra log:? [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list! [dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list! 2012-10-15 15:28:30,809 using notification forwarder: DBUSNotificationsForwarder(org.freedesktop.Notifications) 2012-10-15 15:28:30,820 xpra server version 0.7.1 2012-10-15 15:28:30,903 xpra is ready. 2012-10-15 15:29:06,312 New connection received: SocketConnection(/home/church/.xpra/machine-100 - ) 2012-10-15 15:29:06,315 Connection lost 2012-10-15 15:29:06,404 New connection received: SocketConnection(/home/church/.xpra/machine-100 - ) 2012-10-15 15:29:06,415 New connection received: SocketConnection(/home/church/.xpra/machine-100 - ) 2012-10-15 15:29:06,481 Connection lost 2012-10-15 15:29:06,485 Connection lost 2012-10-15 15:29:06,855 Lost WM selection, exiting 2012-10-15 15:29:06,856 xpra is terminating. 2012-10-15 15:29:06,886 xpra end of gtk.main(). 2012-10-15 15:29:06,886 upgrading: not cleaning up Xvfb or socket ? and ps: 4396 ? ? 1 ?0 15:28 ? ? ? ? ?00:00:00 Xvfb-for-Xpra-:100 +extension Composite -screen 0 3840x2560x24+32 -nolisten tcp -noreset? 4405 ? ? 1 ?0 15:28 ? ? ? ? ?00:00:00 dbus-launch --autolaunch 6e17cff66517c3e4393f96d54fe89d6c --binary-syntax --close-stderr 4406 ? ? 1 ?0 15:28 ? ? ? ? ?00:00:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 4547 ? ? 1 ?0 15:29 ? ? ? ? ?00:00:00 /usr/bin/python /usr/bin/winswitch_server --daemon 4592 ? ? 1 ?0 15:29 ? ? ? ? ?00:00:00 /usr/bin/python /usr/bin/xpra --bind-tcp=127.0.0.1:15062? 4610 ? ? 1 ?0 15:29 ? ? ? ? ?00:00:00 dbus-daemon --fork --print-address=1 --print-pid=1 --session 4618 ? ? 1 ?0 15:29 ? ? ? ? ?00:00:00 /usr/bin/python /usr/bin/xpra --bind-tcp=127.0.0.1:15063? 4619 ?4618 ?0 15:29 ? ? ? ? ?00:00:00 Xvfb-for-Xpra-:62 +extension Composite -screen 0 3840x2560x24+32 -nolisten tcp -noreset? 4667 ?4547 ?0 15:30 ? ? ? ? ?00:00:00 [xpra] It seems to me there is another xpra on :62 is it right? Davide From mehmetf at gmail.com Sat Oct 20 22:38:44 2012 From: mehmetf at gmail.com (Mehmet Fidanboylu) Date: Sat, 20 Oct 2012 14:38:44 -0700 Subject: [winswitch] Xpra 0.7 and retina screen Message-ID: Hi Xpra Users, I recently got a company laptop (macbook pro with retina screen). It seems that Apple did a nifty trick with this laptop and stuffed the 15'' screen with 2880x1800 pixels however the actual resolution is scaled to much lower (so that you can actually use the thing). I think Xpra gets confused by this scaling. I noted that the screen resolution sent to xpra during handshake is whatever scaled resolution is (1680x1050). The images that come back from xpra server look like they have been "zoomed in". Text and images look heavily anti-aliased. I downloaded the src code of client.py and manually set the resolution to 2880x1800, I don't think that made much of a difference. I also turned off font smoothing. I am using the following params: xpra --no-clipboard --no-pulseaudio --no-notifications --no-bell --encoding=x264 attach ssh: I am attaching a screen shot to show you what I mean. It is quite usable but not nearly as sharp as what I see when using it with a different monitor with no scaling (also attached). I dont think this is caused by the X server on client side. Starting up native apps like Terminal look sharp. Note that the attached images are not the same size (the artifact of the aforementioned scaling). Retina screenshots produce a larger pixel count. Any ideas? - Mehmet From antoine at nagafix.co.uk Sun Oct 21 05:34:56 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 21 Oct 2012 11:34:56 +0700 Subject: [winswitch] Xpra 0.7 and retina screen In-Reply-To: References: Message-ID: <50837B70.6020905@nagafix.co.uk> Hi, > ... manually set the resolution to 2880x1800 ... You mean in the Xvfb startup code? If so, you could have used the "--xvfb=" switch for that. Have you tried using the "--dpi" switch? I don't think Xpra can guess the correct dpi value to use from the gtk toolkit on osx, I will try to take a look when I get back. Are you using Xdummy or Xvfb? (look for xvfb= in your /etc/xpra/xpra.conf) Or more generally speaking, what is your server distro? Are you sure this isn't encoding related? Does this also happen with lossless encodings like png? (I know you are not seeing the same issue on another system, but you would be surprised what small details like a change in pixel count can do...) Cheers Antoine On 10/21/2012 04:38 AM, Mehmet Fidanboylu wrote: > Hi Xpra Users, > > I recently got a company laptop (macbook pro with retina screen). It seems > that Apple did a nifty trick with this laptop and stuffed the 15'' screen > with 2880x1800 pixels however the actual resolution is scaled to much lower > (so that you can actually use the thing). I think Xpra gets confused by > this scaling. I noted that the screen resolution sent to xpra during > handshake is whatever scaled resolution is (1680x1050). The images that > come back from xpra server look like they have been "zoomed in". Text and > images look heavily anti-aliased. I downloaded the src code of client.py > and manually set the resolution to 2880x1800, I don't think that made much > of a difference. I also turned off font smoothing. I am using the following > params: > > xpra --no-clipboard --no-pulseaudio --no-notifications --no-bell > --encoding=x264 attach ssh: > > I am attaching a screen shot to show you what I mean. It is quite usable > but not nearly as sharp as what I see when using it with a different > monitor with no scaling (also attached). I dont think this is caused by the > X server on client side. Starting up native apps like Terminal look sharp. > > Note that the attached images are not the same size (the artifact of the > aforementioned scaling). Retina screenshots produce a larger pixel count. > > Any ideas? > > - Mehmet > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From mehmetf at gmail.com Sun Oct 21 07:28:53 2012 From: mehmetf at gmail.com (Mehmet Fidanboylu) Date: Sat, 20 Oct 2012 23:28:53 -0700 Subject: [winswitch] Xpra 0.7 and retina screen In-Reply-To: References: Message-ID: Thanks for the reply Antoine. I will give more details: I changed the resolution manually in the client startup code, more specifically here: https://www.xpra.org/trac/browser/tags/v0.7.x/src/xpra/client.py#L15 . I thought this is how Xvfb was deciding the image size to be sent. Of course this is quite naive as I am sure the frame HxW (among other things) also comes into picture. My max "server" resolution is 3840x2560. So, I figured that is not a problem. I tried using the --dpi switch to no avail both client and server (dpi=300). My server is Xvfb (since that is what i see running via ps x). I installed the debian packages directly from http://xpra.org/dists/lucid/main/binary-amd64/ Yes, I am sure this is not encoding related but I tried your suggestion anyway. Even with PNG, the image/fonts are soft. Since then, I downloaded an app called QuickRes that lets me turn off scaling completely and actually use the full 2880x1800 resolution. I took some screenshots for both scaled and unscaled versions. I included the window title text for comparison. If you zoom in both pictures, you can clearly see that in the unscaled version the resolution for both window title (native) and firefox menu (xpra) looks the same. Whereas in the scaled version, xpra looks much worse. I am afraid the solution to this is going to require an in-depth understanding of how retina scaling works and I understand this is not a priority for xpra. I just found this problem interesting and wanted to see if there was a hack to circumvent the issue. From mehmetf at gmail.com Sun Oct 21 23:33:46 2012 From: mehmetf at gmail.com (Mehmet Fidanboylu) Date: Sun, 21 Oct 2012 15:33:46 -0700 Subject: [winswitch] Xpra 0.7 and retina screen In-Reply-To: References: Message-ID: I think I might have found the answer to this. I said the following in my original email: "I dont think this is caused by the X server on client side. Starting up native apps like Terminal look sharp." What I noticed later is that, the title bars etc of applications started on XQuartz did not look sharp. So, I went and read wikipedia :). Here's what it says: "As of version 2.7.2, X11.app/XQuartz does not expose support for high-resolution Retina displays to X11 apps, which run in pixel-doubled mode on high-resolution displays." Problem is not solved but at least now we know the main issue. On Sat, Oct 20, 2012 at 11:28 PM, Mehmet Fidanboylu wrote: > Thanks for the reply Antoine. I will give more details: > > I changed the resolution manually in the client startup code, more specifically here: https://www.xpra.org/trac/browser/tags/v0.7.x/src/xpra/client.py#L15 . I thought this is how Xvfb was deciding the image size to be sent. Of course this is quite naive as I am sure the frame HxW (among other things) also comes into picture. My max "server" resolution is 3840x2560. So, I figured that is not a problem. > > I tried using the --dpi switch to no avail both client and server (dpi=300). My server is Xvfb (since that is what i see running via ps x). I installed the debian packages directly from http://xpra.org/dists/lucid/main/binary-amd64/ > > Yes, I am sure this is not encoding related but I tried your suggestion anyway. Even with PNG, the image/fonts are soft. > > Since then, I downloaded an app called QuickRes that lets me turn off scaling completely and actually use the full 2880x1800 resolution. I took some screenshots for both scaled and unscaled versions. I included the window title text for comparison. If you zoom in both pictures, you can clearly see that in the unscaled version the resolution for both window title (native) and firefox menu (xpra) looks the same. Whereas in the scaled version, xpra looks much worse. > > I am afraid the solution to this is going to require an in-depth understanding of how retina scaling works and I understand this is not a priority for xpra. I just found this problem interesting and wanted to see if there was a hack to circumvent the issue. > > From onlyjob at member.fsf.org Thu Oct 25 01:46:49 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Thu, 25 Oct 2012 11:46:49 +1100 Subject: [winswitch] Q: how to attach to remote Xpra session through SSH with password auth.? Message-ID: <201210251146.49271.onlyjob@member.fsf.org> Dear Antoine, On my computers I use public key authentication which makes attaching to Xpra sessions very easy. Yesterday I was trying to connect to my session from non-trusted computer where for obvious reasons I had to use password authentication. Unfortunately I couldn't figure out how to attach to remote session over SSH if public key authentication is unavailable. How it is possible to attach with SSH password authentication? IMHO answer to this would naturally belong to FAQ. Please advise. Thank you. Regards, Dmitry. From onlyjob at member.fsf.org Thu Oct 25 01:56:19 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Thu, 25 Oct 2012 11:56:19 +1100 Subject: [winswitch] Xpra-FAQ: no problems with KDE/oxygen on Debian Wheezy Message-ID: <201210251156.19317.onlyjob@member.fsf.org> Hi Antoine, I've just realised that according to Xpra FAQ there might be some problems with "oxygen" theme on KDE. This is exactly what I'm using and I'd like to say that there are no problems with KDE/oxygen on Debian Wheezy. Perhaps FAQ is worth updating in that regards. Thanks. Cheers, Dmitry. From antoine at nagafix.co.uk Tue Oct 30 04:45:43 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 30 Oct 2012 11:45:43 +0700 Subject: [winswitch] Xpra-FAQ: no problems with KDE/oxygen on Debian Wheezy In-Reply-To: <201210251156.19317.onlyjob@member.fsf.org> References: <201210251156.19317.onlyjob@member.fsf.org> Message-ID: <508F5B77.2030007@nagafix.co.uk> On 10/25/2012 07:56 AM, Dmitry Smirnov wrote: > Hi Antoine, > > I've just realised that according to Xpra FAQ there might be some problems > with "oxygen" theme on KDE. This is exactly what I'm using and I'd like to say > that there are no problems with KDE/oxygen on Debian Wheezy. Just because you run a fixed/recent version of oxygen does not mean that most users are that lucky (and in fact, distro statistics say otherwise). The FAQ states: "There are problems with some versions of the oxygen theme engine (..)" Which does not imply that all users will have problems, only some. Once the majority of users are running a recent enough version, I will consider changing the wording. Cheers Antoine > > Perhaps FAQ is worth updating in that regards. > > Thanks. > > 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 Tue Oct 30 05:02:08 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 30 Oct 2012 12:02:08 +0700 Subject: [winswitch] Q: how to attach to remote Xpra session through SSH with password auth.? In-Reply-To: <201210251146.49271.onlyjob@member.fsf.org> References: <201210251146.49271.onlyjob@member.fsf.org> Message-ID: <508F5F50.2020603@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/25/2012 07:46 AM, Dmitry Smirnov wrote: > Dear Antoine, > > On my computers I use public key authentication which makes > attaching to Xpra sessions very easy. Yesterday I was trying to > connect to my session from non-trusted computer where for obvious > reasons I had to use password authentication. Unfortunately I > couldn't figure out how to attach to remote session over SSH if > public key authentication is unavailable. How it is possible to > attach with SSH password authentication? Works OK here: $ xpra attach ssh:test at localhost:10 test at localhost's password: xpra client version 0.8.0 Permission denied, please try again. (...) The version string was printed over the top of the password prompt, this is now fixed: https://www.xpra.org/trac/changeset/1990 I am building some 0.7.2 beta packages with this fix, they will appear here shortly: http://xpra.org/beta/ But if you just press return (or type it wrong) it will prompt you again (more cleanly this time). Cheers Antoine > > IMHO answer to this would naturally belong to FAQ. > > Please advise. > > Thank you. > > Regards, Dmitry. _______________________________________________ > 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/ iEYEARECAAYFAlCPX1AACgkQGK2zHPGK1rvSxQCfTSvoqPnmCbyLJJHYvFs5QT+0 j7gAn0xaJDl+hcQ9Hq82xyNsJASMFMfN =nhUe -----END PGP SIGNATURE----- From onlyjob at member.fsf.org Tue Oct 30 05:27:20 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 30 Oct 2012 16:27:20 +1100 Subject: [winswitch] Xpra-FAQ: no problems with KDE/oxygen on Debian Wheezy In-Reply-To: <508F5B77.2030007@nagafix.co.uk> References: <201210251156.19317.onlyjob@member.fsf.org> <508F5B77.2030007@nagafix.co.uk> Message-ID: <201210301627.21182.onlyjob@member.fsf.org> On Tue, 30 Oct 2012 15:45:43 Antoine Martin wrote: > Just because you run a fixed/recent version of oxygen does not mean that > most users are that lucky (and in fact, distro statistics say > otherwise). The FAQ states: > "There are problems with some versions of the oxygen theme engine (..)" > Which does not imply that all users will have problems, only some. > Once the majority of users are running a recent enough version, I will > consider changing the wording. Thanks for your comment. I'm not challenging FAQ or wording. My intention was to merely provide some feedback. It is good to warn people about known problems but not to condemn KDE or Oxygen as troublesome. I just wanted you to know that situation has improved. Regards, Dmitry. From onlyjob at member.fsf.org Tue Oct 30 06:08:44 2012 From: onlyjob at member.fsf.org (Dmitry Smirnov) Date: Tue, 30 Oct 2012 17:08:44 +1100 Subject: [winswitch] Q: how to attach to remote Xpra session through SSH with password auth.? In-Reply-To: <508F5F50.2020603@nagafix.co.uk> References: <201210251146.49271.onlyjob@member.fsf.org> <508F5F50.2020603@nagafix.co.uk> Message-ID: <201210301708.44863.onlyjob@member.fsf.org> On Tue, 30 Oct 2012 16:02:08 Antoine Martin wrote: > Works OK here: > $ xpra attach ssh:test at localhost:10 > test at localhost's password: xpra client version 0.8.0 Thank you. I got so used to "ssh:HOST:DISPLAY" notation and at the same time overwhelmed with other things that this simple answer didn't quite came to mind when I needed it. Worth noticing that man page do not suggest that "ssh:[USER@]HOST:DISPLAY" can be used as well and as my miserable experience proved it may not be very obvious. > The version string was printed over the top of the password prompt, This was never an issue to me. What contributed to the confusion on my side is the fact that never before I used SSH password authentication with Xpra. I was trying to connect from someone's keyboard to my session on server where user also had an account. bash: .xpra/run-xpra: No such file or directory cannot write using ['ssh', '-T', 'HOST']: the SSH process has terminated with exit code=127 I got the above error message which is just indicate that user didn't have a Xpra session on server (I just typed "xpra attach ssh:HOST:DISPLAY" automatically and therefore was mistakenly trying to connect to user's session, not mine. Without password prompt (user also have a public key authentication to the server) I misunderstood the issue as problem with password authentication. It was totally stupid but I didn't realised it back then in the late afternoon when I was tired and had no time. I hope the lesson from this experience may help to improve the error message in case when remote session don't exist. At the moment one can tell that remote Xpra session do not exist only from prior experience (which I'm lacking as well because I usually connect to session that is running). As you can see the attempt to connect to non- existent session gives two errors: bash: .xpra/run-xpra: No such file or directory cannot write using ['ssh', '-T', 'HOST']: the SSH process has terminated with exit code=127 neither of which is clear about the real issue (cause). Cheers, Dmitry. From antoine at nagafix.co.uk Tue Oct 30 06:37:33 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 30 Oct 2012 13:37:33 +0700 Subject: [winswitch] Q: how to attach to remote Xpra session through SSH with password auth.? In-Reply-To: <201210301708.44863.onlyjob@member.fsf.org> References: <201210251146.49271.onlyjob@member.fsf.org> <508F5F50.2020603@nagafix.co.uk> <201210301708.44863.onlyjob@member.fsf.org> Message-ID: <508F75AD.4050600@nagafix.co.uk> (snip) > Worth noticing that man page do not suggest that "ssh:[USER@]HOST:DISPLAY" can > be used as well and as my miserable experience proved it may not be very > obvious. Thanks, I've updated the man page: https://www.xpra.org/trac/changeset/1995 (snip) > I was trying to connect from someone's keyboard to my session on server where > user also had an account. > > bash: .xpra/run-xpra: No such file or directory > cannot write using ['ssh', '-T', 'HOST']: > the SSH process has terminated with exit code=127 > > I got the above error message which is just indicate that user didn't have a > Xpra session on server (I just typed "xpra attach ssh:HOST:DISPLAY" > automatically and therefore was mistakenly trying to connect to user's > session, not mine. Without password prompt (user also have a public key > authentication to the server) I misunderstood the issue as problem with > password authentication. It was totally stupid but I didn't realised it back > then in the late afternoon when I was tired and had no time. > > I hope the lesson from this experience may help to improve the error message > in case when remote session don't exist. > > At the moment one can tell that remote Xpra session do not exist only from > prior experience (which I'm lacking as well because I usually connect to > session that is running). As you can see the attempt to connect to non- > existent session gives two errors: > > bash: .xpra/run-xpra: No such file or directory > > cannot write using ['ssh', '-T', 'HOST']: > the SSH process has terminated with exit code=127 > > neither of which is clear about the real issue (cause). I will try to do something about that. 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 mvrable at google.com Wed Oct 31 05:46:30 2012 From: mvrable at google.com (Michael Vrable) Date: Tue, 30 Oct 2012 22:46:30 -0700 Subject: [winswitch] Reworking Encryption in Xpra Message-ID: <20121031054630.GA2191@google.com> A couple of weeks back I was taking a look at some of the encryption code in Xpra and was thinking that the code could use some improvements (see bug #198). I haven't had as much time to work on this on my own as I'd like (since it's really just been in my free time on evenings/weekends), but have made some progress. Attached is a first patch (still needs to be tested) at adding better transport-layer encryption to Xpra--it adds message authentication to each of the packets to prevent any tampering of the data stream. Please don't commit it, as it isn't ready for that yet. I'm also working on a patch to implement key exchange at the start of a connection (the patch I'm posting will require that to work); I'm currently doing some testing on that and need to get a final approval to release it. Hopefully that will be done in the next few days, and I'll send it here to be looked at too. This is definitely still work in progress, and will warrant a security review before it should be trusted, but should be a good first step. --Michael Vrable From mvrable at google.com Wed Oct 31 05:50:56 2012 From: mvrable at google.com (Michael Vrable) Date: Tue, 30 Oct 2012 22:50:56 -0700 Subject: [winswitch] Reworking Encryption in Xpra In-Reply-To: <20121031054630.GA2191@google.com> References: <20121031054630.GA2191@google.com> Message-ID: <20121031055056.GB2191@google.com> On Tue, Oct 30, 2012 at 10:46:30PM -0700, Michael Vrable wrote: > Attached is a first patch (still needs to be tested) at adding better > transport-layer encryption to Xpra--it adds message authentication to each of > the packets to prevent any tampering of the data stream. Please don't commit > it, as it isn't ready for that yet. Does the mailing list strip attachments? I'm not sure it went through, so here it is again inline. --Michael Vrable commit 1f7e729bbb1e641506ca36ee82bd78c6ff009595 Author: Michael Vrable Proof-of-concept implementation of a more secure transport layer for Xpra. This uses AES encryption of data packets (in CTR mode to avoid the need for padding), and a truncated HMAC-SHA-256 to provide authentication of the data stream. This assumes that both sides have run some type of key-agreement protocol to establish a shared session secret. I'm working on the key exchange part in a separate patch which will follow. This code isn't yet tested, but should give a basic idea. diff --git a/src/xpra/protocol.py b/src/xpra/protocol.py index 2fdec82..95da1ad 100644 --- a/src/xpra/protocol.py +++ b/src/xpra/protocol.py @@ -11,12 +11,16 @@ from wimpiggy.gobject_compat import import_gobject gobject = import_gobject() gobject.threads_init() +import hashlib +import hmac import sys import socket # for socket.error import zlib import struct import time import os +from Crypto.Cipher import AES +from Crypto.Util import Counter NOYIELD = os.environ.get("XPRA_YIELD") is None @@ -69,6 +73,168 @@ def zlib_compress(datatype, data, level=5): return ZLibCompressed(datatype, cdata, level) +class CryptoError(ValueError): + """Error raised when decryption fails for any reason.""" + pass + + +class TransportCrypto: + """Interface for transport-level encryption layers. + + This class defines the methods that must be implemented to define a + transport-layer encryption/authentication method. The crypto layer is + generally set up after both parties have performed mutual authentication + and established a shared secret value, which is used to key the + encryption/MAC primitives. + + This class does not provide an implementation and so should not be + instantiated directly. Use one of NullCrypto or AESCrypto. + """ + + def name(self): + """Returns the name of the current crypto layer.""" + raise NotImplementedError + + def overhead_bytes(self, packet_len): + """Returns the number of bytes added to a packet of the given size. + + This allows a crypto transport to add extra data for an IV, padding, or + MAC. + """ + raise NotImplementedError + + def encrypt(self, header, payload): + """Encrypt/MAC the specified data payload. + + Returns the modified payload, which will be of length + len(payload) + overhead_bytes(len(payload)) + The encrypted payload does not include the header, but the computed MAC + may cover the values in the header. + """ + raise NotImplementedError + + def decrypt(self, header, payload): + """Decrypt the specified data payload. + + Returns the decrypted payload data, or raises a CryptoError exception + on any failures (bad MAC, incorrect padding if padding is used, etc.). + """ + raise NotImplementedError + + +class NullCrypto(TransportCrypto): + """A transparent transport which performs no encryption/authentication.""" + + def name(self): + return "null" + + def overhead_bytes(self, packet_len): + return 0 + + def encrypt(self, header, payload): + return payload + + def decrypt(self, header, payload): + return payload + + +class AESCrypto(TransportCrypto): + """A crypto layer using AES256 in CTR mode and HMAC-SHA-256. + + For each communication direction, two keys are derived from the shared + session secret: one encryption key and one message authentication key. + Data payloads are encrypted with AES in CTR mode, starting with a counter + value all zeroes. No padding is needed. + + A message authentication code (MAC) is appended to each packet; the MAC is + computed using HMAC-SHA-256 (keyed with the authentication key). The + digest is computed over the concatentation of a 64-bit, big-endian packet + counter (to prevent packet replay/reorder attacks), the unencrypted packet + header, and the encrypted packet data. The hash is truncated to mac_bytes + in length (default: 12 bytes = 96 bits) then appended after the packet + data. The length field encoded in the packet header is the length of the + data payload, not including the header and MAC. + """ + + def __init__(self, session_secret, context, mac_bytes=12): + """Initializes the crypto layer for one direction of a transport. + + Args: + session_secret: A secret value negotiated by both sides of the + connection. The value of session_secret must never be re-used + in a different connection, or security may suffer. This may be + any string value. + context: A string used to distinguish multiple related + instantiations of AESCrypto. For example, a client and server + may compute a single shared session_secret, and use a context + of "server" for data sent by the server and "client" for data + sent by the client. This ensures that separate keys are used + for each data direction. + mac_bytes: Number of bytes to include in the message authentication + code for each packet. The MAC is a truncated HMAC-SHA-256; + mac_bytes can be up to 32 but smaller values reduce overhead at + the risk of allowing undetected errors if mac_bytes is too + small. + """ + self._session_secret = session_secret + self._context = context + + # Derived keys. There are two: + # - A 256-bit AES key for encryption + # - A key used for HMAC authentication + def derive_key(subtype): + return hmac.new(session_secret, "%s-%s" % (context, subtype), + digest_mod=hashlib.sha256).digest() + key_enc = derive_key("aes") + key_mac = derive_key("mac") + + # Start CTR mode counting from zero. This is safe as long as every + # session (and direction) uses a unique encryption key. + self._cipher = AES.new(key_enc, mode=AES.MODE_CTR, + counter=Counter.new(128)) + + self._hmac_key = key_mac + self._mac_bytes = mac_bytes + + # The packet counter. This is incremented for each packet processed. + # The packet counter is included in the MAC for each packet (to prevent + # replay/reordering attacks), but is not explicitly added to the output + # to reduce overhead. + self._packet_counter = 0 + + def name(self): + return "aes256-ctr/hmac256-%d" % (self._mac_bytes * 8) + + def overhead_bytes(self, packet_len): + # No padding is needed for CTR mode, so the only overhead is the MAC + # overhead, independent of packet size. + return self._mac_bytes + + def encrypt(self, header, payload): + payload = self._cipher.encrypt(payload) + mac = hmac.new(self._hmac_key, digest_mod=hashlib.sha256) + mac.update(struct.pack("!Q", self._packet_counter)) + self._packet_counter += 1 + mac.update(header) + mac.update(payload) + mac_value = mac.digest()[0:self._mac_bytes] + return payload + mac_value + + def decrypt(self, header, payload): + if len(payload) < self._mac_bytes: + raise CryptoError("Bad decryption") + payload_data = payload[:-self._mac_bytes] + payload_mac = payload[-self._mac_bytes:] + mac = hmac.new(self._hmac_key, digest_mod=hashlib.sha256) + mac.update(struct.pack("!Q", self._packet_counter)) + self._packet_counter += 1 + mac.update(header) + mac.update(payload_data) + if mac.digest()[0:self._mac_bytes] != payload_mac: + raise CryptoError("Bad decryption") + return self._cipher.decrypt(payload_data) + + class Protocol(object): CONNECTION_LOST = "connection-lost" GIBBERISH = "gibberish" @@ -97,12 +263,8 @@ class Protocol(object): self._encoder = self.bencode self._decompressor = zlib.decompressobj() self._compression_level = 0 - self.cipher_in = None - self.cipher_in_name = None - self.cipher_in_block_size = 0 - self.cipher_out = None - self.cipher_out_name = None - self.cipher_out_block_size = 0 + self.cipher_in = NullCrypto() + self.cipher_out = NullCrypto() def make_daemon_thread(target, name): daemon_thread = Thread(target=target, name=name) daemon_thread.setDaemon(True) @@ -112,33 +274,15 @@ class Protocol(object): self._read_thread = make_daemon_thread(self._read_thread_loop, "read_loop") self._read_parser_thread = make_daemon_thread(self._read_parse_thread_loop, "read_parse_loop") - def get_cipher(self, ciphername, iv, password, key_salt, iterations): - log("get_cipher_in(%s, %s, %s, %s, %s)", ciphername, iv, password, key_salt, iterations) - if not ciphername: - return None, 0 - assert iterations>=100 - assert ciphername=="AES" - assert password and iv - from Crypto.Cipher import AES - from Crypto.Protocol.KDF import PBKDF2 - #stretch the password: - block_size = 32 #fixme: can we derive this? - secret = PBKDF2(password, key_salt, dkLen=block_size, count=iterations) - #secret = (password+password+password+password+password+password+password+password)[:32] - log("get_cipher(%s, %s, %s) secret=%s, block_size=%s", ciphername, iv, password, secret.encode('hex'), block_size) - return AES.new(secret, AES.MODE_CBC, iv), block_size - - def set_cipher_in(self, ciphername, iv, password, key_salt, iterations): - if self.cipher_in_name!=ciphername: - log.info("receiving data using %s encryption", ciphername) - self.cipher_in_name = ciphername - self.cipher_in, self.cipher_in_block_size = self.get_cipher(ciphername, iv, password, key_salt, iterations) - - def set_cipher_out(self, ciphername, iv, password, key_salt, iterations): - if self.cipher_out_name!=ciphername: - log.info("sending data using %s encryption", ciphername) - self.cipher_out_name = ciphername - self.cipher_out, self.cipher_out_block_size = self.get_cipher(ciphername, iv, password, key_salt, iterations) + def set_cipher(self, direction, ciphername, session_secret, context): + cipher = AESCrypto(session_secret, context) + log.info("setting encryption from %s to %s", context, cipher.name()) + if direction == "in": + self.cipher_in = cipher + elif direction == "out": + self.cipher_out = cipher + else: + raise ValueError("Unknown cipher direction: " + direction) def __str__(self): ti = ["%s:%s" % (x.name, x.is_alive()) for x in self.get_threads()] @@ -289,29 +433,12 @@ class Protocol(object): #fire the end_send callback when the last packet (index==0) makes it out: if index==0: ecb = end_send_cb - if self.cipher_out: - proto_flags |= Protocol.FLAGS_CIPHER - #note: since we are padding: l!=len(data) - padding = (self.cipher_out_block_size - len(data) % self.cipher_out_block_size) * " " - if len(padding)==0: - padded = data - else: - padded = data+padding - actual_size = payload_size + len(padding) - assert len(padded)==actual_size - data = self.cipher_out.encrypt(padded) - assert len(data)==actual_size - log("sending %s bytes encrypted with %s padding", payload_size, len(padding)) - if actual_size<16384: - #'p' + protocol-flags + compression_level + packet_index + data_size - if type(data)==unicode: - data = str(data) - header_and_data = struct.pack('!BBBBL%ss' % actual_size, ord("P"), proto_flags, level, index, payload_size, data) - self._write_queue.put((header_and_data, scb, ecb)) - else: - header = struct.pack('!BBBBL', ord("P"), proto_flags, level, index, payload_size) - self._write_queue.put((header, scb, None)) - self._write_queue.put((data, None, ecb)) + header = struct.pack('!BBBBL', + ord("P"), proto_flags, level, + index, payload_size) + data = self.cipher_out.encrypt(header, data) + self._write_queue.put((header, scb, None)) + self._write_queue.put((data, None, ecb)) counter += 1 finally: self.output_packetcount += 1 @@ -437,20 +564,14 @@ class Protocol(object): break #packet still too small #packet format: struct.pack('cBBBL', ...) - 8 bytes try: - _, protocol_flags, compression_level, packet_index, data_size = struct.unpack_from('!cBBBL', read_buffer) + header = read_buffer[:8] + _, protocol_flags, compression_level, packet_index, data_size = struct.unpack('!cBBBL', header) except Exception, e: raise Exception("invalid packet header: %s" % list(read_buffer[:8]), e) read_buffer = read_buffer[8:] bl = len(read_buffer) - if protocol_flags & Protocol.FLAGS_CIPHER: - assert self.cipher_in_block_size>0, "received cipher block but we don't have a cipher do decrypt it with" - padding = (self.cipher_in_block_size - data_size % self.cipher_in_block_size) * " " - payload_size = data_size + len(padding) - else: - #no cipher, no padding: - padding = None - payload_size = data_size - assert payload_size>0 + payload_size = (data_size + + self.cipher_in.overhead_bytes(data_size)) if payload_size>self.max_packet_size: #this packet is seemingly too big, but check again from the main UI thread @@ -474,13 +595,11 @@ class Protocol(object): raw_string = read_buffer[:payload_size] read_buffer = read_buffer[payload_size:] #decrypt if needed: - data = raw_string - if self.cipher_in and protocol_flags & Protocol.FLAGS_CIPHER: - log("received %s encrypted bytes with %s padding", payload_size, len(padding)) - data = self.cipher_in.decrypt(raw_string) - if padding: - assert data.endswith(padding), "decryption failed: string does not end with '%s': %s (%s) -> %s (%s)" % (padding, list(bytearray(raw_string)), type(raw_string), list(bytearray(data)), type(data)) - data = data[:-len(padding)] + try: + data = self.cipher_in.decrypt(header, raw_string) + if len(data) != len(data_size): raise CryptoError() + except CryptoError: + return self._call_connection_lost("Decryption failed: %s" % repr_ellipsized(data)) #uncompress if needed: if compression_level>0: if self.chunked_compression: @@ -490,9 +609,6 @@ class Protocol(object): if sys.version>='3': data = data.decode("latin1") - if self.cipher_in and not (protocol_flags & Protocol.FLAGS_CIPHER): - return self._call_connection_lost("unencrypted packet dropped: %s" % repr_ellipsized(data)) - if self._closed: return if packet_index>0: From antoine at nagafix.co.uk Wed Oct 31 06:48:32 2012 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 31 Oct 2012 13:48:32 +0700 Subject: [winswitch] Reworking Encryption in Xpra In-Reply-To: <20121031055056.GB2191@google.com> References: <20121031054630.GA2191@google.com> <20121031055056.GB2191@google.com> Message-ID: <5090C9C0.8030804@nagafix.co.uk> On 10/31/2012 12:50 PM, Michael Vrable wrote: > On Tue, Oct 30, 2012 at 10:46:30PM -0700, Michael Vrable wrote: >> Attached is a first patch (still needs to be tested) at adding better >> transport-layer encryption to Xpra--it adds message authentication to each of >> the packets to prevent any tampering of the data stream. Please don't commit >> it, as it isn't ready for that yet. Don't worry, there is no need to rush. > Does the mailing list strip attachments? I'm not sure it went through, so here > it is again inline. It looks like it does, even though mailman's "Scrub attachments of regular delivery message?" is turned off.. (snip) > This assumes that both sides have run some type of key-agreement > protocol to establish a shared session secret. I'm working on the key > exchange part in a separate patch which will follow. Out of curiosity, what sort of key exchange are you interested in? > This code isn't yet tested, but should give a basic idea. Only had a quick glance at it, looks nicely abstracted. Will take a proper look later. (I may move the crypto import stuff to where it is used to allow one to build xpra without the crypto options - no biggie) Cheers Antoine From mvrable at google.com Wed Oct 31 17:10:17 2012 From: mvrable at google.com (Michael Vrable) Date: Wed, 31 Oct 2012 10:10:17 -0700 Subject: [winswitch] Reworking Encryption in Xpra In-Reply-To: <5090C9C0.8030804@nagafix.co.uk> References: <20121031054630.GA2191@google.com> <20121031055056.GB2191@google.com> <5090C9C0.8030804@nagafix.co.uk> Message-ID: <20121031171017.GA32419@google.com> On Wed, Oct 31, 2012 at 01:48:32PM +0700, Antoine Martin wrote: > On 10/31/2012 12:50 PM, Michael Vrable wrote: >> Does the mailing list strip attachments? I'm not sure it went >> through, so here it is again inline. > It looks like it does, even though mailman's "Scrub attachments of > regular delivery message?" is turned off.. I noticed later that my original message was flagged as spam by mail.nagafix.co.uk for some reason, so perhaps that was related to the attachment scrubbing? The second message was not marked as spam. >> This assumes that both sides have run some type of key-agreement >> protocol to establish a shared session secret. I'm working on the >> key exchange part in a separate patch which will follow. > Out of curiosity, what sort of key exchange are you interested in? The code I'm working on currently simply does a basic Diffie-Hellman key exchange with an HMAC to prevent a man-in-the-middle attack, but this does leak information about the password to an active attacker. After I get the basics working, I was considering implementing something based on EAP-EKE since that is standardized. SPEKE is nice and simple, but there might be patent issues (I haven't fully investigated) so that might be worth avoiding. In any case, it should be fairly easy to plug in different mechanisms once I get the framework for it. > (I may move the crypto import stuff to where it is used to allow one > to build xpra without the crypto options - no biggie) Good point, I'll do that to my patches here. --Michael Vrable