From mukulagrawal78 at yahoo.com Mon Jan 2 17:20:33 2017 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Mon, 2 Jan 2017 17:20:33 +0000 (UTC) Subject: [winswitch] XPRA on TLS/SSL In-Reply-To: <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk> <1e61d82e-cbe3-658c-e75b-641e9153adba@nagafix.co.uk> <1097677634.1209542.1482529628422@mail.yahoo.com> <3f4cf197-6673-4934-4d38-899751994df5@nagafix.co.uk> <677559647.4418560.1483141563904@mail.yahoo.com> <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> Message-ID: <762452944.5353687.1483377633389@mail.yahoo.com> I got a commercial SSL certificate installed on my ubuntu xenial machine.I tested the setup using a simple "Hello World" python https server. Everything is woorking good. I can hit the index page using https from anywhere from outside world.Also checked with "openssl s_client -connect" and it confiorms that certificate is using used properly. Now I started the xpra server following instructions here - Encryption/SSL ? Xpra | | | | | | | | | | | Encryption/SSL ? Xpra xpra - screen for X | | | | Used following command :- xpra start :17 --start=xclock --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=/path/to/fullchain.pem --ssl-key=/ path/to/privatekey.pem ssl=https Now if I hit the webaddress from webbrowser with https, I get following error on browser ;- SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG "openssl s_client -connect" is showing "connected" but giving an error? 140770FC:SSL rountines:SSL23_GET_SERVER_HELLO:unknown_protocol:s23_clnt.c:794: XPRA server logs are showing "invalid packet header, SSL packet?" Any idea what is going on?I am doing iptable routing from 443 to 3001. This works just fine with the above mentioned "Hello World" python https server. It seems to me there is some problem with websockify's webserver is trying to attach certificates to wrong port or network interface. Any advice on how to debug this? ?Regards, Mukul From mukulagrawal78 at yahoo.com Mon Jan 2 19:39:36 2017 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Mon, 2 Jan 2017 19:39:36 +0000 (UTC) Subject: [winswitch] XPRA on TLS/SSL In-Reply-To: <762452944.5353687.1483377633389@mail.yahoo.com> References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk> <1e61d82e-cbe3-658c-e75b-641e9153adba@nagafix.co.uk> <1097677634.1209542.1482529628422@mail.yahoo.com> <3f4cf197-6673-4934-4d38-899751994df5@nagafix.co.uk> <677559647.4418560.1483141563904@mail.yahoo.com> <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> <762452944.5353687.1483377633389@mail.yahoo.com> Message-ID: <1231418285.5451936.1483385976791@mail.yahoo.com> OK, I tried something slightly different. I removed the "ssl=https" (seems like I was not reading the wiki on https://xpra.org/trac/ticket/1213 correctly). Here is what I did :- xpra start :17 --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=./fullchain.pem --ssl-key=./privkey.pem --start=xclock =>? Simply hit the https://hostname.com. Web-browser says Secure Connection Failed. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.=> XPRA log is showing:- Error: error in network packet reading/parsing^[[0m ^[[31m2017-01-02 19:11:15,446 invalid_header() takes exactly 3 arguments (4 given) Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 682, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 725, in do_read_parse_thread_loop=> openssl s_client -connect host:443 -- this is showing ssl is connect and is working fine Any idea why browser is not connecting? Do I need to provide some parameters on the address line on the browser? ?Regards, Mukul On Monday, January 2, 2017 5:20 PM, Mukul Agrawal via shifter-users wrote: I got a commercial SSL certificate installed on my ubuntu xenial machine.I tested the setup using a simple "Hello World" python https server. Everything is woorking good. I can hit the index page using https from anywhere from outside world.Also checked with "openssl s_client -connect" and it confiorms that certificate is using used properly. Now I started the xpra server following instructions here - Encryption/SSL ? Xpra ? |? |? |? |? |? ? | ? | ? | |? |? |? Encryption/SSL ? Xpra xpra - screen for X? |? | ? | ? | Used following command :- xpra start :17 --start=xclock --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=/path/to/fullchain.pem --ssl-key=/ path/to/privatekey.pem ssl=https Now if I hit the webaddress from webbrowser with https, I get following error on browser ;- SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG "openssl s_client -connect" is showing "connected" but giving an error? 140770FC:SSL rountines:SSL23_GET_SERVER_HELLO:unknown_protocol:s23_clnt.c:794: XPRA server logs are showing "invalid packet header, SSL packet?" Any idea what is going on?I am doing iptable routing from 443 to 3001. This works just fine with the above mentioned "Hello World" python https server. It seems to me there is some problem with websockify's webserver is trying to attach certificates to wrong port or network interface. Any advice on how to debug this? ?Regards, Mukul ? _______________________________________________ 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 Jan 3 09:01:30 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 3 Jan 2017 16:01:30 +0700 Subject: [winswitch] XPRA on TLS/SSL In-Reply-To: <1231418285.5451936.1483385976791@mail.yahoo.com> References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk> <1e61d82e-cbe3-658c-e75b-641e9153adba@nagafix.co.uk> <1097677634.1209542.1482529628422@mail.yahoo.com> <3f4cf197-6673-4934-4d38-899751994df5@nagafix.co.uk> <677559647.4418560.1483141563904@mail.yahoo.com> <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> <762452944.5353687.1483377633389@mail.yahoo.com> <1231418285.5451936.1483385976791@mail.yahoo.com> Message-ID: On 03/01/17 02:39, Mukul Agrawal via shifter-users wrote: > OK, I tried something slightly different. I removed the "ssl=https" (seems like I was not reading the wiki on https://xpra.org/trac/ticket/1213 correctly). > Here is what I did :- Please always include all the details: the full OS version, the full xpra version, the full command or log output, the browser you used, etc. And you really should be testing with more than one browser. Since you are using a signed certificate, you should include how you generated the full chain. What CA you used, etc You may also want to enable "-d websocket,http" Or even adding "-d network" (this may be too verbose) Also, please try using a better email service. Yahoo makes a complete mess of the text formatting and your emails are a pain to parse. (and that's just one of many reasons to stay away from Yahoo) > xpra start :17 --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=./fullchain.pem --ssl-key=./privkey.pem --start=xclock > => Simply hit the https://hostname.com. Web-browser says Secure Connection Failed. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.=> XPRA log is showing:- Error: error in network packet reading/parsing^[[0m ^[[31m2017-01-02 19:11:15,446 invalid_header() takes exactly 3 arguments (4 given) Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 682, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 725, in do_read_parse_thread_loop=> openssl s_client -connect host:443 -- this is showing ssl is connect and is working fine > Any idea why browser is not connecting? Do I need to provide some parameters on the address line on the browser? No. If openssl connects OK, so should the browser AFAIK. Cheers Antoine > > > Regards, > Mukul > > > On Monday, January 2, 2017 5:20 PM, Mukul Agrawal via shifter-users wrote: > > > I got a commercial SSL certificate installed on my ubuntu xenial machine.I tested the setup using a simple "Hello World" python https server. Everything is woorking good. I can hit the index page using https from anywhere from outside world.Also checked with "openssl s_client -connect" and it confiorms that certificate is using used properly. > Now I started the xpra server following instructions here - > Encryption/SSL ? Xpra > > > | > | > | > | | | > > | > > | > | > | | > Encryption/SSL ? Xpra > xpra - screen for X | | > > | > > | > > > > Used following command :- > xpra start :17 --start=xclock --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=/path/to/fullchain.pem --ssl-key=/ > path/to/privatekey.pem ssl=https > > Now if I hit the webaddress from webbrowser with https, I get following error on browser ;- > SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG > > "openssl s_client -connect" is showing "connected" but giving an error 140770FC:SSL rountines:SSL23_GET_SERVER_HELLO:unknown_protocol:s23_clnt.c:794: > > XPRA server logs are showing "invalid packet header, SSL packet?" > > Any idea what is going on?I am doing iptable routing from 443 to 3001. This works just fine with the above mentioned "Hello World" python https server. It seems to me there is some problem with websockify's webserver is trying to attach certificates to wrong port or network interface. Any advice on how to debug this? > > Regards, > Mukul > > > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From mukulagrawal78 at yahoo.com Tue Jan 3 18:00:10 2017 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Tue, 3 Jan 2017 18:00:10 +0000 (UTC) Subject: [winswitch] XPRA on TLS/SSL In-Reply-To: References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk> <1e61d82e-cbe3-658c-e75b-641e9153adba@nagafix.co.uk> <1097677634.1209542.1482529628422@mail.yahoo.com> <3f4cf197-6673-4934-4d38-899751994df5@nagafix.co.uk> <677559647.4418560.1483141563904@mail.yahoo.com> <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> <762452944.5353687.1483377633389@mail.yahoo.com> <1231418285.5451936.1483385976791@mail.yahoo.com> Message-ID: <1496833402.6024049.1483466410201@mail.yahoo.com> Antoine: Sorry for the trouble with Yahoo. I did test lots of client OS and browsers. I will send you summary of all testing using Gmail later today.? Meanwhile, so I could summarize the results in a more meaningful manner, can you tell me some implementational differences between 1. bind-tcp (with ssl=*) and bind-ssl.2. the differences between ssl=Mode switches. Somehow they aren't very intuitive for me.?3. Is ssl encryption/protocol used between client and websockify Webserver only or is it also used between XPRA server socket and websockify as well? Thanks! Mukul Sent from Yahoo Mail on Android On Tue, Jan 3, 2017 at 1:01 AM, Antoine Martin via shifter-users wrote: On 03/01/17 02:39, Mukul Agrawal via shifter-users wrote: > OK, I tried something slightly different. I removed the "ssl=https" (seems like I was not reading the wiki on https://xpra.org/trac/ticket/1213 correctly). > Here is what I did :- Please always include all the details: the full OS version, the full xpra version, the full command or log output, the browser you used, etc. And you really should be testing with more than one browser. Since you are using a signed certificate, you should include how you generated the full chain. What CA you used, etc You may also want to enable "-d websocket,http" Or even adding "-d network" (this may be too verbose) Also, please try using a better email service. Yahoo makes a complete mess of the text formatting and your emails are a pain to parse. (and that's just one of many reasons to stay away from Yahoo) > xpra start :17 --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=./fullchain.pem --ssl-key=./privkey.pem --start=xclock > =>? Simply hit the https://hostname.com. Web-browser says Secure Connection Failed. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.=> XPRA log is showing:- Error: error in network packet reading/parsing^[[0m ^[[31m2017-01-02 19:11:15,446 invalid_header() takes exactly 3 arguments (4 given) Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 682, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 725, in do_read_parse_thread_loop=> openssl s_client -connect host:443 -- this is showing ssl is connect and is working fine > Any idea why browser is not connecting? Do I need to provide some parameters on the address line on the browser? No. If openssl connects OK, so should the browser AFAIK. Cheers Antoine > > >? Regards, > Mukul >? > >? ? On Monday, January 2, 2017 5:20 PM, Mukul Agrawal via shifter-users wrote: >? > >? I got a commercial SSL certificate installed on my ubuntu xenial machine.I tested the setup using a simple "Hello World" python https server. Everything is woorking good. I can hit the index page using https from anywhere from outside world.Also checked with "openssl s_client -connect" and it confiorms that certificate is using used properly. > Now I started the xpra server following instructions here - > Encryption/SSL ? Xpra > >? > |? > |? > |? > |? |? ? | > >? | > >? | > |? > |? |? > Encryption/SSL ? Xpra >? xpra - screen for X? |? | > >? | > >? | > >? > > Used following command :- > xpra start :17 --start=xclock --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=/path/to/fullchain.pem --ssl-key=/ > path/to/privatekey.pem ssl=https > > Now if I hit the webaddress from webbrowser with https, I get following error on browser ;- > SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG > > "openssl s_client -connect" is showing "connected" but giving an error? 140770FC:SSL rountines:SSL23_GET_SERVER_HELLO:unknown_protocol:s23_clnt.c:794: > > XPRA server logs are showing "invalid packet header, SSL packet?" > > Any idea what is going on?I am doing iptable routing from 443 to 3001. This works just fine with the above mentioned "Hello World" python https server. It seems to me there is some problem with websockify's webserver is trying to attach certificates to wrong port or network interface. Any advice on how to debug this? > >? Regards, > Mukul > > > >? > >? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > >? ? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list shifter-users at lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users From mukulagrawal78 at yahoo.com Tue Jan 3 18:00:10 2017 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Tue, 3 Jan 2017 18:00:10 +0000 (UTC) Subject: [winswitch] XPRA on TLS/SSL In-Reply-To: References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk> <1e61d82e-cbe3-658c-e75b-641e9153adba@nagafix.co.uk> <1097677634.1209542.1482529628422@mail.yahoo.com> <3f4cf197-6673-4934-4d38-899751994df5@nagafix.co.uk> <677559647.4418560.1483141563904@mail.yahoo.com> <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> <762452944.5353687.1483377633389@mail.yahoo.com> <1231418285.5451936.1483385976791@mail.yahoo.com> Message-ID: <1496833402.6024049.1483466410201@mail.yahoo.com> Antoine: Sorry for the trouble with Yahoo. I did test lots of client OS and browsers. I will send you summary of all testing using Gmail later today.? Meanwhile, so I could summarize the results in a more meaningful manner, can you tell me some implementational differences between 1. bind-tcp (with ssl=*) and bind-ssl.2. the differences between ssl=Mode switches. Somehow they aren't very intuitive for me.?3. Is ssl encryption/protocol used between client and websockify Webserver only or is it also used between XPRA server socket and websockify as well? Thanks! Mukul Sent from Yahoo Mail on Android On Tue, Jan 3, 2017 at 1:01 AM, Antoine Martin via shifter-users wrote: On 03/01/17 02:39, Mukul Agrawal via shifter-users wrote: > OK, I tried something slightly different. I removed the "ssl=https" (seems like I was not reading the wiki on https://xpra.org/trac/ticket/1213 correctly). > Here is what I did :- Please always include all the details: the full OS version, the full xpra version, the full command or log output, the browser you used, etc. And you really should be testing with more than one browser. Since you are using a signed certificate, you should include how you generated the full chain. What CA you used, etc You may also want to enable "-d websocket,http" Or even adding "-d network" (this may be too verbose) Also, please try using a better email service. Yahoo makes a complete mess of the text formatting and your emails are a pain to parse. (and that's just one of many reasons to stay away from Yahoo) > xpra start :17 --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=./fullchain.pem --ssl-key=./privkey.pem --start=xclock > =>? Simply hit the https://hostname.com. Web-browser says Secure Connection Failed. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.=> XPRA log is showing:- Error: error in network packet reading/parsing^[[0m ^[[31m2017-01-02 19:11:15,446 invalid_header() takes exactly 3 arguments (4 given) Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 682, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 725, in do_read_parse_thread_loop=> openssl s_client -connect host:443 -- this is showing ssl is connect and is working fine > Any idea why browser is not connecting? Do I need to provide some parameters on the address line on the browser? No. If openssl connects OK, so should the browser AFAIK. Cheers Antoine > > >? Regards, > Mukul >? > >? ? On Monday, January 2, 2017 5:20 PM, Mukul Agrawal via shifter-users wrote: >? > >? I got a commercial SSL certificate installed on my ubuntu xenial machine.I tested the setup using a simple "Hello World" python https server. Everything is woorking good. I can hit the index page using https from anywhere from outside world.Also checked with "openssl s_client -connect" and it confiorms that certificate is using used properly. > Now I started the xpra server following instructions here - > Encryption/SSL ? Xpra > >? > |? > |? > |? > |? |? ? | > >? | > >? | > |? > |? |? > Encryption/SSL ? Xpra >? xpra - screen for X? |? | > >? | > >? | > >? > > Used following command :- > xpra start :17 --start=xclock --bind-tcp=0.0.0.0:3001 --ssl=on --ssl-cert=/path/to/fullchain.pem --ssl-key=/ > path/to/privatekey.pem ssl=https > > Now if I hit the webaddress from webbrowser with https, I get following error on browser ;- > SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG > > "openssl s_client -connect" is showing "connected" but giving an error? 140770FC:SSL rountines:SSL23_GET_SERVER_HELLO:unknown_protocol:s23_clnt.c:794: > > XPRA server logs are showing "invalid packet header, SSL packet?" > > Any idea what is going on?I am doing iptable routing from 443 to 3001. This works just fine with the above mentioned "Hello World" python https server. It seems to me there is some problem with websockify's webserver is trying to attach certificates to wrong port or network interface. Any advice on how to debug this? > >? Regards, > Mukul > > > >? > >? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > >? ? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list shifter-users at lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed Jan 4 09:20:44 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 4 Jan 2017 16:20:44 +0700 Subject: [winswitch] XPRA on TLS/SSL In-Reply-To: <1496833402.6024049.1483466410201@mail.yahoo.com> References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk> <1e61d82e-cbe3-658c-e75b-641e9153adba@nagafix.co.uk> <1097677634.1209542.1482529628422@mail.yahoo.com> <3f4cf197-6673-4934-4d38-899751994df5@nagafix.co.uk> <677559647.4418560.1483141563904@mail.yahoo.com> <412d08cc-6b6b-1cc0-beaa-7ff237c997b4@nagafix.co.uk> <762452944.5353687.1483377633389@mail.yahoo.com> <1231418285.5451936.1483385976791@mail.yahoo.com> <1496833402.6024049.1483466410201@mail.yahoo.com> Message-ID: <24ac2dc6-ed02-552e-f4fc-448a80ae3ef8@nagafix.co.uk> On 04/01/17 01:00, Mukul Agrawal wrote: > Antoine: Sorry for the trouble with Yahoo. I did test lots of client OS > and browsers. I will send you summary of all testing using Gmail later > today. > > Meanwhile, so I could summarize the results in a more meaningful manner, > can you tell me some implementational differences between 1. bind-tcp > (with ssl=*) and bind-ssl. TCP: bind-tcp creates TCP sockets which can be upgraded to SSL if you enable it (ssl=on flag) and if the client connects using SSL. These sockets can also be used for the built-in webserver (http) and for websockets connections if you enable it (html=on). See "ssl" flag. SSL: bind-ssl sockets can only be used with a client that connects using SSL. Be it a browser with https or a regular client with a "ssl/HOST:PORT/" connection string. If you are going to be using SSL, I recommend using a dedicated port for it. This may avoid some of the issues with the protocol arbitration logic. > 2. the differences between ssl=Mode switches. Somehow they aren't very > intuitive for me. This is covered in the manual, here is the changeset that added it: https://xpra.org/trac/changeset/13610 For more information on this small limitation, see: https://xpra.org/trac/ticket/1213#comment:3 > 3. Is ssl encryption/protocol used between client and websockify > Webserver only or is it also used between XPRA server socket and > websockify as well? There is no connection between xpra and websockify. Websockify runs embedded in the xpra server as a transport layer. Cheers Antoine > Thanks! > > Mukul > > Sent from Yahoo Mail on Android > > > On Tue, Jan 3, 2017 at 1:01 AM, Antoine Martin via shifter-users > wrote: > > On 03/01/17 02:39, Mukul Agrawal via shifter-users wrote: > > OK, I tried something slightly different. I removed the > "ssl=https" (seems like I was not reading the wiki on > https://xpra.org/trac/ticket/1213 correctly). > > Here is what I did :- > Please always include all the details: the full OS version, the full > xpra version, the full command or log output, the browser you used, etc. > And you really should be testing with more than one browser. > > Since you are using a signed certificate, you should include how you > generated the full chain. What CA you used, etc > > You may also want to enable "-d websocket,http" > Or even adding "-d network" (this may be too verbose) > > Also, please try using a better email service. Yahoo makes a complete > mess of the text formatting and your emails are a pain to parse. > (and that's just one of many reasons to stay away from Yahoo) > > > xpra start :17 --bind-tcp=0.0.0.0:3001 --ssl=on > --ssl-cert=./fullchain.pem --ssl-key=./privkey.pem --start=xclock > > => Simply hit the https://hostname.com. Web-browser says Secure > Connection Failed. The page you are trying to view cannot be shown > because the authenticity of the received data could not be > verified.=> XPRA log is showing:- Error: error in network packet > reading/parsing^[[0m ^[[31m2017-01-02 19:11:15,446 invalid_header() > takes exactly 3 arguments (4 given) Traceback (most recent call > last): File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", > line 682, in _read_parse_thread_loop > self.do_read_parse_thread_loop() File > "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 725, > in do_read_parse_thread_loop=> openssl s_client -connect host:443 -- > this is showing ssl is connect and is working fine > > Any idea why browser is not connecting? Do I need to provide some > parameters on the address line on the browser? > No. > If openssl connects OK, so should the browser AFAIK. > > Cheers > Antoine > > > > > > > > Regards, > > Mukul > > > > > > On Monday, January 2, 2017 5:20 PM, Mukul Agrawal via > shifter-users > wrote: > > > > > > I got a commercial SSL certificate installed on my ubuntu xenial > machine.I tested the setup using a simple "Hello World" python https > server. Everything is woorking good. I can hit the index page using > https from anywhere from outside world.Also checked with "openssl > s_client -connect" and it confiorms that certificate is using used > properly. > > Now I started the xpra server following instructions here - > > Encryption/SSL ? Xpra > > > > > > | > > | > > | > > | | | > > > > | > > > > | > > | > > | | > > Encryption/SSL ? Xpra > > xpra - screen for X | | > > > > | > > > > | > > > > > > > > Used following command :- > > xpra start :17 --start=xclock --bind-tcp=0.0.0.0:3001 --ssl=on > --ssl-cert=/path/to/fullchain.pem --ssl-key=/ > > path/to/privatekey.pem ssl=https > > > > Now if I hit the webaddress from webbrowser with https, I get > following error on browser ;- > > SSL received a record that exceeded the maximum permissible > length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG > > > > "openssl s_client -connect" is showing "connected" but giving an > error 140770FC:SSL > rountines:SSL23_GET_SERVER_HELLO:unknown_protocol:s23_clnt.c:794: > > > > XPRA server logs are showing "invalid packet header, SSL packet?" > > > > Any idea what is going on?I am doing iptable routing from 443 to > 3001. This works just fine with the above mentioned "Hello World" > python https server. It seems to me there is some problem with > websockify's webserver is trying to attach certificates to wrong > port or network interface. Any advice on how to debug this? > > > > Regards, > > Mukul > > > > > > > > > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From me.xpra at cgf.cx Wed Jan 4 17:20:09 2017 From: me.xpra at cgf.cx (Christopher Faylor) Date: Wed, 4 Jan 2017 12:20:09 -0500 Subject: [winswitch] Loss of focus and screen refresh when switching between work spaces Message-ID: <20170104172009.GA5477@ednor.casa.cgf.cx> Hi, I am running xpra on a Fedora 24 system, using it to run "pidgin" so that I can keep the client alive between home and work. pidgin consists of two windows: a Buddy window and the main chat window which has multiple tabs for different conversations. I run pidgin on a Gentoo system on workspace 2. The xpra version is: xpra-1.0-2.fc24.armv7hl . The Gentoo system is running xpra-0.17.6. My problem is that, whenever I switch away from the workspace, the chat window stops updating and I lose the ability to type anything in it when I switch back. The buddy window still remains active and, in fact, when selecting the chat window, anything I type goes to the buddy window. I do have things set up so that the buddy window doesn't show anything on the taskbar. I only have the chat window icon on the taskbar. If I toggle the "OpenGL" setting from the Xpra icon I can get back proper behavior in the chat window until the next time I switch from the workspace. If it matters: pidgin-2.11.0-1.fc24.armv7hl I would appreciate any insight into how to fix this problem. Thanks. From mark.attard at imperial.ac.uk Wed Jan 4 14:51:31 2017 From: mark.attard at imperial.ac.uk (Attard, Mark I) Date: Wed, 4 Jan 2017 14:51:31 +0000 Subject: [winswitch] xpra Message-ID: Hi, Apologies if this email is misdirected, in which case can you point me in the right direction please? I am having a new problem with xpra that I never had before: xpra attach :7 2017-01-04 14:27:58,278 Xpra gtk2 client version 1.0 64-bit 2017-01-04 14:27:58,381 running on Linux RedHatEnterpriseWorkstation 6.6 Santiago 2017-01-04 14:27:58,383 Warning: failed to import opencv: 2017-01-04 14:27:58,383 No module named cv2 2017-01-04 14:27:58,384 webcam forwarding is disabled 2017-01-04 14:27:59,469 GStreamer version 0.10.29 for Python 2.6.6 64-bit Gdk-ERROR **: The program 'xpra' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 332 error_code 2 request_code 154 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... Aborted (core dumped) Any help will be greatly appreciated thanks. All the best for the New year, Mark From antoine at nagafix.co.uk Wed Jan 4 18:09:49 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Jan 2017 01:09:49 +0700 Subject: [winswitch] Loss of focus and screen refresh when switching between work spaces In-Reply-To: <20170104172009.GA5477@ednor.casa.cgf.cx> References: <20170104172009.GA5477@ednor.casa.cgf.cx> Message-ID: <973360d4-7e18-8771-4c92-3f5fae0300ca@nagafix.co.uk> On 05/01/17 00:20, Christopher Faylor via shifter-users wrote: > Hi, > I am running xpra on a Fedora 24 system, using it to run "pidgin" so > that I can keep the client alive between home and work. pidgin consists > of two windows: a Buddy window and the main chat window which has multiple > tabs for different conversations. I run pidgin on a Gentoo system on > workspace 2. The xpra version is: xpra-1.0-2.fc24.armv7hl . > > The Gentoo system is running xpra-0.17.6. What is your desktop environment? > My problem is that, whenever I switch away from the workspace, the chat > window stops updating and I lose the ability to type anything in it when > I switch back. Sounds like the code detects the change in workspace but not the switch back to that workspace. You may have to create a ticket so we can fix this. You can try running the client with "-d workspace" to get more information. ("-d window" may also have some extra details) > The buddy window still remains active and, in fact, when selecting the > chat window, anything I type goes to the buddy window. I do have things > set up so that the buddy window doesn't show anything on the taskbar. I > only have the chat window icon on the taskbar. > > If I toggle the "OpenGL" setting from the Xpra icon I can get back > proper behavior in the chat window until the next time I switch from the > workspace. Toggling OpenGL will re-create the window, which will also re-map it. It effectively re-starts from scratch. Does minimizing the window and then unminimizing it also fix things? > If it matters: pidgin-2.11.0-1.fc24.armv7hl What's your DE? > I would appreciate any insight into how to fix this problem. Cheers Antoine > > Thanks. From antoine at nagafix.co.uk Wed Jan 4 18:15:08 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Jan 2017 01:15:08 +0700 Subject: [winswitch] xpra In-Reply-To: References: Message-ID: On 04/01/17 21:51, Attard, Mark I via shifter-users wrote: > Hi, > > Apologies if this email is misdirected, in which case can you point me in the right direction please? This is the right place. > I am having a new problem with xpra that I never had before: > > > xpra attach :7 > 2017-01-04 14:27:58,278 Xpra gtk2 client version 1.0 64-bit > 2017-01-04 14:27:58,381 running on Linux RedHatEnterpriseWorkstation 6.6 Santiago > 2017-01-04 14:27:58,383 Warning: failed to import opencv: > 2017-01-04 14:27:58,383 No module named cv2 > 2017-01-04 14:27:58,384 webcam forwarding is disabled > 2017-01-04 14:27:59,469 GStreamer version 0.10.29 for Python 2.6.6 64-bit > > Gdk-ERROR **: The program 'xpra' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadValue (integer parameter out of range for operation)'. > (Details: serial 332 error_code 2 request_code 154 minor_code 3) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > aborting... > Aborted (core dumped) Ouch. That's bad :( Strange thing is that I am not seeing this at all with CentOS 6.6, which should behave exactly the same as RHEL 6.6. > Any help will be greatly appreciated thanks. Please attach gdb to your client process and try to get a backtrace when it crashes. http://xpra.org/trac/wiki/Debugging#GDB It may also be helpful to include the last few lines of the client output when run with "-d all". Then there's also the usual suspects: try turning off opengl, clipboard, etc. Cheers Antoine > All the best for the New year, > Mark From me.xpra at cgf.cx Wed Jan 4 18:56:28 2017 From: me.xpra at cgf.cx (Christopher Faylor) Date: Wed, 4 Jan 2017 13:56:28 -0500 Subject: [winswitch] Loss of focus and screen refresh when switching between work spaces In-Reply-To: <973360d4-7e18-8771-4c92-3f5fae0300ca@nagafix.co.uk> References: <20170104172009.GA5477@ednor.casa.cgf.cx> <973360d4-7e18-8771-4c92-3f5fae0300ca@nagafix.co.uk> Message-ID: <20170104185628.GA7795@ednor.casa.cgf.cx> On Thu, Jan 05, 2017 at 01:09:49AM +0700, Antoine Martin via shifter-users wrote: >On 05/01/17 00:20, Christopher Faylor via shifter-users wrote: >> Hi, >> I am running xpra on a Fedora 24 system, using it to run "pidgin" so >> that I can keep the client alive between home and work. pidgin consists >> of two windows: a Buddy window and the main chat window which has multiple >> tabs for different conversations. I run pidgin on a Gentoo system on >> workspace 2. The xpra version is: xpra-1.0-2.fc24.armv7hl . >> >> The Gentoo system is running xpra-0.17.6. >What is your desktop environment? Gentoo xfce. >> My problem is that, whenever I switch away from the workspace, the chat >> window stops updating and I lose the ability to type anything in it when >> I switch back. >Sounds like the code detects the change in workspace but not the switch >back to that workspace. >You may have to create a ticket so we can fix this. Opened. Ticket #1396. >You can try running the client with "-d workspace" to get more >information. ("-d window" may also have some extra details) Attached to ticket. >> The buddy window still remains active and, in fact, when selecting the >> chat window, anything I type goes to the buddy window. I do have things >> set up so that the buddy window doesn't show anything on the taskbar. I >> only have the chat window icon on the taskbar. >> >> If I toggle the "OpenGL" setting from the Xpra icon I can get back >> proper behavior in the chat window until the next time I switch from the >> workspace. >Toggling OpenGL will re-create the window, which will also re-map it. >It effectively re-starts from scratch. Right. >Does minimizing the window and then unminimizing it also fix things? Actually, the window won't minimize. It blinks and maintains the same behavior. Using XFCE's "fullscreen" mode, seemed to make it work once, though. The second attempt resulted in a black screen. Reconnecting to the server got it back. cgf From antoine at nagafix.co.uk Sat Jan 7 09:38:00 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 7 Jan 2017 16:38:00 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 1.0 Message-ID: Hi, Xpra version 1.0.x is here. * New Features: Despite the focus on stability for this new LTS release, it does contain a large number of exciting new features, for more information please see this summary: http://xpra.org/trac/wiki/News#a1.0ImportantFeatures Here's are some of the short keywords: SSL, default TCP port, system proxy service, desktop mode, grabs, scrolling, 10-bit colours.. * Version Numbering: We are finally moving to a 1.0 stable version number because Xpra has been used in production for years and this will be our most stable version yet. It is time. Many thanks to those who spent so much time testing and exposing all those corner cases. In particular, I would like to single out Alex Farr and Max Mena for their contribution to the project. * Future Versions: The 1.0.x branch will be supported for a minimum of 2 years, possibly more. The 0.14.x LTS branch may still also receive one or two updates, but it will be discontinued before long - time to move on. The next release after this one will be version 2.0, that version will mostly be a cleanup of the current codebase as we drop compatibility for a lot of outdated technologies (ie: Windows XP, Python 2.6, etc), see: http://xpra.org/trac/milestone/2.0 If there are important features in later versions that warrant it, we may create a new 1.1 branch with those limited features backported - for those unable to move to newer operating systems. (ie: CentOS 6.x) * Participate: Now is the ideal time to submit your ideas and feature requests for the next milestones. You can also help with the new logo, adding your feedback here: http://xpra.org/trac/ticket/1342#comment:3 (as this didn't make the cut for the 1.0 release) The source: https://xpra.org/src/ Direct binary downloads: https://xpra.org/dists/ Binaries/repositories: https://winswitch.org/downloads/ Cheers Antoine PS: this email was meant to be sent exactly one month ago but has been sitting in my outbox since then, here it is at last. Version 1.0.1 is actually available now, a separate announcement will follow. From antoine at nagafix.co.uk Sat Jan 7 10:42:36 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 7 Jan 2017 17:42:36 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 1.0.1 (many fixes) Message-ID: <78efc90a-6995-d453-1a36-16130d562b79@nagafix.co.uk> Hi, The first stable update to the 1.0 LTS branch is here and it includes a large number of fixes. Although none of these fixes are really critical, updating is strongly recommended. Release notes - only fixes: * mousewheel events position with MS Windows clients * compatibility with newer versions of pyobjc * race condition in "xpra info" window handler * html5 client ignoring paint errors * Mac OS bell with newer OS versions * spurious warning: "disabled" is a valid clipboard direction * setting of "xpra" group for shared sockets * html5 client auto-connect * ssh to default port 22: don't specify the port * sound error handling cases * don't use XDG_RUNTIME_DIR for xpra script on Ubuntu 14.04 * window minimization with some window managers * multi-monitor maximize with MS Windows clients * system tray cleanup race condition error * suse RPM packaging * missing shell expansion in "env" command line options * transparency warning with newer versions of Pillow * firewall messages during RPM post (un)install * html5 build flag not being honoured * installations without the service files * xvfb example syntax in config file * syntax error in webp codec * html5 printer forwarding * mmap-group option * Xorg and config path detection with Arch Linux * exit-with-children option * file left over after running clean build target * duplicated websocket logging category * dbus server errors with display names containing dots * encoding quality tray tooltip message when disabled by mmap * systray forwarding window position The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine From sadatakhavi.ali at gmail.com Sun Jan 8 00:53:05 2017 From: sadatakhavi.ali at gmail.com (Ali Sadat) Date: Sun, 8 Jan 2017 11:53:05 +1100 Subject: [winswitch] Xpra - Docker - Assistance request Message-ID: Hi, I appreciate if you could assist me with the following question regarding use of xpra inside Docker containers. As a part of one of my projects, I have to use xpra inside runc\docker containers to access GUI apps. (I understand this is not the best practice) Xpra works perfectly inside containers, until I have to checkpoint and restore the container. It seems CRIU does not like the concept of unix-sockets inside containers and requires special IPC to be created between processes. I tried to follow the instructions provided by CRIU for VNC in link below. However, could not get xpra to work. https://criu.org/VNC Tried other approaches too eg: SSH, TCP and... to avoid use of Display sockets, but there was not much success there either. I am really stuck !!! and I am just wondering if you can help me with this or point me toward the right direction. Is there any way to create an IPC been xpra and application inside container ? or exit xpra session before checkpoint and reconnect to exit-ed session after restore ? or... Thanks Ali From antoine at nagafix.co.uk Sun Jan 8 07:19:59 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 8 Jan 2017 14:19:59 +0700 Subject: [winswitch] Xpra - Docker - Assistance request In-Reply-To: References: Message-ID: <7a83e528-10b6-b21f-85d9-1692766530cc@nagafix.co.uk> On 08/01/17 07:53, Ali Sadat via shifter-users wrote: > Hi, > > > I appreciate if you could assist me with the following question regarding > use of xpra inside Docker containers. > > As a part of one of my projects, I have to use xpra inside runc\docker > containers to access GUI apps. (I understand this is not the best practice) What makes you think that this is not "the best practice"? > Xpra works perfectly inside containers, until I have to checkpoint and > restore the container. It seems CRIU does not like the concept of > unix-sockets inside containers and requires special IPC to be created > between processes. Then I'm not sure how you expect the X11 client applications to survive the checkpoint and restore. And this would affect VNC the same way. All X11 applications usually connect to the X11 server using unix domain sockets (see /tmp/.X11-unix/. You could try switching them to TCP sockets if that is better supported by the checkpoint code. > I tried to follow the instructions provided by CRIU for > VNC in link below. However, could not get xpra to work. Please always try to provide details and in particular the specific errors you encounter. "does not work" is not it. > https://criu.org/VNC This seems to be using regular displays with unix domain sockets. So you will really need to clarify the problem(s) you encounter, and the CRIU issues, if any, with the sockets. > Tried other approaches too eg: SSH, TCP and... to avoid use of Display > sockets, but there was not much success there either. Xpra is a client of the X11 server (Xdummy or Xvfb), so it will also connect using unix domain sockets. > I am really stuck !!! and I am just wondering if you can help me with this > or point me toward the right direction. If it helps to use TCP sockets instead of unix domain sockets, then you can try versions newer than this changeset: https://xpra.org/trac/changeset/14729 And connect xpra to the X11 server using TCP. Something like this (here for Fedora 25): /usr/libexec/Xorg -noreset \ -nolisten unix -listen tcp \ +extension GLX +extension RANDR +extension RENDER \ -logfile /run/user/1000/xpra/Xorg.100.log \ -configdir /home/antoine/.xpra/xorg.conf.d \ -config /etc/xpra/xorg.conf :100 & xpra start \ --bind=none --bind-tcp=0.0.0.0: \ --no-daemon --start=xterm \ --use-display 127.0.0.1:100 > Is there any way to create an IPC been xpra and application inside > container ? Not sure what you mean. > or exit xpra session before checkpoint and reconnect to exit-ed > session after restore ? or... I don't see why that wouldn't work. Cheers Antoine > > Thanks > > Ali > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From timothy at hobbs.cz Sun Jan 8 10:15:54 2017 From: timothy at hobbs.cz (Timothy Hobbs) Date: Sun, 8 Jan 2017 11:15:54 +0100 Subject: [winswitch] Xpra - Docker - Assistance request In-Reply-To: References: Message-ID: Hello, I'm the author of a project called subuser.org which helps users install and use GUI applications in Docker. We use XPRA, but we don't do CRIU and don't plan on it either. In my experience, there using XPRA with containers isn't bad practice, I'm not sure where you heard that from. It works quite well actually. In order to securely provide access to the X11 server, I have subuser set up to use a 3 container per application approach which is described here http://subuser.org/news/0.3.html#the-xpra-x11-bridge . I presume you currently have it set up so that the XPRA server runs in the same container as the GUI application? Is your trouble then that the UNIX sockets INSIDE the container don't work? Aka the applications connection to the xpra server via the /tmp/.X11-unix socket? Or is the trouble with the socket that connects the xpra server to the xpra client? If you're running into the former case then I think you have no hope of using CRIU for anything usefull untill such a severe bug is fixed :(. If it is the later, then I think we might be able to find some workarounds, such as detaching the xpra client before freezing and then reattaching it afterwards. On 01/08/2017 01:53 AM, Ali Sadat via shifter-users wrote: > Hi, > > > I appreciate if you could assist me with the following question regarding > use of xpra inside Docker containers. > > As a part of one of my projects, I have to use xpra inside runc\docker > containers to access GUI apps. (I understand this is not the best practice) > > Xpra works perfectly inside containers, until I have to checkpoint and > restore the container. It seems CRIU does not like the concept of > unix-sockets inside containers and requires special IPC to be created > between processes. I tried to follow the instructions provided by CRIU for > VNC in link below. However, could not get xpra to work. > > https://criu.org/VNC > > Tried other approaches too eg: SSH, TCP and... to avoid use of Display > sockets, but there was not much success there either. > > I am really stuck !!! and I am just wondering if you can help me with this > or point me toward the right direction. > > Is there any way to create an IPC been xpra and application inside > container ? or exit xpra session before checkpoint and reconnect to exit-ed > session after restore ? or... > > Thanks > > Ali > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From dougdoole at gmail.com Thu Jan 12 21:37:13 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Thu, 12 Jan 2017 21:37:13 +0000 Subject: [winswitch] No menu bar in Ubuntu Message-ID: I'm using xpra 1.0.1 (also saw this on 1.0) on a Ubuntu 14.04.5 system. Most of the time I'm running it in loopback mode. xpra start :10 xpra attach ssh:localhost:10 When I do this, however, I don't see the menu bars for my applications (gvim and eclipse being my most commonly used). All the menu bar at the top of the screen says is "attachXpra" If I attach from my MacBook, then I see menu bars. (The menu bars are in each window instead of at the top of the screen, and there's a generic Xpra menu at the top of the screen. That's fine by me.) So it looks like the xpra server is aware of the menu bars, but the Ubuntu client isn't showing them. Is there some setting I'm missing? Thanks. - Doug From rajaiyer at LIVE.COM Fri Jan 13 15:42:45 2017 From: rajaiyer at LIVE.COM (R V) Date: Fri, 13 Jan 2017 15:42:45 +0000 Subject: [winswitch] Xpra attach resolution issue Message-ID: Dear all I have a problem with using Xpra attach. Xpra is running on a linux cluster in a different city and I am using xpra attach to view the window locally. However, I have some issues changing the resolution of the window. I have three windows 1) laptop 1366x768 2) Mon1 1280x1024 3) Mon2 1920x1080 If all the monitors are connected, the resolution is not as good.. (aka. for e.g. only 10 rows x 10 columns on full screen window). However, if I first disable the monitors and just use my laptop and then start viewing the window and then add the monitors, I am able to see much more ( eg. 15 rows x 15 columns). It is annoying that I have to disable the monitors every time I need to use this window. Is there a way out. What I have tried the following options till now with xpra attach --dpi=32,96 ??xsettings=yes|no ??video?scaling=on|offSCALING None of these help. Any ideas ? Thanks AreEye Sent from Outlook From antoine at nagafix.co.uk Fri Jan 13 16:30:35 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 13 Jan 2017 23:30:35 +0700 Subject: [winswitch] Xpra attach resolution issue In-Reply-To: References: Message-ID: <4ae96cb1-b486-6b71-6c53-733bd6fb43f3@nagafix.co.uk> On 13/01/17 22:42, R V via shifter-users wrote: > Dear all > > > I have a problem with using Xpra attach. Xpra is running on a linux cluster in a different city and I am using xpra attach to view the window locally. However, I have some issues changing the resolution of the window. I don't understand what "changing the resolution of the window" means. > I have three windows I guess you mean screens or monitors then? > 1) laptop 1366x768 > > 2) Mon1 1280x1024 > > 3) Mon2 1920x1080 > > > If all the monitors are connected, the resolution is not as good.. (aka. for e.g. only 10 rows x 10 columns on full screen window). Please define "the resolution is not as good". 10 rows of what? What application? > However, if I first disable the monitors and just use my laptop and then start viewing the window and then add the monitors, I am able to see much more ( eg. 15 rows x 15 columns). It is annoying that I have to disable the monitors every time I need to use this window. Is there a way out. > > > What I have tried the following options till now with xpra attach > > --dpi=32,96 FYI: dpi may not work on all distributions. Not sure what your distro is. > ??xsettings=yes|no > > ??video?scaling=on|offSCALING > > > None of these help. Any ideas ? Maybe try turning off desktop-scaling? Cheers Antoine > Thanks > > AreEye > > > Sent from Outlook > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From rajaiyer at LIVE.COM Fri Jan 13 18:38:13 2017 From: rajaiyer at LIVE.COM (R V) Date: Fri, 13 Jan 2017 18:38:13 +0000 Subject: [winswitch] Xpra attach resolution issue In-Reply-To: References: Message-ID: Thanks Antoine desktop-scaling option seems to do the trick. This is cool. Feels so much better. -- AreEye Sent from Outlook ________________________________ From: R V Sent: Friday, January 13, 2017 9:42 AM To: shifter-users at lists.devloop.org.uk Subject: Xpra attach resolution issue Dear all I have a problem with using Xpra attach. Xpra is running on a linux cluster in a different city and I am using xpra attach to view the window locally. However, I have some issues changing the resolution of the window. I have three windows 1) laptop 1366x768 2) Mon1 1280x1024 3) Mon2 1920x1080 If all the monitors are connected, the resolution is not as good.. (aka. for e.g. only 10 rows x 10 columns on full screen window). However, if I first disable the monitors and just use my laptop and then start viewing the window and then add the monitors, I am able to see much more ( eg. 15 rows x 15 columns). It is annoying that I have to disable the monitors every time I need to use this window. Is there a way out. What I have tried the following options till now with xpra attach --dpi=32,96 ??xsettings=yes|no ??video?scaling=on|offSCALING None of these help. Any ideas ? Thanks AreEye Sent from Outlook From lukashaase at gmx.at Mon Jan 16 21:25:01 2017 From: lukashaase at gmx.at (Lukas Haase) Date: Mon, 16 Jan 2017 22:25:01 +0100 Subject: [winswitch] fakeXinerama questions Message-ID: Hi, I have some questions regarding fakeXinerama. I use it in the following setup: 1.) Client is a Win 10 laptop with 3 monitors attached: 1366x768 1920x1200 1920x1080 2.) Ubuntu LTS Xenial Xerus with xpra running xpra. On the xpra server, I do not start the X client directly but use DISPLAY=:100 ssh -X otherserver 3.) otherserver is a RHEL5 linux system that runs proprietory software Stated differently, I use xpra as a terminal server. Now if I want to use fakeXinerama, would I use it on the xpra server (preload it into ssh) or on the RHEL5 server (preload it into the proprietory applications) or would it not work at all? My second question is regarding fakeXInerama in general. I still do not 100% understand what it really does. Which advantage does it give to me in the setup above? Ultimately what I could love is to let xpra IGNORE the first monitor (1366x768) and make it ONLY use the second two (1920x1200, 1920x1080). I tried creating .100-fakexinerama with the following content (on the xpra server and starting xterm rather than "ssh -X"): # 2 monitors: 2 # DISPLAY1 0 0 1920 1200 # DISPLAY2 1920 0 1920 1080 However, I do not see any differences. Does this even do what I want and if yes, what is the correct format? Thanks! Lukas From antoine at nagafix.co.uk Tue Jan 17 16:20:13 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 17 Jan 2017 23:20:13 +0700 Subject: [winswitch] fakeXinerama questions In-Reply-To: References: Message-ID: <110ec2c0-9263-b4f6-da7c-e814ef618363@nagafix.co.uk> On 17/01/17 04:25, Lukas Haase via shifter-users wrote: > Hi, > > I have some questions regarding fakeXinerama. I use it in the following setup: > > 1.) Client is a Win 10 laptop with 3 monitors attached: > 1366x768 1920x1200 1920x1080 > > 2.) Ubuntu LTS Xenial Xerus with xpra running xpra. > On the xpra server, I do not start the X client directly but use DISPLAY=:100 ssh -X otherserver Do not use: DISPLAY=:100 THECOMMAND always use this form instead: xpra --start=THECOMMAND As this will survive if the connection is severed and ensure that the environment is correct for the DISPLAY. There is more to it than just $DISPLAY, for example: preloading fakeXinerama.. > 3.) otherserver is a RHEL5 linux system that runs proprietory software > > Stated differently, I use xpra as a terminal server. > Now if I want to use fakeXinerama, would I use it on the xpra server (preload it into ssh) or on the RHEL5 server (preload it into the proprietory applications) or would it not work at all? When you run "ssh -X" the application that you start will be talking directly to the X11 server on your Ubuntu system (via the ssh tunnel), but since the application is running on a different system, in a different environment, the fakeXinerama library will not be injected. You would need to inject it by hand with LD_PRELOAD when you start your proprietary application. (that's assuming that you really need it - and you probably don't) > My second question is regarding fakeXInerama in general. I still do not 100% understand what it really does. > Which advantage does it give to me in the setup above? I assume that you've read the wiki page here: https://www.xpra.org/trac/wiki/FakeXinerama > Ultimately what I could love is to let xpra IGNORE the first monitor (1366x768) and make it ONLY use the second two (1920x1200, 1920x1080). This is not xpra's job: xpra forwards the windows to the client OS (ie: MS Windows 10 in this case), the client OS is in charge of placing the windows where it sees fit. You may be able to find a MS Windows tool that does this instead. > I tried creating .100-fakexinerama with the following content (on the xpra server and starting xterm rather than "ssh -X"): > > > # 2 monitors: > 2 > # DISPLAY1 > 0 0 1920 1200 > # DISPLAY2 > 1920 0 1920 1080 > > However, I do not see any differences. These settings would not actually match your display size and this could cause problems. If anything, IF (a big if) the application used the Xinerama data somehow, this could clamp the windows to the first two monitors instead. Also, you're not stating when you created that file - which may get overwritten when the client connects. Applications tend not to reload the Xinerama data. > Does this even do what I want and if yes, what is the correct format? No, fakeXinerama is not the solution you are looking for. Cheers Antoine > > Thanks! > Lukas > > > > > > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Wed Jan 18 03:15:32 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 18 Jan 2017 10:15:32 +0700 Subject: [winswitch] fakeXinerama questions In-Reply-To: <110ec2c0-9263-b4f6-da7c-e814ef618363@nagafix.co.uk> References: <110ec2c0-9263-b4f6-da7c-e814ef618363@nagafix.co.uk> Message-ID: (snip) >> Ultimately what I could love is to let xpra IGNORE the first monitor (1366x768) and make it ONLY use the second two (1920x1200, 1920x1080). > This is not xpra's job: xpra forwards the windows to the client OS (ie: > MS Windows 10 in this case), the client OS is in charge of placing the > windows where it sees fit. Thinking about this again, it shouldn't be too hard to implement an override for this. If you can create a ticket and follow up with some testing, we should be able to do something. Cheers Antoine > You may be able to find a MS Windows tool that does this instead. (..) From antoine at nagafix.co.uk Wed Jan 18 05:11:29 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 18 Jan 2017 12:11:29 +0700 Subject: [winswitch] fakeXinerama questions In-Reply-To: References: <110ec2c0-9263-b4f6-da7c-e814ef618363@nagafix.co.uk> Message-ID: Please always CC the list. On 18/01/17 11:48, Lukas Haase wrote: > Hi Antoine, > >> (snip) >>>> Ultimately what I could love is to let xpra IGNORE the first monitor (1366x768) and make it ONLY use the second two (1920x1200, 1920x1080). >>> This is not xpra's job: xpra forwards the windows to the client OS (ie: >>> MS Windows 10 in this case), the client OS is in charge of placing the >>> windows where it sees fit. >> Thinking about this again, it shouldn't be too hard to implement an >> override for this. >> If you can create a ticket and follow up with some testing, we should be >> able to do something. > > That would be awesome, thank you! > > But before, could you help me to understand what fakeXinerama does and how I see the results? > > For simplicity, let's assume just a normal xpra client on Win 10 with 2 monitors 1366x768 and 1920x1200 and xpra server on Ubuntu (no ssh -X). > > The application is gedit (supposedly using Xinerama according to ldd). > > How would preloading fakeXinerama change on the client side compared to not using it at all? The application (gedit in your example) may use Xinerama to get information about the monitor geometry. > How can I see the changes? That depends entirely on what the application does with that information. > As I said, I just don't see any differences on the client side, no matter which fakeXinerama settings I choose. Then the application probably doesn't use the data we gave it. The most common use-case for fakeXinerama is applications that maximize or go fullscreen, as they may choose to only do so on one monitor. > I even compiled with DEBUG so I see the messages that the client application is reading in the geometry ... but I don't see effects on the xpra client. > > Also, from the original question: I think it should be more > 2 > 1366 0 1920 1200 > 3286 0 1920 1080 > > ? Because the actual X area would be 5206x1200 with my 3 monitor setup. This configuration would split it into 2 monitors but have both of them offset by 1366 so there is no "monitor" and hence no windows should be places there. No. Don't do that. Your monitors should cover the whole display. Cheers Antoine > > Best, > Lukas > From dougdoole at gmail.com Wed Jan 18 17:29:48 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Wed, 18 Jan 2017 17:29:48 +0000 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: References: Message-ID: Any thoughts on this? I can open a bug, but I'd like to know that I'm not missing something first. Thanks. - Doug On Thu, Jan 12, 2017 at 1:37 PM Douglas Doole wrote: > I'm using xpra 1.0.1 (also saw this on 1.0) on a Ubuntu 14.04.5 system. > Most of the time I'm running it in loopback mode. > > xpra start :10 > xpra attach ssh:localhost:10 > > When I do this, however, I don't see the menu bars for my applications > (gvim and eclipse being my most commonly used). All the menu bar at the top > of the screen says is "attachXpra" > > If I attach from my MacBook, then I see menu bars. (The menu bars are in > each window instead of at the top of the screen, and there's a generic Xpra > menu at the top of the screen. That's fine by me.) > > So it looks like the xpra server is aware of the menu bars, but the Ubuntu > client isn't showing them. Is there some setting I'm missing? > > Thanks. > > - Doug > From antoine at nagafix.co.uk Wed Jan 18 17:37:32 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 19 Jan 2017 00:37:32 +0700 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: References: Message-ID: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> On 19/01/17 00:29, Douglas Doole via shifter-users wrote: > Any thoughts on this? I can open a bug, but I'd like to know that I'm not > missing something first. Sorry, forgot to reply - I wanted to test first but couldn't find the time. It's probably best to file a ticket so this doesn't get lost again. My guess is that there must be some setting that is forwarded that tells the application to not use Ubuntu's "global menu". We do have some environment variables that are set to try to turn it off, but maybe these are no longer sufficient. These environment variables will only affect commands started with: xpra start --start=THECOMMAND And not with: DISPLAY=:100 THECOMMAND Yet another reason for always using the "--start" option. Cheers Antoine > > Thanks. > > - Doug > > On Thu, Jan 12, 2017 at 1:37 PM Douglas Doole wrote: > >> I'm using xpra 1.0.1 (also saw this on 1.0) on a Ubuntu 14.04.5 system. >> Most of the time I'm running it in loopback mode. >> >> xpra start :10 >> xpra attach ssh:localhost:10 >> >> When I do this, however, I don't see the menu bars for my applications >> (gvim and eclipse being my most commonly used). All the menu bar at the top >> of the screen says is "attachXpra" >> >> If I attach from my MacBook, then I see menu bars. (The menu bars are in >> each window instead of at the top of the screen, and there's a generic Xpra >> menu at the top of the screen. That's fine by me.) >> >> So it looks like the xpra server is aware of the menu bars, but the Ubuntu >> client isn't showing them. Is there some setting I'm missing? >> >> Thanks. >> >> - Doug >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From dougdoole at gmail.com Wed Jan 18 18:37:55 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Wed, 18 Jan 2017 18:37:55 +0000 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> References: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> Message-ID: Thanks Antoine. I thought the --start was the trick I needed, but it seems I've stumbled onto something new. :-( My general model is that I have xpra running, and then I create and dispose of terminal windows as needed. Then I run commands as needed from the terminal. I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar problem. Since xpra is already running, I can't use "xpra start --start=...", so I used "xpra control :10 start gnome-terminal". This gives me a terminal window with a menu bar. Any commands I start from the terminal (gvim, eclipse) also have their menu bar. Yay! But when I try to start a second terminal using "xpra control :10 start gnome-terminal", xpra hangs. I get the title bar and border for the second window, but its contents are black. All existing windows stop responding to input. (Even the close button in the title bar is non-responsive.) The xpra icon in the systray changes from an X to the clipboard icon. (The systray icon responds normally.) Running "xpra list" shows a LIVE session. If I disconnect the client, the server still reports a LIVE session. However as soon as I try to reconnect the client the server reports it as DEAD (cleaned up). (The session is not fully cleaned up though - there are still 6 xpra related processes running, including "xpra start" and Xorg-for-Xpra". Manually killing the Xorg-for-Xpra process cleans everything up.) Any idea on this one? In the short term, I can just create my first window using xpra control start and then spawn new terminals from that. However my preferred way to work is to have a terminal icon in the launcher that I click to spawn a new terminal in xpra. - Doug On Wed, Jan 18, 2017 at 9:37 AM Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 19/01/17 00:29, Douglas Doole via shifter-users wrote: > > Any thoughts on this? I can open a bug, but I'd like to know that I'm not > > missing something first. > Sorry, forgot to reply - I wanted to test first but couldn't find the time. > It's probably best to file a ticket so this doesn't get lost again. > > My guess is that there must be some setting that is forwarded that tells > the application to not use Ubuntu's "global menu". > We do have some environment variables that are set to try to turn it > off, but maybe these are no longer sufficient. > > These environment variables will only affect commands started with: > xpra start --start=THECOMMAND > And not with: > DISPLAY=:100 THECOMMAND > Yet another reason for always using the "--start" option. > > Cheers > Antoine > > > > > Thanks. > > > > - Doug > > > > On Thu, Jan 12, 2017 at 1:37 PM Douglas Doole > wrote: > > > >> I'm using xpra 1.0.1 (also saw this on 1.0) on a Ubuntu 14.04.5 system. > >> Most of the time I'm running it in loopback mode. > >> > >> xpra start :10 > >> xpra attach ssh:localhost:10 > >> > >> When I do this, however, I don't see the menu bars for my applications > >> (gvim and eclipse being my most commonly used). All the menu bar at the > top > >> of the screen says is "attachXpra" > >> > >> If I attach from my MacBook, then I see menu bars. (The menu bars are > in > >> each window instead of at the top of the screen, and there's a generic > Xpra > >> menu at the top of the screen. That's fine by me.) > >> > >> So it looks like the xpra server is aware of the menu bars, but the > Ubuntu > >> client isn't showing them. Is there some setting I'm missing? > >> > >> Thanks. > >> > >> - Doug > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Thu Jan 19 13:40:46 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 19 Jan 2017 20:40:46 +0700 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: References: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> Message-ID: <5a696ef1-5bd3-f939-ba3a-64db90c16620@nagafix.co.uk> On 19/01/17 01:37, Douglas Doole wrote: > Thanks Antoine. > > I thought the --start was the trick I needed, but it seems I've stumbled > onto something new. :-( > > My general model is that I have xpra running, and then I create and > dispose of terminal windows as needed. Then I run commands as needed > from the terminal. > > I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar problem. > > Since xpra is already running, I can't use "xpra start --start=...", so > I used "xpra control :10 start gnome-terminal". This gives me a terminal > window with a menu bar. Any commands I start from the terminal (gvim, > eclipse) also have their menu bar. Yay! Right. Can we close this thread and start a new one? (or at least rename the thread) > But when I try to start a second terminal using "xpra control :10 start > gnome-terminal", xpra hangs. I get the title bar and border for the > second window, but its contents are black. All existing windows stop > responding to input. (Even the close button in the title bar is > non-responsive.) The xpra icon in the systray changes from an X to the > clipboard icon. (The systray icon responds normally.) Running "xpra > list" shows a LIVE session. If I disconnect the client, the server still > reports a LIVE session. However as soon as I try to reconnect the client > the server reports it as DEAD (cleaned up). (The session is not fully > cleaned up though - there are still 6 xpra related processes running, > including "xpra start" and Xorg-for-Xpra". Manually killing the > Xorg-for-Xpra process cleans everything up.) > > Any idea on this one? Yes, unfortunately. Many applications have started refusing to launch new instances when you execute them. This started with browsers, but it is now affecting other types of applications. (KDE and many recent gnome applications suffer from this) Instead of starting a new instance, they try to show a new window - still belonging to the first process that was started. Now, although this can cause the application to misbehave, it should not be able to crash the xpra server. Unfortunately, clipboard misbehaviour is an issue that is known to cause this sort of problems. I'll try to reproduce, having a ticket with details wouldn't hurt. > In the short term, I can just create my first window using xpra control > start and then spawn new terminals from that. However my preferred way > to work is to have a terminal icon in the launcher that I click to spawn > a new terminal in xpra. Not sure I understand this part. Cheers Antoine > > - Doug > > On Wed, Jan 18, 2017 at 9:37 AM Antoine Martin via shifter-users > > wrote: > > On 19/01/17 00:29, Douglas Doole via shifter-users wrote: > > Any thoughts on this? I can open a bug, but I'd like to know that > I'm not > > missing something first. > Sorry, forgot to reply - I wanted to test first but couldn't find > the time. > It's probably best to file a ticket so this doesn't get lost again. > > My guess is that there must be some setting that is forwarded that tells > the application to not use Ubuntu's "global menu". > We do have some environment variables that are set to try to turn it > off, but maybe these are no longer sufficient. > > These environment variables will only affect commands started with: > xpra start --start=THECOMMAND > And not with: > DISPLAY=:100 THECOMMAND > Yet another reason for always using the "--start" option. > > Cheers > Antoine > > > > > Thanks. > > > > - Doug > > > > On Thu, Jan 12, 2017 at 1:37 PM Douglas Doole > wrote: > > > >> I'm using xpra 1.0.1 (also saw this on 1.0) on a Ubuntu 14.04.5 > system. > >> Most of the time I'm running it in loopback mode. > >> > >> xpra start :10 > >> xpra attach ssh:localhost:10 > >> > >> When I do this, however, I don't see the menu bars for my > applications > >> (gvim and eclipse being my most commonly used). All the menu bar > at the top > >> of the screen says is "attachXpra" > >> > >> If I attach from my MacBook, then I see menu bars. (The menu > bars are in > >> each window instead of at the top of the screen, and there's a > generic Xpra > >> menu at the top of the screen. That's fine by me.) > >> > >> So it looks like the xpra server is aware of the menu bars, but > the Ubuntu > >> client isn't showing them. Is there some setting I'm missing? > >> > >> Thanks. > >> > >> - Doug > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From dougdoole at gmail.com Thu Jan 19 17:55:17 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Thu, 19 Jan 2017 17:55:17 +0000 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: <5a696ef1-5bd3-f939-ba3a-64db90c16620@nagafix.co.uk> References: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> <5a696ef1-5bd3-f939-ba3a-64db90c16620@nagafix.co.uk> Message-ID: On Thu, Jan 19, 2017 at 5:40 AM Antoine Martin wrote: > On 19/01/17 01:37, Douglas Doole wrote: > > Thanks Antoine. > > > > I thought the --start was the trick I needed, but it seems I've stumbled > > onto something new. :-( > > > > My general model is that I have xpra running, and then I create and > > dispose of terminal windows as needed. Then I run commands as needed > > from the terminal. > > > > I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar > problem. > > > > Since xpra is already running, I can't use "xpra start --start=...", so > > I used "xpra control :10 start gnome-terminal". This gives me a terminal > > window with a menu bar. Any commands I start from the terminal (gvim, > > eclipse) also have their menu bar. Yay! > Right. Can we close this thread and start a new one? > (or at least rename the thread) > To close off this thread, would you still like a ticket opened for the problems with "DISPLAY=:10 myapp" problems, or is that working as well as it possibly can? I'll start new threads for my follow-on questions. From antoine at nagafix.co.uk Thu Jan 19 17:56:43 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 20 Jan 2017 00:56:43 +0700 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: References: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> <5a696ef1-5bd3-f939-ba3a-64db90c16620@nagafix.co.uk> Message-ID: <6d989635-610b-0fe3-5cbf-29967fff7634@nagafix.co.uk> On 20/01/17 00:55, Douglas Doole wrote: > On Thu, Jan 19, 2017 at 5:40 AM Antoine Martin > wrote: > > On 19/01/17 01:37, Douglas Doole wrote: > > Thanks Antoine. > > > > I thought the --start was the trick I needed, but it seems I've > stumbled > > onto something new. :-( > > > > My general model is that I have xpra running, and then I create and > > dispose of terminal windows as needed. Then I run commands as needed > > from the terminal. > > > > I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar > problem. > > > > Since xpra is already running, I can't use "xpra start > --start=...", so > > I used "xpra control :10 start gnome-terminal". This gives me a > terminal > > window with a menu bar. Any commands I start from the terminal (gvim, > > eclipse) also have their menu bar. Yay! > Right. Can we close this thread and start a new one? > (or at least rename the thread) > > > To close off this thread, would you still like a ticket opened for the > problems with "DISPLAY=:10 myapp" problems, or is that working as well > as it possibly can? Yes please. Sounds like we should be able to handle this better. Cheers Antoine > > I'll start new threads for my follow-on questions. From dougdoole at gmail.com Thu Jan 19 18:18:25 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Thu, 19 Jan 2017 18:18:25 +0000 Subject: [winswitch] No menu bar in Ubuntu In-Reply-To: <6d989635-610b-0fe3-5cbf-29967fff7634@nagafix.co.uk> References: <9544e59a-cbfe-9552-9df5-4f5929bcab9a@nagafix.co.uk> <5a696ef1-5bd3-f939-ba3a-64db90c16620@nagafix.co.uk> <6d989635-610b-0fe3-5cbf-29967fff7634@nagafix.co.uk> Message-ID: Ticket #1419 opened. On Thu, Jan 19, 2017 at 9:56 AM Antoine Martin wrote: > On 20/01/17 00:55, Douglas Doole wrote: > > On Thu, Jan 19, 2017 at 5:40 AM Antoine Martin > > wrote: > > > > On 19/01/17 01:37, Douglas Doole wrote: > > > Thanks Antoine. > > > > > > I thought the --start was the trick I needed, but it seems I've > > stumbled > > > onto something new. :-( > > > > > > My general model is that I have xpra running, and then I create and > > > dispose of terminal windows as needed. Then I run commands as > needed > > > from the terminal. > > > > > > I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar > > problem. > > > > > > Since xpra is already running, I can't use "xpra start > > --start=...", so > > > I used "xpra control :10 start gnome-terminal". This gives me a > > terminal > > > window with a menu bar. Any commands I start from the terminal > (gvim, > > > eclipse) also have their menu bar. Yay! > > Right. Can we close this thread and start a new one? > > (or at least rename the thread) > > > > > > To close off this thread, would you still like a ticket opened for the > > problems with "DISPLAY=:10 myapp" problems, or is that working as well > > as it possibly can? > Yes please. Sounds like we should be able to handle this better. > > Cheers > Antoine > > > > > I'll start new threads for my follow-on questions. > > From dougdoole at gmail.com Thu Jan 19 18:56:38 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Thu, 19 Jan 2017 18:56:38 +0000 Subject: [winswitch] Unable to start multiple gnome-terminals Message-ID: Splitting this discussion off from the "No menu bar in Ubuntu" thread. On Thu, Jan 19, 2017 at 5:40 AM Antoine Martin wrote: > > My general model is that I have xpra running, and then I create and In case it matters, I start xpra with: xpra start :10 --start-new-commands=yes > > dispose of terminal windows as needed. Then I run commands as needed > > from the terminal. > > > > I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar problem. > > > > Since xpra is already running, I can't use "xpra start --start=...", so > > I used "xpra control :10 start gnome-terminal". This gives me a terminal > > window with a menu bar. Any commands I start from the terminal (gvim, > > eclipse) also have their menu bar. Yay! > Right. Can we close this thread and start a new one? > (or at least rename the thread) > > > But when I try to start a second terminal using "xpra control :10 start > > gnome-terminal", xpra hangs. I get the title bar and border for the > > second window, but its contents are black. All existing windows stop > > responding to input. (Even the close button in the title bar is > > non-responsive.) The xpra icon in the systray changes from an X to the > > clipboard icon. (The systray icon responds normally.) Running "xpra > > list" shows a LIVE session. If I disconnect the client, the server still > > reports a LIVE session. However as soon as I try to reconnect the client > > the server reports it as DEAD (cleaned up). (The session is not fully > > cleaned up though - there are still 6 xpra related processes running, > > including "xpra start" and Xorg-for-Xpra". Manually killing the > > Xorg-for-Xpra process cleans everything up.) > > > > Any idea on this one? > Yes, unfortunately. > > Many applications have started refusing to launch new instances when you > execute them. > This started with browsers, but it is now affecting other types of > applications. (KDE and many recent gnome applications suffer from this) > Instead of starting a new instance, they try to show a new window - > still belonging to the first process that was started. I think you nailed it there. If I start gnome-terminal with the --disable-factory option, each instance is spawned as a separate process and don't get the hang. > Now, although this can cause the application to misbehave, it should not > be able to crash the xpra server. Unfortunately, clipboard misbehaviour > is an issue that is known to cause this sort of problems. > I'll try to reproduce, having a ticket with details wouldn't hurt. I'll open a ticket shortly. > > In the short term, I can just create my first window using xpra control > > start and then spawn new terminals from that. However my preferred way > > to work is to have a terminal icon in the launcher that I click to spawn > > a new terminal in xpra. > Not sure I understand this part. Don't worry about this. I can work around my concern with --disable-factory. From dougdoole at gmail.com Thu Jan 19 19:10:40 2017 From: dougdoole at gmail.com (Douglas Doole) Date: Thu, 19 Jan 2017 19:10:40 +0000 Subject: [winswitch] Unable to start multiple gnome-terminals In-Reply-To: References: Message-ID: Ticket #1420 opened. On Thu, Jan 19, 2017 at 10:56 AM Douglas Doole wrote: > Splitting this discussion off from the "No menu bar in Ubuntu" thread. > > On Thu, Jan 19, 2017 at 5:40 AM Antoine Martin > wrote: > > > My general model is that I have xpra running, and then I create and > > In case it matters, I start xpra with: > xpra start :10 --start-new-commands=yes > > > > dispose of terminal windows as needed. Then I run commands as needed > > > from the terminal. > > > > > > I had been using "DISPLAY=:10 gnome-terminal" and had the menu bar > problem. > > > > > > Since xpra is already running, I can't use "xpra start --start=...", so > > > I used "xpra control :10 start gnome-terminal". This gives me a > terminal > > > window with a menu bar. Any commands I start from the terminal (gvim, > > > eclipse) also have their menu bar. Yay! > > Right. Can we close this thread and start a new one? > > (or at least rename the thread) > > > > > But when I try to start a second terminal using "xpra control :10 start > > > gnome-terminal", xpra hangs. I get the title bar and border for the > > > second window, but its contents are black. All existing windows stop > > > responding to input. (Even the close button in the title bar is > > > non-responsive.) The xpra icon in the systray changes from an X to the > > > clipboard icon. (The systray icon responds normally.) Running "xpra > > > list" shows a LIVE session. If I disconnect the client, the server > still > > > reports a LIVE session. However as soon as I try to reconnect the > client > > > the server reports it as DEAD (cleaned up). (The session is not fully > > > cleaned up though - there are still 6 xpra related processes running, > > > including "xpra start" and Xorg-for-Xpra". Manually killing the > > > Xorg-for-Xpra process cleans everything up.) > > > > > > Any idea on this one? > > Yes, unfortunately. > > > > Many applications have started refusing to launch new instances when you > > execute them. > > This started with browsers, but it is now affecting other types of > > applications. (KDE and many recent gnome applications suffer from this) > > Instead of starting a new instance, they try to show a new window - > > still belonging to the first process that was started. > > I think you nailed it there. If I start gnome-terminal with the > --disable-factory option, each instance is spawned as a separate process > and don't get the hang. > > > Now, although this can cause the application to misbehave, it should not > > be able to crash the xpra server. Unfortunately, clipboard misbehaviour > > is an issue that is known to cause this sort of problems. > > I'll try to reproduce, having a ticket with details wouldn't hurt. > > I'll open a ticket shortly. > > > > In the short term, I can just create my first window using xpra control > > > start and then spawn new terminals from that. However my preferred way > > > to work is to have a terminal icon in the launcher that I click to > spawn > > > a new terminal in xpra. > > Not sure I understand this part. > > Don't worry about this. I can work around my concern with > --disable-factory. > From sadatakhavi.ali at gmail.com Thu Jan 19 20:59:34 2017 From: sadatakhavi.ali at gmail.com (Ali Sadat) Date: Fri, 20 Jan 2017 07:59:34 +1100 Subject: [winswitch] Xpra - Incorrect window position info Message-ID: Hi, I am using Xpra as a part of one of my projects; and there is a requirement of identifying the current position of active Xpra windows on screen. I am using a power-shell script to pull out the application positions based on thier PID. It works successfully for all programs, except Xpra. All Xpra window locations are reported as following: "Top_Left_Cornr_Y": -80, "cmd": "\"C:\\Program Files (x86)\\Xpra\\Xpra.exe\" attach tcp:192.168.134.10:2224", "pid": 6928, "Win_Size_Y": 88, "Win_Size_X": 88, "Top_Left_Cornr": -80 I am using line below to get the PID of an application instance: $process_data_var = (Get-CimInstance Win32_Process | where Name -match Xpra) | where CommandLine -match 192.168.134.10: And the following PS script to identify the location of App on the screen: https://gallery.technet.microsoft.com/scriptcenter/ Get-the-position-of-a-c91a5f1f It is becoming an urgent issue and I highly appreciate if someone could help me and point me towards the right direction. Thanks Ali _________________________________________________________________________ Ali Sadat Please consider the environment before printing this e-mail This email and any attachments contain confidential information intended only for the person named above and may be subject to legal privilege. If you are not the intended recipient, any disclosure, copying or use of this information is strictly prohibited. The sender provides no guarantee that this communication is free of virus or that it has not been intercepted or interfered with. If you have received this email in error or have any other concerns regarding its transmission, please notify Ali.Sadat at ieee.org From antoine at nagafix.co.uk Fri Jan 20 11:46:16 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 20 Jan 2017 18:46:16 +0700 Subject: [winswitch] Xpra - Incorrect window position info In-Reply-To: References: Message-ID: On 20/01/17 03:59, Ali Sadat via shifter-users wrote: > Hi, > > I am using Xpra as a part of one of my projects; and there is a requirement > of identifying the current position of active Xpra windows on screen. > > I am using a power-shell script to pull out the application positions based > on thier PID. > > It works successfully for all programs, except Xpra. > > All Xpra window locations are reported as following: > "Top_Left_Cornr_Y": -80, > "cmd": "\"C:\\Program Files > (x86)\\Xpra\\Xpra.exe\" attach tcp:192.168.134.10:2224", > "pid": 6928, > "Win_Size_Y": 88, > "Win_Size_X": 88, > "Top_Left_Cornr": -80 > > I am using line below to get the PID of an application instance: > $process_data_var = (Get-CimInstance Win32_Process > | where Name -match Xpra) | where CommandLine -match 192.168.134.10: > > And the following PS script to identify the location of App on the screen: > https://gallery.technet.microsoft.com/scriptcenter/ > Get-the-position-of-a-c91a5f1f How many windows does it show coordinates for? (it is possible that GTK uses event-only windows on win32 - can't remember, it could be one of those) Cheers Antoine > > > It is becoming an urgent issue and I highly appreciate if someone could > help me and point me towards the right direction. > > Thanks > Ali > > _________________________________________________________________________ > Ali Sadat > > Please consider the environment before printing this e-mail > > This email and any attachments contain confidential information intended > only for the person named above and may be subject to legal privilege. If > you are not the intended recipient, any disclosure, copying or use of this > information is strictly prohibited. The sender provides no guarantee that > this communication is free of virus or that it has not been intercepted or > interfered with. If you have received this email in error or have any other > concerns regarding its transmission, please notify Ali.Sadat at ieee.org > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From tzahi.ml at gmail.com Wed Jan 25 08:50:53 2017 From: tzahi.ml at gmail.com (tzahi ml) Date: Wed, 25 Jan 2017 10:50:53 +0200 Subject: [winswitch] Newbie question about XPRA HTML5 Licensing Message-ID: What is the license of the XPRA HTML5 client? Is it indeed fully MPL as some of the files appear to be? I am thinking about integrating it with other javascript libs of mine and I don't want a GPL license to collide with them. Optionally if it is indeed a GPL, I was thinking in embedding it in a separate iframe so it won't interact with the non-GPL. Do you think it is enough? Thanks. From antoine at nagafix.co.uk Wed Jan 25 16:57:25 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 25 Jan 2017 23:57:25 +0700 Subject: [winswitch] Newbie question about XPRA HTML5 Licensing In-Reply-To: References: Message-ID: On 25/01/17 15:50, tzahi ml via shifter-users wrote: > What is the license of the XPRA HTML5 client? > Is it indeed fully MPL as some of the files appear to be? The core code is MPL but there are many optional sub-modules with their own licenses. (audio, video, packet compression, etc) > I am thinking about integrating it with other javascript libs of mine and I > don't want a GPL license to collide with them. Define "collide". > Optionally if it is indeed a GPL, I was thinking in embedding it in a > separate iframe so it won't interact with the non-GPL. Do you think it is > enough? IANAL and I don't know what your code does, but this sounds overkill. Cheers Antoine > > Thanks. From tzahi.ml at gmail.com Sun Jan 29 10:30:50 2017 From: tzahi.ml at gmail.com (tzahi ml) Date: Sun, 29 Jan 2017 12:30:50 +0200 Subject: [winswitch] Newbie question about XPRA HTML5 Licensing In-Reply-To: References: Message-ID: Collide means, that I have some javascript files which are proprietary to me and I am not yet feeling ready to release them as open source (unless advantageous). So if there will be a GPL license in the same process with them (i.e. xpra html5 client files), it will force me to release them as an open source license. IANAL as well, and unless I missed something, but from my limited understanding it seems there are no GPL client side javascript libraries in the HTML5 client libraries sources (some Apache, some MIT, MPL but no GPL). Please correct me if I am wrong... On Wed, Jan 25, 2017 at 6:57 PM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 25/01/17 15:50, tzahi ml via shifter-users wrote: > > What is the license of the XPRA HTML5 client? > > Is it indeed fully MPL as some of the files appear to be? > The core code is MPL but there are many optional sub-modules with their > own licenses. (audio, video, packet compression, etc) > > > I am thinking about integrating it with other javascript libs of mine > and I > > don't want a GPL license to collide with them. > Define "collide". > > > Optionally if it is indeed a GPL, I was thinking in embedding it in a > > separate iframe so it won't interact with the non-GPL. Do you think it is > > enough? > IANAL and I don't know what your code does, but this sounds overkill. > > Cheers > Antoine > > > > > Thanks. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >