From dougdoole at gmail.com Tue May 5 18:00:19 2015 From: dougdoole at gmail.com (Douglas Doole) Date: Tue, 5 May 2015 13:00:19 -0400 Subject: [winswitch] xpra 0.14.23 - Spinners not going away Message-ID: Since upgrading to xpra 0.14.23, I've had a couple instances where I've had a network hiccup and the spinners have appeared. Yet once the network is moving again, the spinners have remained on some of the windows (not all) even though they are otherwise responding properly. That is, I'm editing text, cutting & pasting, etc. but the spinner is sitting in front of everything spinning away. Needless to say, it makes the affected windows pretty much unusable. Once this has happened, the only way I can clear things up is to drop the client connection and re-connect to the server. I am not able to reproduce this on demand, but it has happened a couple times now. I have no idea what the trigger might be. I had not seen this problem before upgrading to 0.14.23. Bother the server and the client are running Ubuntu 14.04. Unfortunately, I don't have a log from either of the times I've seen it happen. Anything in particular I should capture to help debug it? -- -- Doug Doole aibohphobia - The irrational fear of palindromes From antoine at nagafix.co.uk Wed May 6 11:49:31 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 06 May 2015 17:49:31 +0700 Subject: [winswitch] xpra 0.14.23 - Spinners not going away In-Reply-To: References: Message-ID: <5549F1BB.40609@nagafix.co.uk> Hi Douglas, On 06/05/15 00:00, Douglas Doole wrote: > Since upgrading to xpra 0.14.23, I've had a couple instances where I've had > a network hiccup and the spinners have appeared. Yet once the network is > moving again, the spinners have remained on some of the windows (not all) > even though they are otherwise responding properly. That is, I'm editing > text, cutting & pasting, etc. but the spinner is sitting in front of > everything spinning away. Needless to say, it makes the affected windows > pretty much unusable. > > Once this has happened, the only way I can clear things up is to drop the > client connection and re-connect to the server. You may also be able to restore things by toggling opengl off then on again from the tray menu. (assuming your system supports opengl) > I am not able to reproduce this on demand, but it has happened a couple > times now. I have no idea what the trigger might be. I had not seen this > problem before upgrading to 0.14.23. Bother the server and the client are > running Ubuntu 14.04. Thanks for reporting it. It would help if I could reproduce the problem on my setup. Can you tell us which applications were running when the problem occurred? (and also which ones were affected and which ones were not) > Unfortunately, I don't have a log from either of the times I've seen it > happen. Anything in particular I should capture to help debug it? Unfortunately, there isn't a specific debug switch for this feature, so you would need to use the big hammer "-d client", which will also log a lot of unrelated things. And even if the logging was more specific, it may not tell us enough to debug further. Looking at the spinner code, I found a couple of issues, maybe one of those is what was causing your problem. These fixes will be included in 0.14.24. Thanks Antoine From dougdoole at gmail.com Wed May 6 14:22:52 2015 From: dougdoole at gmail.com (Douglas Doole) Date: Wed, 6 May 2015 09:22:52 -0400 Subject: [winswitch] xpra 0.14.23 - Spinners not going away In-Reply-To: <5549F1BB.40609@nagafix.co.uk> References: <5549F1BB.40609@nagafix.co.uk> Message-ID: > You may also be able to restore things by toggling opengl off then on > again from the tray menu. (assuming your system supports opengl) I am using opengl, so I'll give this a try the next time I see it happen. > Thanks for reporting it. > It would help if I could reproduce the problem on my setup. If I ever determine something that triggers it, I'll be sure to update you. > Can you tell us which applications were running when the problem > occurred? (and also which ones were affected and which ones were not) Every time I've seen it (3 times now), I've had a mix of konsole and gvim up. The problem has affected both window types. On the last occurrence, I had two konsole windows and 4 gvim windows and only one konsole window was affected. Previously I'd had a similar mix of windows, but it was one gvim and two konsole windows that were affected. On the most recent occurrence I noticed that the troublesome spinner is actually static until the window contents change. So, on the stuck konsole, the spinner was frozen until I started typing, at which point it rotated one segment for each character typed. I also noticed that the stuck spinner survives things like window resizing, minimizing, etc. > Unfortunately, there isn't a specific debug switch for this feature, so > you would need to use the big hammer "-d client", which will also log a > lot of unrelated things. > And even if the logging was more specific, it may not tell us enough to > debug further. On the last occurrence, I captured the basic client log, but all it showed was the "server is not responding, drawing spinners over the wind ows" message. I'll add "-d client" and see if I get anything useful. On Wed, May 6, 2015 at 6:49 AM, Antoine Martin wrote: > Hi Douglas, > > On 06/05/15 00:00, Douglas Doole wrote: > > Since upgrading to xpra 0.14.23, I've had a couple instances where I've > had > > a network hiccup and the spinners have appeared. Yet once the network is > > moving again, the spinners have remained on some of the windows (not all) > > even though they are otherwise responding properly. That is, I'm editing > > text, cutting & pasting, etc. but the spinner is sitting in front of > > everything spinning away. Needless to say, it makes the affected windows > > pretty much unusable. > > > > Once this has happened, the only way I can clear things up is to drop the > > client connection and re-connect to the server. > You may also be able to restore things by toggling opengl off then on > again from the tray menu. (assuming your system supports opengl) > > I am not able to reproduce this on demand, but it has happened a couple > > times now. I have no idea what the trigger might be. I had not seen this > > problem before upgrading to 0.14.23. Bother the server and the client are > > running Ubuntu 14.04. > Thanks for reporting it. > It would help if I could reproduce the problem on my setup. > Can you tell us which applications were running when the problem > occurred? (and also which ones were affected and which ones were not) > > Unfortunately, I don't have a log from either of the times I've seen it > > happen. Anything in particular I should capture to help debug it? > Unfortunately, there isn't a specific debug switch for this feature, so > you would need to use the big hammer "-d client", which will also log a > lot of unrelated things. > And even if the logging was more specific, it may not tell us enough to > debug further. > > Looking at the spinner code, I found a couple of issues, maybe one of > those is what was causing your problem. > These fixes will be included in 0.14.24. > > Thanks > Antoine > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > -- -- Doug Doole aibohphobia - The irrational fear of palindromes From dougdoole at gmail.com Wed May 6 16:11:33 2015 From: dougdoole at gmail.com (Douglas Doole) Date: Wed, 6 May 2015 11:11:33 -0400 Subject: [winswitch] xpra 0.14.23 - Spinners not going away In-Reply-To: References: <5549F1BB.40609@nagafix.co.uk> Message-ID: Just hit the problem again. Here's the client log with "-d client" starting from the server not responding message 2015-05-06 11:06:35,078 server is not responding, drawing spinners over the windows 2015-05-06 11:06:35,196 ping echo server load=(0, 20, 50), measured client latency=2ms 2015-05-06 11:06:35,205 server is OK again 2015-05-06 11:06:35,206 process_draw 109990 bytes for window 1 using png encoding with options={'compress_level': 2} 2015-05-06 11:06:35,219 process_draw 99427 bytes for window 1 using png encoding with options={'compress_level': 2} 2015-05-06 11:06:35,228 record_decode_time(True) wid=1, png: 575x768, 22.3ms 2015-05-06 11:06:35,231 record_decode_time(True) wid=1, png: 575x768, 11.0ms 2015-05-06 11:06:35,287 process_draw 125023 bytes for window 1 using png encoding with options={'compress_level': 2} 2015-05-06 11:06:35,297 record_decode_time(True) wid=1, png: 575x768, 10.3ms 2015-05-06 11:06:40,269 process_draw 122605 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:40,286 record_decode_time(True) wid=1, png: 575x768, 17.4ms 2015-05-06 11:06:42,228 process_draw 124183 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:42,246 record_decode_time(True) wid=1, png: 575x768, 18.0ms 2015-05-06 11:06:42,385 process_draw 123751 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:42,403 record_decode_time(True) wid=1, png: 575x768, 18.2ms 2015-05-06 11:06:44,065 check_echo_timeout(1430924744063) last_ping_echoed_time=1430924794068 2015-05-06 11:06:44,069 average server latency=6.5, using max wait 1.01s 2015-05-06 11:06:44,072 ping echo server load=(0, 20, 50), measured client latency=3ms 2015-05-06 11:06:47,007 process_draw 125209 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:47,025 record_decode_time(True) wid=1, png: 575x768, 17.4ms 2015-05-06 11:06:48,871 process_draw 105618 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:48,884 record_decode_time(True) wid=1, png: 575x768, 12.4ms 2015-05-06 11:06:54,071 average server latency=6.5, using max wait 1.01s 2015-05-06 11:06:54,072 check_echo_timeout(1430924754065) last_ping_echoed_time=1430924804069 2015-05-06 11:06:54,074 ping echo server load=(0, 20, 50), measured client latency=7ms 2015-05-06 11:06:54,231 process_draw 106959 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:54,254 record_decode_time(True) wid=1, png: 575x768, 22.5ms 2015-05-06 11:06:57,833 process_draw 110440 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:57,847 record_decode_time(True) wid=1, png: 575x768, 13.5ms 2015-05-06 11:06:58,493 process_draw 108951 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:58,507 record_decode_time(True) wid=1, png: 575x768, 13.5ms 2015-05-06 11:06:58,922 process_draw 104383 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:58,943 record_decode_time(True) wid=1, png: 575x768, 20.0ms 2015-05-06 11:06:58,957 process_draw 101628 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:06:58,973 record_decode_time(True) wid=1, png: 575x768, 15.9ms 2015-05-06 11:06:59,230 process_draw 753 bytes for window 1 using png encoding with options={'compress_level': 3, 'store': 634, 'delta': 604} 2015-05-06 11:06:59,232 record_decode_time(True) wid=1, png: 553x15, 1.9ms 2015-05-06 11:07:03,057 server cursor sizes: default=85, max=(64, 64) 2015-05-06 11:07:03,057 new cursor at 6,4 with serial=135, dimensions: 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) 2015-05-06 11:07:03,276 server cursor sizes: default=85, max=(64, 64) 2015-05-06 11:07:03,277 new cursor at 11,11 with serial=3, dimensions: 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) 2015-05-06 11:07:03,304 server cursor sizes: default=85, max=(64, 64) 2015-05-06 11:07:03,305 new cursor at 6,4 with serial=114, dimensions: 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) 2015-05-06 11:07:03,448 server cursor sizes: default=85, max=(64, 64) 2015-05-06 11:07:03,448 new cursor at 11,11 with serial=3, dimensions: 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) 2015-05-06 11:07:03,871 update_focus(1, True) focused=None, grabbed=None 2015-05-06 11:07:03,871 send_focus(1) 2015-05-06 11:07:03,888 process_draw 90 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:07:03,891 record_decode_time(True) wid=1, png: 7x15, 2.6ms 2015-05-06 11:07:04,067 check_echo_timeout(1430924764066) last_ping_echoed_time=1430924814071 2015-05-06 11:07:04,072 average server latency=6.5, using max wait 1.01s 2015-05-06 11:07:04,077 ping echo server load=(0, 20, 50), measured client latency=3ms 2015-05-06 11:07:05,009 handle_key_action(GLClientWindow(1 : GLPixmapBacking(1, (575, 768), None)), ) wid=1 2015-05-06 11:07:05,035 server cursor sizes: default=85, max=(64, 64) 2015-05-06 11:07:05,035 new cursor at 8,8 with serial=4, dimensions: 16x16, len(pixels)=1024, default cursor size is 25, maximum=(64, 64) 2015-05-06 11:07:05,072 handle_key_action(GLClientWindow(1 : GLPixmapBacking(1, (575, 768), None)), ) wid=1 2015-05-06 11:07:05,112 process_draw 99622 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:07:05,131 record_decode_time(True) wid=1, png: 575x748, 18.8ms 2015-05-06 11:07:05,563 server cursor sizes: default=85, max=(64, 64) 2015-05-06 11:07:05,563 new cursor at 11,11 with serial=3, dimensions: 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) 2015-05-06 11:07:06,183 update_focus(1, False) focused=1, grabbed=None 2015-05-06 11:07:06,204 send_focus(0) 2015-05-06 11:07:06,218 process_draw 104 bytes for window 1 using png encoding with options={'compress_level': 3} 2015-05-06 11:07:06,220 record_decode_time(True) wid=1, png: 7x15, 1.0ms 2015-05-06 11:07:14,074 average server latency=6.5, using max wait 1.01s 2015-05-06 11:07:14,074 check_echo_timeout(1430924774067) last_ping_echoed_time=1430924824072 2015-05-06 11:07:14,077 ping echo server load=(0, 20, 50), measured client latency=3ms 2015-05-06 11:07:24,068 check_echo_timeout(1430924784068) last_ping_echoed_time=1430924834073 2015-05-06 11:07:24,074 average server latency=6.5, using max wait 1.01s 2015-05-06 11:07:24,077 ping echo server load=(0, 20, 50), measured client latency=4ms Toggling opengl on and off did make the spinner go away. On Wed, May 6, 2015 at 9:22 AM, Douglas Doole wrote: > > You may also be able to restore things by toggling opengl off then on > > again from the tray menu. (assuming your system supports opengl) > > I am using opengl, so I'll give this a try the next time I see it happen. > > > Thanks for reporting it. > > It would help if I could reproduce the problem on my setup. > > If I ever determine something that triggers it, I'll be sure to update you. > > > Can you tell us which applications were running when the problem > > occurred? (and also which ones were affected and which ones were not) > > Every time I've seen it (3 times now), I've had a mix of konsole and gvim > up. The problem has affected both window types. On the last occurrence, I > had two konsole windows and 4 gvim windows and only one konsole window was > affected. Previously I'd had a similar mix of windows, but it was one gvim > and two konsole windows that were affected. > > On the most recent occurrence I noticed that the troublesome spinner is > actually static until the window contents change. So, on the stuck konsole, > the spinner was frozen until I started typing, at which point it rotated > one segment for each character typed. I also noticed that the stuck spinner > survives things like window resizing, minimizing, etc. > > > Unfortunately, there isn't a specific debug switch for this feature, so > > you would need to use the big hammer "-d client", which will also log a > > lot of unrelated things. > > And even if the logging was more specific, it may not tell us enough to > > debug further. > > On the last occurrence, I captured the basic client log, but all it showed > was the "server is not responding, drawing spinners over the wind > ows" message. I'll add "-d client" and see if I get anything useful. > > On Wed, May 6, 2015 at 6:49 AM, Antoine Martin > wrote: > >> Hi Douglas, >> >> On 06/05/15 00:00, Douglas Doole wrote: >> > Since upgrading to xpra 0.14.23, I've had a couple instances where I've >> had >> > a network hiccup and the spinners have appeared. Yet once the network is >> > moving again, the spinners have remained on some of the windows (not >> all) >> > even though they are otherwise responding properly. That is, I'm editing >> > text, cutting & pasting, etc. but the spinner is sitting in front of >> > everything spinning away. Needless to say, it makes the affected windows >> > pretty much unusable. >> > >> > Once this has happened, the only way I can clear things up is to drop >> the >> > client connection and re-connect to the server. >> You may also be able to restore things by toggling opengl off then on >> again from the tray menu. (assuming your system supports opengl) >> > I am not able to reproduce this on demand, but it has happened a couple >> > times now. I have no idea what the trigger might be. I had not seen this >> > problem before upgrading to 0.14.23. Bother the server and the client >> are >> > running Ubuntu 14.04. >> Thanks for reporting it. >> It would help if I could reproduce the problem on my setup. >> Can you tell us which applications were running when the problem >> occurred? (and also which ones were affected and which ones were not) >> > Unfortunately, I don't have a log from either of the times I've seen it >> > happen. Anything in particular I should capture to help debug it? >> Unfortunately, there isn't a specific debug switch for this feature, so >> you would need to use the big hammer "-d client", which will also log a >> lot of unrelated things. >> And even if the logging was more specific, it may not tell us enough to >> debug further. >> >> Looking at the spinner code, I found a couple of issues, maybe one of >> those is what was causing your problem. >> These fixes will be included in 0.14.24. >> >> Thanks >> Antoine >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > > > -- > -- Doug Doole > > aibohphobia - The irrational fear of palindromes > -- -- Doug Doole aibohphobia - The irrational fear of palindromes From jksiezniak at gmail.com Mon May 11 18:52:40 2015 From: jksiezniak at gmail.com (=?UTF-8?B?SmFrdWIgS3NpxJnFvG5pYWs=?=) Date: Mon, 11 May 2015 19:52:40 +0200 Subject: [winswitch] [xpra] Implementation of Java/Android client Message-ID: Hello devs, I've started writing a new Java/Android client. Currently, I'm developing a Swing client as a Proof of Concept and I think, that it has already surpassed the old java client found in SVN repo, as it supports both bencode and rencode packet encodings, fully controls life-cycle of windows and popups (create, move, resize, etc.) and handles all mouse events. However, it still lacks keyboard support and I'd like to ask you for help and explanation, how key mapping works? (If that's not possible then I'll try to figure out it on my own. :-)) In the old java client there is a code that builds key-mappings and appends them to 'hello' packet. Each KeySpec consists of a keyval, keyname, keycode, group and level. Then, on 'key-action' event, there is sent keyval, keyname and keycode again. It looks like some redundant data is sent here, so I'd like to simplify it a bit, but first I need to understand what design decisions are behind this key-mapping logic. :p Also, I've noticed some issues with my Xpra installation (v0.14.22): 1. Initial window positioning constantly changes. a) $ xpra start :100 --start-child=xterm b) Connect with 'xpra attach' to the server and move the window to the top left corner. c) Disconnect and connect repeatedly and notice how the window is moved a bit down on each connection. (I'm using KDE environment, if it helps.) 2. When a menu is opened, the Xpra server provides a 'transient-for' value which helps to associate with a parent window, but when a sub-menu is opened the 'transient-for' is missing. Is it a correct behaviour? -- Thanks, Jakub Ksi??niak From antoine at nagafix.co.uk Tue May 12 05:56:18 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 12 May 2015 11:56:18 +0700 Subject: [winswitch] [xpra] Implementation of Java/Android client In-Reply-To: References: Message-ID: <555187F2.1010904@nagafix.co.uk> On 12/05/15 00:52, Jakub Ksi??niak wrote: > Hello devs, > > I've started writing a new Java/Android client. Currently, I'm developing a > Swing client as a Proof of Concept and I think, that it has already > surpassed the old java client found in SVN repo, as it supports both > bencode and rencode packet encodings, fully controls life-cycle of windows > and popups (create, move, resize, etc.) and handles all mouse events. Excellent! Can you share the code so we can try it? > However, it still lacks keyboard support and I'd like to ask you for help > and explanation, how key mapping works? (If that's not possible then I'll > try to figure out it on my own. :-)) Good question.. but there is no easy answer I am afraid. The key mapping code is a mixture of GTK and X11 key definitions (because that's how the code started), with lots of hacks to get other platforms to work more or less properly... > In the old java client there is a code that builds key-mappings and appends > them to 'hello' packet. Each KeySpec consists of a keyval, keyname, > keycode, group and level. Then, on 'key-action' event, there is sent > keyval, keyname and keycode again. It looks like some redundant data is > sent here, so I'd like to simplify it a bit, but first I need to understand > what design decisions are behind this key-mapping logic. :p Mostly: backwards compatibility. They are not as redundant as you might think. The same keycode can emit multiple keysyms. I would focus on getting the basics working with your new client rather than trying to refactor some code which is very tricky to get right for all platforms. (unless you have time to test all the platforms with all the layouts - we're talking many weeks of testing here...) > Also, I've noticed some issues with my Xpra installation (v0.14.22): > 1. Initial window positioning constantly changes. > a) $ xpra start :100 --start-child=xterm > b) Connect with 'xpra attach' to the server and move the window to the top > left corner. > c) Disconnect and connect repeatedly and notice how the window is moved a > bit down on each connection. (I'm using KDE environment, if it helps.) That's a known issue with the window frame moving the actual window contents a bit. Not a huge issue IMO. > 2. When a menu is opened, the Xpra server provides a 'transient-for' value > which helps to associate with a parent window, but when a sub-menu is > opened the 'transient-for' is missing. Is it a correct behaviour? Which application are you testing with? The transient-for hint is supplied (or not) by client applications and xpra just forwards it to the client. Unfortunately, many applications and toolkits do not always provide this useful window management hint. You can verify it server-side with xprop. Cheers Antoine From jksiezniak at gmail.com Tue May 12 07:46:14 2015 From: jksiezniak at gmail.com (=?UTF-8?B?SmFrdWIgS3NpxJnFvG5pYWs=?=) Date: Tue, 12 May 2015 08:46:14 +0200 Subject: [winswitch] [xpra] Implementation of Java/Android client In-Reply-To: <555187F2.1010904@nagafix.co.uk> References: <555187F2.1010904@nagafix.co.uk> Message-ID: Hi, Of course, I'm willing to share the code and I thought about publishing it on GitHub, but it's quite a mess now. I'll try to clean up it soon, or I can PM you earlier if you want. Regarding 'transient-for' hint, I've got difficulties to run xprop and open menus at the same time. :) The program I run is 'konsole' from KDE, but also Gimp and other apps have this issue. -- Regards, Jakub Ksi??niak 2015-05-12 6:56 GMT+02:00 Antoine Martin : > On 12/05/15 00:52, Jakub Ksi??niak wrote: > >> Hello devs, >> >> I've started writing a new Java/Android client. Currently, I'm developing >> a >> Swing client as a Proof of Concept and I think, that it has already >> surpassed the old java client found in SVN repo, as it supports both >> bencode and rencode packet encodings, fully controls life-cycle of windows >> and popups (create, move, resize, etc.) and handles all mouse events. >> > Excellent! > Can you share the code so we can try it? > >> However, it still lacks keyboard support and I'd like to ask you for help >> and explanation, how key mapping works? (If that's not possible then I'll >> try to figure out it on my own. :-)) >> > Good question.. but there is no easy answer I am afraid. > The key mapping code is a mixture of GTK and X11 key definitions (because > that's how the code started), with lots of hacks to get other platforms to > work more or less properly... > >> In the old java client there is a code that builds key-mappings and >> appends >> them to 'hello' packet. Each KeySpec consists of a keyval, keyname, >> keycode, group and level. Then, on 'key-action' event, there is sent >> keyval, keyname and keycode again. It looks like some redundant data is >> sent here, so I'd like to simplify it a bit, but first I need to >> understand >> what design decisions are behind this key-mapping logic. :p >> > Mostly: backwards compatibility. > They are not as redundant as you might think. The same keycode can emit > multiple keysyms. > I would focus on getting the basics working with your new client rather > than trying to refactor some code which is very tricky to get right for all > platforms. > (unless you have time to test all the platforms with all the layouts - > we're talking many weeks of testing here...) > >> Also, I've noticed some issues with my Xpra installation (v0.14.22): >> 1. Initial window positioning constantly changes. >> a) $ xpra start :100 --start-child=xterm >> b) Connect with 'xpra attach' to the server and move the window to the top >> left corner. >> c) Disconnect and connect repeatedly and notice how the window is moved a >> bit down on each connection. (I'm using KDE environment, if it helps.) >> > That's a known issue with the window frame moving the actual window > contents a bit. > Not a huge issue IMO. > >> 2. When a menu is opened, the Xpra server provides a 'transient-for' value >> which helps to associate with a parent window, but when a sub-menu is >> opened the 'transient-for' is missing. Is it a correct behaviour? >> > Which application are you testing with? > The transient-for hint is supplied (or not) by client applications and > xpra just forwards it to the client. > Unfortunately, many applications and toolkits do not always provide this > useful window management hint. > You can verify it server-side with xprop. > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Wed May 13 10:53:59 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 13 May 2015 16:53:59 +0700 Subject: [winswitch] [xpra] Implementation of Java/Android client In-Reply-To: References: <555187F2.1010904@nagafix.co.uk> Message-ID: <55531F37.2030202@nagafix.co.uk> On 12/05/15 13:46, Jakub Ksi??niak wrote: > Hi, > > Of course, I'm willing to share the code and I thought about > publishing it on GitHub, but it's quite a mess now. I'll try to clean > up it soon, or I can PM you earlier if you want. "Release early, release often"... something we have somewhat failed to do lately. But if I post it, others may be able to help. I've just posted an updated Android build based on the current trunk (which is not great but better than nothing): http://xpra.org/beta/Android/ > > Regarding 'transient-for' hint, I've got difficulties to run xprop and > open menus at the same time. :) The program I run is 'konsole' from > KDE, but also Gimp and other apps have this issue. You can always run "DISPLAY=:XXX xprop -root -tree" via ssh, or using a sleep timer from another terminal. That's what I did and I found a bug in xpra which prevented us from detecting the "transient-for" hint if the window referred to is an override-redirect window, this is fixed in: http://xpra.org/trac/changeset/9351/xpra And will be in the next stable update. Cheers Antoine > > -- > Regards, > Jakub Ksi??niak > > 2015-05-12 6:56 GMT+02:00 Antoine Martin >: > > On 12/05/15 00:52, Jakub Ksi??niak wrote: > > Hello devs, > > I've started writing a new Java/Android client. Currently, I'm > developing a > Swing client as a Proof of Concept and I think, that it has > already > surpassed the old java client found in SVN repo, as it > supports both > bencode and rencode packet encodings, fully controls > life-cycle of windows > and popups (create, move, resize, etc.) and handles all mouse > events. > > Excellent! > Can you share the code so we can try it? > > However, it still lacks keyboard support and I'd like to ask > you for help > and explanation, how key mapping works? (If that's not > possible then I'll > try to figure out it on my own. :-)) > > Good question.. but there is no easy answer I am afraid. > The key mapping code is a mixture of GTK and X11 key definitions > (because that's how the code started), with lots of hacks to get > other platforms to work more or less properly... > > In the old java client there is a code that builds > key-mappings and appends > them to 'hello' packet. Each KeySpec consists of a keyval, > keyname, > keycode, group and level. Then, on 'key-action' event, there > is sent > keyval, keyname and keycode again. It looks like some > redundant data is > sent here, so I'd like to simplify it a bit, but first I need > to understand > what design decisions are behind this key-mapping logic. :p > > Mostly: backwards compatibility. > They are not as redundant as you might think. The same keycode can > emit multiple keysyms. > I would focus on getting the basics working with your new client > rather than trying to refactor some code which is very tricky to > get right for all platforms. > (unless you have time to test all the platforms with all the > layouts - we're talking many weeks of testing here...) > > Also, I've noticed some issues with my Xpra installation > (v0.14.22): > 1. Initial window positioning constantly changes. > a) $ xpra start :100 --start-child=xterm > b) Connect with 'xpra attach' to the server and move the > window to the top > left corner. > c) Disconnect and connect repeatedly and notice how the window > is moved a > bit down on each connection. (I'm using KDE environment, if it > helps.) > > That's a known issue with the window frame moving the actual > window contents a bit. > Not a huge issue IMO. > > 2. When a menu is opened, the Xpra server provides a > 'transient-for' value > which helps to associate with a parent window, but when a > sub-menu is > opened the 'transient-for' is missing. Is it a correct behaviour? > > Which application are you testing with? > The transient-for hint is supplied (or not) by client applications > and xpra just forwards it to the client. > Unfortunately, many applications and toolkits do not always > provide this useful window management hint. > You can verify it server-side with xprop. > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > From jksiezniak at gmail.com Thu May 14 22:06:01 2015 From: jksiezniak at gmail.com (=?UTF-8?B?SmFrdWIgS3NpxJnFvG5pYWs=?=) Date: Thu, 14 May 2015 23:06:01 +0200 Subject: [winswitch] [xpra] Implementation of Java/Android client In-Reply-To: <55531F37.2030202@nagafix.co.uk> References: <555187F2.1010904@nagafix.co.uk> <55531F37.2030202@nagafix.co.uk> Message-ID: 2015-05-13 11:53 GMT+02:00 Antoine Martin : > > "Release early, release often"... something we have somewhat failed to do > lately. > But if I post it, others may be able to help. > > So, I've just published on GitHub the code I've written so far. As a reminder, only a Swing client is working now. https://github.com/jksiezni/xpra-client The repo depends on submodules, so it should be cloned with --recursive parameter: $ git clone --recursive https://github.com/jksiezni/xpra-client.git I've been reading about X11 keyboard management and I haven't found an easy (and cross-platform) way to translate Java keycodes to what Xpra requires. Thus, I'm switching to Android hoping to find an easier way in providing key-mappings to Xpra. Regards, Jakub Ksi??niak > > > > -- > Regards, > Jakub Ksi??niak > > 2015-05-12 6:56 GMT+02:00 Antoine Martin : > >> On 12/05/15 00:52, Jakub Ksi??niak wrote: >> >>> Hello devs, >>> >>> I've started writing a new Java/Android client. Currently, I'm >>> developing a >>> Swing client as a Proof of Concept and I think, that it has already >>> surpassed the old java client found in SVN repo, as it supports both >>> bencode and rencode packet encodings, fully controls life-cycle of >>> windows >>> and popups (create, move, resize, etc.) and handles all mouse events. >>> >> Excellent! >> Can you share the code so we can try it? >> >>> However, it still lacks keyboard support and I'd like to ask you for help >>> and explanation, how key mapping works? (If that's not possible then I'll >>> try to figure out it on my own. :-)) >>> >> Good question.. but there is no easy answer I am afraid. >> The key mapping code is a mixture of GTK and X11 key definitions (because >> that's how the code started), with lots of hacks to get other platforms to >> work more or less properly... >> >>> In the old java client there is a code that builds key-mappings and >>> appends >>> them to 'hello' packet. Each KeySpec consists of a keyval, keyname, >>> keycode, group and level. Then, on 'key-action' event, there is sent >>> keyval, keyname and keycode again. It looks like some redundant data is >>> sent here, so I'd like to simplify it a bit, but first I need to >>> understand >>> what design decisions are behind this key-mapping logic. :p >>> >> Mostly: backwards compatibility. >> They are not as redundant as you might think. The same keycode can emit >> multiple keysyms. >> I would focus on getting the basics working with your new client rather >> than trying to refactor some code which is very tricky to get right for all >> platforms. >> (unless you have time to test all the platforms with all the layouts - >> we're talking many weeks of testing here...) >> >>> Also, I've noticed some issues with my Xpra installation (v0.14.22): >>> 1. Initial window positioning constantly changes. >>> a) $ xpra start :100 --start-child=xterm >>> b) Connect with 'xpra attach' to the server and move the window to the >>> top >>> left corner. >>> c) Disconnect and connect repeatedly and notice how the window is moved a >>> bit down on each connection. (I'm using KDE environment, if it helps.) >>> >> That's a known issue with the window frame moving the actual window >> contents a bit. >> Not a huge issue IMO. >> >>> 2. When a menu is opened, the Xpra server provides a 'transient-for' >>> value >>> which helps to associate with a parent window, but when a sub-menu is >>> opened the 'transient-for' is missing. Is it a correct behaviour? >>> >> Which application are you testing with? >> The transient-for hint is supplied (or not) by client applications and >> xpra just forwards it to the client. >> Unfortunately, many applications and toolkits do not always provide this >> useful window management hint. >> You can verify it server-side with xprop. >> >> Cheers >> Antoine >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > > From johnss1221 at gmail.com Mon May 18 09:01:07 2015 From: johnss1221 at gmail.com (John Smith) Date: Mon, 18 May 2015 15:01:07 +0700 Subject: [winswitch] Secure TCP mode with --password-file Message-ID: Hi, Recently, I have upgrade xpra from 0.14.x to 0.15.0 for my server (trusty) . And now I can't use --password-file option to secure tcp mode as before. Server use --password-file=, but client don't need to use --password-file to attach . I think the problems is xpra for server. If this is a bug, I will file a ticket about this. Thanks. From antoine at nagafix.co.uk Mon May 18 10:19:15 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 18 May 2015 16:19:15 +0700 Subject: [winswitch] Secure TCP mode with --password-file In-Reply-To: References: Message-ID: <5559AE93.7040009@nagafix.co.uk> On 18/05/15 15:01, John Smith wrote: > Hi, > > Recently, I have upgrade xpra from 0.14.x to 0.15.0 for my server (trusty) > . And now I can't use --password-file option to secure tcp mode as before. > Server use --password-file=, but client > don't need to use --password-file to attach . I think the problems is xpra > for server. If this is a bug, I will file a ticket about this. Thanks for reporting this, it should now be fixed: http://xpra.org/trac/changeset/9422 You can just make the same change to your /etc/xpra/xpra.conf Note: in 0.15, we support having different authentication modules for tcp and unix-domain-sockets using the "--tcp-auth" flag. (if unset, it will use the same value as the "--auth" flag as before) So you can choose to have no authentication on the unix domain socket (--auth=none) which should be protected by regular unix file permissions, and have passwords (or other) only used for tcp sockets. Cheers Antoine From antoine at nagafix.co.uk Mon May 18 18:54:48 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 19 May 2015 00:54:48 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.14.24 (many fixes) Message-ID: <555A2768.2050301@nagafix.co.uk> Hi, This stable update fixes many issues, mostly minor ones. Testing for the 0.15 release continues to uncover long standing bugs and corner cases. A new release candidate build of 0.15 is also available. 0.14.24 release notes: * fix launcher crash on encoding menu changes * fix transient-for detection for override-redirect windows * fix wait for connection exit when already closed * fix proxy server protocol errors * fix server and client process exit reliability * fix reentrant errors in signal handler * fix exit on signal from console * fix crash when window spinners are shown * fix invalid lz4 availability check * fix protocol garbage collection (for consistency) * fix error when only video encodings are available * fix compatibility with newer PAM modules * allow rgb32 for non-video (html5 client) * add sanity checks to swscale module * avoid warnings with some Java applications * handle end-of-stream sound messages * improved appdata information 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 johnss1221 at gmail.com Tue May 19 10:58:50 2015 From: johnss1221 at gmail.com (John Smith) Date: Tue, 19 May 2015 16:58:50 +0700 Subject: [winswitch] Secure TCP mode with --password-file In-Reply-To: <5559AE93.7040009@nagafix.co.uk> References: <5559AE93.7040009@nagafix.co.uk> Message-ID: > Thanks for reporting this, it should now be fixed: >> > http://xpra.org/trac/changeset/9422 > You can just make the same change to your /etc/xpra/xpra.conf > > Note: in 0.15, we support having different authentication modules for tcp > and unix-domain-sockets using the "--tcp-auth" flag. > (if unset, it will use the same value as the "--auth" flag as before) > So you can choose to have no authentication on the unix domain socket > (--auth=none) which should be protected by regular unix file permissions, > and have passwords (or other) only used for tcp sockets. > Thanks for your informations :) > > Cheers > Antoine > > _______________________________________________ > 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 Tue May 19 16:20:42 2015 From: dougdoole at gmail.com (Douglas Doole) Date: Tue, 19 May 2015 11:20:42 -0400 Subject: [winswitch] xpra 0.14.23 - Spinners not going away In-Reply-To: References: <5549F1BB.40609@nagafix.co.uk> Message-ID: I am now running xpra 0.14.24 (both client and server) and I just got the stuck spinners again. Anything I can gather to help debug this? On Wed, May 6, 2015 at 11:11 AM, Douglas Doole wrote: > Just hit the problem again. Here's the client log with "-d client" > starting from the server not responding message > > 2015-05-06 11:06:35,078 server is not responding, drawing spinners over > the windows > 2015-05-06 11:06:35,196 ping echo server load=(0, 20, 50), measured client > latency=2ms > 2015-05-06 11:06:35,205 server is OK again > 2015-05-06 11:06:35,206 process_draw 109990 bytes for window 1 using png > encoding with options={'compress_level': 2} > 2015-05-06 11:06:35,219 process_draw 99427 bytes for window 1 using png > encoding with options={'compress_level': 2} > 2015-05-06 11:06:35,228 record_decode_time(True) wid=1, png: 575x768, > 22.3ms > 2015-05-06 11:06:35,231 record_decode_time(True) wid=1, png: 575x768, > 11.0ms > 2015-05-06 11:06:35,287 process_draw 125023 bytes for window 1 using png > encoding with options={'compress_level': 2} > 2015-05-06 11:06:35,297 record_decode_time(True) wid=1, png: 575x768, > 10.3ms > 2015-05-06 11:06:40,269 process_draw 122605 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:40,286 record_decode_time(True) wid=1, png: 575x768, > 17.4ms > 2015-05-06 11:06:42,228 process_draw 124183 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:42,246 record_decode_time(True) wid=1, png: 575x768, > 18.0ms > 2015-05-06 11:06:42,385 process_draw 123751 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:42,403 record_decode_time(True) wid=1, png: 575x768, > 18.2ms > 2015-05-06 11:06:44,065 check_echo_timeout(1430924744063) > last_ping_echoed_time=1430924794068 > 2015-05-06 11:06:44,069 average server latency=6.5, using max wait 1.01s > 2015-05-06 11:06:44,072 ping echo server load=(0, 20, 50), measured client > latency=3ms > 2015-05-06 11:06:47,007 process_draw 125209 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:47,025 record_decode_time(True) wid=1, png: 575x768, > 17.4ms > 2015-05-06 11:06:48,871 process_draw 105618 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:48,884 record_decode_time(True) wid=1, png: 575x768, > 12.4ms > 2015-05-06 11:06:54,071 average server latency=6.5, using max wait 1.01s > 2015-05-06 11:06:54,072 check_echo_timeout(1430924754065) > last_ping_echoed_time=1430924804069 > 2015-05-06 11:06:54,074 ping echo server load=(0, 20, 50), measured client > latency=7ms > 2015-05-06 11:06:54,231 process_draw 106959 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:54,254 record_decode_time(True) wid=1, png: 575x768, > 22.5ms > 2015-05-06 11:06:57,833 process_draw 110440 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:57,847 record_decode_time(True) wid=1, png: 575x768, > 13.5ms > 2015-05-06 11:06:58,493 process_draw 108951 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:58,507 record_decode_time(True) wid=1, png: 575x768, > 13.5ms > 2015-05-06 11:06:58,922 process_draw 104383 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:58,943 record_decode_time(True) wid=1, png: 575x768, > 20.0ms > 2015-05-06 11:06:58,957 process_draw 101628 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:06:58,973 record_decode_time(True) wid=1, png: 575x768, > 15.9ms > 2015-05-06 11:06:59,230 process_draw 753 bytes for window 1 using png > encoding with options={'compress_level': 3, 'store': 634, 'delta': 604} > 2015-05-06 11:06:59,232 record_decode_time(True) wid=1, png: 553x15, 1.9ms > 2015-05-06 11:07:03,057 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,057 new cursor at 6,4 with serial=135, dimensions: > 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) > 2015-05-06 11:07:03,276 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,277 new cursor at 11,11 with serial=3, dimensions: > 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) > 2015-05-06 11:07:03,304 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,305 new cursor at 6,4 with serial=114, dimensions: > 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) > 2015-05-06 11:07:03,448 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,448 new cursor at 11,11 with serial=3, dimensions: > 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) > 2015-05-06 11:07:03,871 update_focus(1, True) focused=None, grabbed=None > 2015-05-06 11:07:03,871 send_focus(1) > 2015-05-06 11:07:03,888 process_draw 90 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:07:03,891 record_decode_time(True) wid=1, png: 7x15, 2.6ms > 2015-05-06 11:07:04,067 check_echo_timeout(1430924764066) > last_ping_echoed_time=1430924814071 > 2015-05-06 11:07:04,072 average server latency=6.5, using max wait 1.01s > 2015-05-06 11:07:04,077 ping echo server load=(0, 20, 50), measured client > latency=3ms > 2015-05-06 11:07:05,009 handle_key_action(GLClientWindow(1 : > GLPixmapBacking(1, (575, 768), None)), {'modifiers': [], 'group': 0, 'string': '\r', 'keyname': 'Return', > 'pressed': True, 'keyval': 65293, 'keycode': 36}>) wid=1 > 2015-05-06 11:07:05,035 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:05,035 new cursor at 8,8 with serial=4, dimensions: > 16x16, len(pixels)=1024, default cursor size is 25, maximum=(64, 64) > 2015-05-06 11:07:05,072 handle_key_action(GLClientWindow(1 : > GLPixmapBacking(1, (575, 768), None)), {'modifiers': [], 'group': 0, 'string': '\r', 'keyname': 'Return', > 'pressed': False, 'keyval': 65293, 'keycode': 36}>) wid=1 > 2015-05-06 11:07:05,112 process_draw 99622 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:07:05,131 record_decode_time(True) wid=1, png: 575x748, > 18.8ms > 2015-05-06 11:07:05,563 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:05,563 new cursor at 11,11 with serial=3, dimensions: > 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) > 2015-05-06 11:07:06,183 update_focus(1, False) focused=1, grabbed=None > 2015-05-06 11:07:06,204 send_focus(0) > 2015-05-06 11:07:06,218 process_draw 104 bytes for window 1 using png > encoding with options={'compress_level': 3} > 2015-05-06 11:07:06,220 record_decode_time(True) wid=1, png: 7x15, 1.0ms > 2015-05-06 11:07:14,074 average server latency=6.5, using max wait 1.01s > 2015-05-06 11:07:14,074 check_echo_timeout(1430924774067) > last_ping_echoed_time=1430924824072 > 2015-05-06 11:07:14,077 ping echo server load=(0, 20, 50), measured client > latency=3ms > 2015-05-06 11:07:24,068 check_echo_timeout(1430924784068) > last_ping_echoed_time=1430924834073 > 2015-05-06 11:07:24,074 average server latency=6.5, using max wait 1.01s > 2015-05-06 11:07:24,077 ping echo server load=(0, 20, 50), measured client > latency=4ms > > Toggling opengl on and off did make the spinner go away. > > On Wed, May 6, 2015 at 9:22 AM, Douglas Doole wrote: > >> > You may also be able to restore things by toggling opengl off then on >> > again from the tray menu. (assuming your system supports opengl) >> >> I am using opengl, so I'll give this a try the next time I see it happen. >> >> > Thanks for reporting it. >> > It would help if I could reproduce the problem on my setup. >> >> If I ever determine something that triggers it, I'll be sure to update >> you. >> >> > Can you tell us which applications were running when the problem >> > occurred? (and also which ones were affected and which ones were not) >> >> Every time I've seen it (3 times now), I've had a mix of konsole and gvim >> up. The problem has affected both window types. On the last occurrence, I >> had two konsole windows and 4 gvim windows and only one konsole window was >> affected. Previously I'd had a similar mix of windows, but it was one gvim >> and two konsole windows that were affected. >> >> On the most recent occurrence I noticed that the troublesome spinner is >> actually static until the window contents change. So, on the stuck konsole, >> the spinner was frozen until I started typing, at which point it rotated >> one segment for each character typed. I also noticed that the stuck spinner >> survives things like window resizing, minimizing, etc. >> >> > Unfortunately, there isn't a specific debug switch for this feature, so >> > you would need to use the big hammer "-d client", which will also log a >> > lot of unrelated things. >> > And even if the logging was more specific, it may not tell us enough to >> > debug further. >> >> On the last occurrence, I captured the basic client log, but all it >> showed was the "server is not responding, drawing spinners over the wind >> ows" message. I'll add "-d client" and see if I get anything useful. >> >> On Wed, May 6, 2015 at 6:49 AM, Antoine Martin >> wrote: >> >>> Hi Douglas, >>> >>> On 06/05/15 00:00, Douglas Doole wrote: >>> > Since upgrading to xpra 0.14.23, I've had a couple instances where >>> I've had >>> > a network hiccup and the spinners have appeared. Yet once the network >>> is >>> > moving again, the spinners have remained on some of the windows (not >>> all) >>> > even though they are otherwise responding properly. That is, I'm >>> editing >>> > text, cutting & pasting, etc. but the spinner is sitting in front of >>> > everything spinning away. Needless to say, it makes the affected >>> windows >>> > pretty much unusable. >>> > >>> > Once this has happened, the only way I can clear things up is to drop >>> the >>> > client connection and re-connect to the server. >>> You may also be able to restore things by toggling opengl off then on >>> again from the tray menu. (assuming your system supports opengl) >>> > I am not able to reproduce this on demand, but it has happened a couple >>> > times now. I have no idea what the trigger might be. I had not seen >>> this >>> > problem before upgrading to 0.14.23. Bother the server and the client >>> are >>> > running Ubuntu 14.04. >>> Thanks for reporting it. >>> It would help if I could reproduce the problem on my setup. >>> Can you tell us which applications were running when the problem >>> occurred? (and also which ones were affected and which ones were not) >>> > Unfortunately, I don't have a log from either of the times I've seen it >>> > happen. Anything in particular I should capture to help debug it? >>> Unfortunately, there isn't a specific debug switch for this feature, so >>> you would need to use the big hammer "-d client", which will also log a >>> lot of unrelated things. >>> And even if the logging was more specific, it may not tell us enough to >>> debug further. >>> >>> Looking at the spinner code, I found a couple of issues, maybe one of >>> those is what was causing your problem. >>> These fixes will be included in 0.14.24. >>> >>> Thanks >>> Antoine >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> >> >> >> -- >> -- Doug Doole >> >> aibohphobia - The irrational fear of palindromes >> > > > > -- > -- Doug Doole > > aibohphobia - The irrational fear of palindromes > -- -- Doug Doole aibohphobia - The irrational fear of palindromes From antoine at nagafix.co.uk Tue May 19 16:23:53 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 19 May 2015 22:23:53 +0700 Subject: [winswitch] xpra 0.14.23 - Spinners not going away In-Reply-To: References: <5549F1BB.40609@nagafix.co.uk> Message-ID: <555B5589.3000508@nagafix.co.uk> On 19/05/15 22:20, Douglas Doole wrote: > I am now running xpra 0.14.24 (both client and server) and I just got > the stuck spinners again. Anything I can gather to help debug this? Yes, please file a ticket following the guidelines here: http://xpra.org/trac/wiki/ReportingBugs I'll make sure we track it down. Cheers Antoine > > On Wed, May 6, 2015 at 11:11 AM, Douglas Doole > wrote: > > Just hit the problem again. Here's the client log with "-d client" > starting from the server not responding message > > 2015-05-06 11:06:35,078 server is not responding, drawing spinners > over the windows > 2015-05-06 11:06:35,196 ping echo server load=(0, 20, 50), > measured client latency=2ms > 2015-05-06 11:06:35,205 server is OK again > 2015-05-06 11:06:35,206 process_draw 109990 bytes for window 1 > using png encoding with options={'compress_level': 2} > 2015-05-06 11:06:35,219 process_draw 99427 bytes for window 1 > using png encoding with options={'compress_level': 2} > 2015-05-06 11:06:35,228 record_decode_time(True) wid=1, png: > 575x768, 22.3ms > 2015-05-06 11:06:35,231 record_decode_time(True) wid=1, png: > 575x768, 11.0ms > 2015-05-06 11:06:35,287 process_draw 125023 bytes for window 1 > using png encoding with options={'compress_level': 2} > 2015-05-06 11:06:35,297 record_decode_time(True) wid=1, png: > 575x768, 10.3ms > 2015-05-06 11:06:40,269 process_draw 122605 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:40,286 record_decode_time(True) wid=1, png: > 575x768, 17.4ms > 2015-05-06 11:06:42,228 process_draw 124183 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:42,246 record_decode_time(True) wid=1, png: > 575x768, 18.0ms > 2015-05-06 11:06:42,385 process_draw 123751 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:42,403 record_decode_time(True) wid=1, png: > 575x768, 18.2ms > 2015-05-06 11:06:44,065 check_echo_timeout(1430924744063) > last_ping_echoed_time=1430924794068 > 2015-05-06 11:06:44,069 average server latency=6.5, using max wait > 1.01s > 2015-05-06 11:06:44,072 ping echo server load=(0, 20, 50), > measured client latency=3ms > 2015-05-06 11:06:47,007 process_draw 125209 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:47,025 record_decode_time(True) wid=1, png: > 575x768, 17.4ms > 2015-05-06 11:06:48,871 process_draw 105618 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:48,884 record_decode_time(True) wid=1, png: > 575x768, 12.4ms > 2015-05-06 11:06:54,071 average server latency=6.5, using max wait > 1.01s > 2015-05-06 11:06:54,072 check_echo_timeout(1430924754065) > last_ping_echoed_time=1430924804069 > 2015-05-06 11:06:54,074 ping echo server load=(0, 20, 50), > measured client latency=7ms > 2015-05-06 11:06:54,231 process_draw 106959 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:54,254 record_decode_time(True) wid=1, png: > 575x768, 22.5ms > 2015-05-06 11:06:57,833 process_draw 110440 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:57,847 record_decode_time(True) wid=1, png: > 575x768, 13.5ms > 2015-05-06 11:06:58,493 process_draw 108951 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:58,507 record_decode_time(True) wid=1, png: > 575x768, 13.5ms > 2015-05-06 11:06:58,922 process_draw 104383 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:58,943 record_decode_time(True) wid=1, png: > 575x768, 20.0ms > 2015-05-06 11:06:58,957 process_draw 101628 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:06:58,973 record_decode_time(True) wid=1, png: > 575x768, 15.9ms > 2015-05-06 11:06:59,230 process_draw 753 bytes for window 1 using > png encoding with options={'compress_level': 3, 'store': 634, > 'delta': 604} > 2015-05-06 11:06:59,232 record_decode_time(True) wid=1, png: > 553x15, 1.9ms > 2015-05-06 11:07:03,057 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,057 new cursor at 6,4 with serial=135, > dimensions: 24x24, len(pixels)=2304, default cursor size is 25, > maximum=(64, 64) > 2015-05-06 11:07:03,276 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,277 new cursor at 11,11 with serial=3, > dimensions: 24x24, len(pixels)=2304, default cursor size is 25, > maximum=(64, 64) > 2015-05-06 11:07:03,304 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,305 new cursor at 6,4 with serial=114, > dimensions: 24x24, len(pixels)=2304, default cursor size is 25, > maximum=(64, 64) > 2015-05-06 11:07:03,448 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:03,448 new cursor at 11,11 with serial=3, > dimensions: 24x24, len(pixels)=2304, default cursor size is 25, > maximum=(64, 64) > 2015-05-06 11:07:03,871 update_focus(1, True) focused=None, > grabbed=None > 2015-05-06 11:07:03,871 send_focus(1) > 2015-05-06 11:07:03,888 process_draw 90 bytes for window 1 using > png encoding with options={'compress_level': 3} > 2015-05-06 11:07:03,891 record_decode_time(True) wid=1, png: 7x15, > 2.6ms > 2015-05-06 11:07:04,067 check_echo_timeout(1430924764066) > last_ping_echoed_time=1430924814071 > 2015-05-06 11:07:04,072 average server latency=6.5, using max wait > 1.01s > 2015-05-06 11:07:04,077 ping echo server load=(0, 20, 50), > measured client latency=3ms > 2015-05-06 11:07:05,009 handle_key_action(GLClientWindow(1 : > GLPixmapBacking(1, (575, 768), None)), contents: {'modifiers': [], 'group': 0, 'string': '\r', 'keyname': > 'Return', 'pressed': True, 'keyval': 65293, 'keycode': 36}>) wid=1 > 2015-05-06 11:07:05,035 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:05,035 new cursor at 8,8 with serial=4, > dimensions: 16x16, len(pixels)=1024, default cursor size is 25, > maximum=(64, 64) > 2015-05-06 11:07:05,072 handle_key_action(GLClientWindow(1 : > GLPixmapBacking(1, (575, 768), None)), contents: {'modifiers': [], 'group': 0, 'string': '\r', 'keyname': > 'Return', 'pressed': False, 'keyval': 65293, 'keycode': 36}>) wid=1 > 2015-05-06 11:07:05,112 process_draw 99622 bytes for window 1 > using png encoding with options={'compress_level': 3} > 2015-05-06 11:07:05,131 record_decode_time(True) wid=1, png: > 575x748, 18.8ms > 2015-05-06 11:07:05,563 server cursor sizes: default=85, max=(64, 64) > 2015-05-06 11:07:05,563 new cursor at 11,11 with serial=3, > dimensions: 24x24, len(pixels)=2304, default cursor size is 25, > maximum=(64, 64) > 2015-05-06 11:07:06,183 update_focus(1, False) focused=1, grabbed=None > 2015-05-06 11:07:06,204 send_focus(0) > 2015-05-06 11:07:06,218 process_draw 104 bytes for window 1 using > png encoding with options={'compress_level': 3} > 2015-05-06 11:07:06,220 record_decode_time(True) wid=1, png: 7x15, > 1.0ms > 2015-05-06 11:07:14,074 average server latency=6.5, using max wait > 1.01s > 2015-05-06 11:07:14,074 check_echo_timeout(1430924774067) > last_ping_echoed_time=1430924824072 > 2015-05-06 11:07:14,077 ping echo server load=(0, 20, 50), > measured client latency=3ms > 2015-05-06 11:07:24,068 check_echo_timeout(1430924784068) > last_ping_echoed_time=1430924834073 > 2015-05-06 11:07:24,074 average server latency=6.5, using max wait > 1.01s > 2015-05-06 11:07:24,077 ping echo server load=(0, 20, 50), > measured client latency=4ms > > Toggling opengl on and off did make the spinner go away. > > On Wed, May 6, 2015 at 9:22 AM, Douglas Doole > wrote: > > > You may also be able to restore things by toggling opengl off then on > > again from the tray menu. (assuming your system supports opengl) > > I am using opengl, so I'll give this a try the next time I see > it happen. > > > Thanks for reporting it. > > It would help if I could reproduce the problem on my setup. > > If I ever determine something that triggers it, I'll be sure > to update you. > > > Can you tell us which applications were running when the problem > > occurred? (and also which ones were affected and which ones > were not) > > Every time I've seen it (3 times now), I've had a mix of > konsole and gvim up. The problem has affected both window > types. On the last occurrence, I had two konsole windows and 4 > gvim windows and only one konsole window was affected. > Previously I'd had a similar mix of windows, but it was one > gvim and two konsole windows that were affected. > > On the most recent occurrence I noticed that the troublesome > spinner is actually static until the window contents change. > So, on the stuck konsole, the spinner was frozen until I > started typing, at which point it rotated one segment for each > character typed. I also noticed that the stuck spinner > survives things like window resizing, minimizing, etc. > > > Unfortunately, there isn't a specific debug switch for this > feature, so > > you would need to use the big hammer "-d client", which will > also log a > > lot of unrelated things. > > And even if the logging was more specific, it may not tell > us enough to > > debug further. > > On the last occurrence, I captured the basic client log, but > all it showed was the "server is not responding, drawing > spinners over the wind > ows" message. I'll add "-d client" and see if I get anything > useful. > > On Wed, May 6, 2015 at 6:49 AM, Antoine Martin > > wrote: > > Hi Douglas, > > On 06/05/15 00:00, Douglas Doole wrote: > > Since upgrading to xpra 0.14.23, I've had a couple > instances where I've had > > a network hiccup and the spinners have appeared. Yet > once the network is > > moving again, the spinners have remained on some of the > windows (not all) > > even though they are otherwise responding properly. That > is, I'm editing > > text, cutting & pasting, etc. but the spinner is sitting > in front of > > everything spinning away. Needless to say, it makes the > affected windows > > pretty much unusable. > > > > Once this has happened, the only way I can clear things > up is to drop the > > client connection and re-connect to the server. > You may also be able to restore things by toggling opengl > off then on > again from the tray menu. (assuming your system supports > opengl) > > I am not able to reproduce this on demand, but it has happened a couple > > times now. I have no idea what the trigger might be. I > had not seen this > > problem before upgrading to 0.14.23. Bother the server > and the client are > > running Ubuntu 14.04. > Thanks for reporting it. > It would help if I could reproduce the problem on my setup. > Can you tell us which applications were running when the > problem > occurred? (and also which ones were affected and which > ones were not) > > Unfortunately, I don't have a log from either of the times I've seen it > > happen. Anything in particular I should capture to help > debug it? > Unfortunately, there isn't a specific debug switch for > this feature, so > you would need to use the big hammer "-d client", which > will also log a > lot of unrelated things. > And even if the logging was more specific, it may not tell > us enough to > debug further. > > Looking at the spinner code, I found a couple of issues, > maybe one of > those is what was causing your problem. > These fixes will be included in 0.14.24. > > Thanks > Antoine > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > -- > -- Doug Doole > > aibohphobia - The irrational fear of palindromes > > > > > -- > -- Doug Doole > > aibohphobia - The irrational fear of palindromes > > > > > -- > -- Doug Doole > > aibohphobia - The irrational fear of palindromes From antoine at nagafix.co.uk Wed May 20 06:36:23 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 20 May 2015 12:36:23 +0700 Subject: [winswitch] [ANNOUNCE] winswitch 0.12.21 Message-ID: <555C1D57.8020003@nagafix.co.uk> Hi, Version 0.12.21 is available now: http://winswitch.org/downloads/ This minor update brings better compatibility with the latest and upcoming versions of Xpra. The binary builds (MS Windows and OSX) include Xpra 0.14.24 You will need to be running this version when xpra 0.15 lands (soon) as xpra 0.15 onwards is no longer compatible with the outdated version that were shipped with previous versions of the winswitch installer. Full (short) release notes show very few other changes: * improved compatibility with newer versions of xpra * fix loading of desktop files with multiple entries * remove bashism from script Cheers Antoine From basd1 at fastbk.com Sat May 23 20:12:40 2015 From: basd1 at fastbk.com (basd) Date: Sat, 23 May 2015 12:12:40 -0700 Subject: [winswitch] openSuSE 13.2 - some observations In-Reply-To: <555B5589.3000508@nagafix.co.uk> References: <5549F1BB.40609@nagafix.co.uk> <555B5589.3000508@nagafix.co.uk> Message-ID: <5560D128.9090007@fastbk.com> Just FYI 1. I built a winswitch-0.12.21 rpm for openSuSE 13.2 and installed it. No problems. 2. I also ran the subversion version winswtch-0.12.21 from the Eric6 python IDE. No problems. 3. I accidentally removed xpra and discovered this: If I try to run application sessions from my openSuSE 13.1 server when there is no xpra, they actually come up in a VNC session. (This is actually an improvement, because Winswitch-0.12.21 on my openSUSE 13.1 server will provide VNC desktops but not Xpra application session. (Haven't upgraded it yet, so don't know if this is Winswitch or Xpra related.) 3a. When I run winswitch and xpra IS installed, there are a lot more gobject errors when winswitch starts up. 4. I could not build an xpra-0.14.24 rpm. I have two spec files -- don't remember where I found them, but somewhere on the xpra site. On the more complex spec file (with the options for fedora, I get an "fg: no job control" error and nothing compiles. With the other spec file, a lot of compiling happens and then in the codec section it crashes with 'command "gcc" failed exit status 1'. 4a. I installed a lot more dependencies based on these spec files, but it didn't solve anything. 5. I have the subversion version of xpra-0.14.24, also in the Eric6 IDE. Unfortunately, it doesn't run because from the top at the "from platform import init" in xpra-launcher Eric can't find init. I think I'll try xpra-0.15 and see what happens. I realize that xpra-0.14 is sort of old news at this point. From basd1 at fastbk.com Sat May 23 20:24:48 2015 From: basd1 at fastbk.com (basd) Date: Sat, 23 May 2015 12:24:48 -0700 Subject: [winswitch] openSuSE 13.2 - some observations In-Reply-To: <5560D377.1090906@daltrey.org> References: <5549F1BB.40609@nagafix.co.uk> <555B5589.3000508@nagafix.co.uk> <5560D128.9090007@fastbk.com> <5560D377.1090906@daltrey.org> Message-ID: <5560D400.1030903@fastbk.com> Sorry, Antoine ... sent this from my wrong email account initially, probably bounces to the moderator cue or something. On 05/23/2015 12:22 PM, Barrington Daltrey wrote: > Oh, wait ... the version from subversion probably is 0.15, since it's currently active and at 9514? > > I'll have to try and figure out why the initial import statement is crashing for me ... > > On 05/23/2015 12:12 PM, basd wrote: >> I think I'll try xpra-0.15 and see what happens. I realize that xpra-0.14 is sort of old news at >> this point. >> >> >> From daltrey at daltrey.org Sat May 23 20:22:31 2015 From: daltrey at daltrey.org (Barrington Daltrey) Date: Sat, 23 May 2015 12:22:31 -0700 Subject: [winswitch] openSuSE 13.2 - some observations In-Reply-To: <5560D128.9090007@fastbk.com> References: <5549F1BB.40609@nagafix.co.uk> <555B5589.3000508@nagafix.co.uk> <5560D128.9090007@fastbk.com> Message-ID: <5560D377.1090906@daltrey.org> Oh, wait ... the version from subversion probably is 0.15, since it's currently active and at 9514? I'll have to try and figure out why the initial import statement is crashing for me ... On 05/23/2015 12:12 PM, basd wrote: > I think I'll try xpra-0.15 and see what happens. I realize that xpra-0.14 is sort of old news at > this point. > > > From basd1 at fastbk.com Sun May 24 00:01:21 2015 From: basd1 at fastbk.com (basd) Date: Sat, 23 May 2015 16:01:21 -0700 Subject: [winswitch] openSuSE 13.2 - more observations In-Reply-To: <5560D128.9090007@fastbk.com> References: <5549F1BB.40609@nagafix.co.uk> <555B5589.3000508@nagafix.co.uk> <5560D128.9090007@fastbk.com> Message-ID: <556106C1.2090703@fastbk.com> 1. I was successful creating an xpra-0.14.24 rpm on a different computer with a different .spec file. No idea what the difference is. 2. Before I updated xpra, connecting winswitch-0.12.21 to winswitch-0.12.20 reported that xpra was not available. 2a. This was not a bad thing, because I discovered that if there is no xpra, then it's possible to choose vnc for an application connection. Since my openSuSE 13.2 computers will not serve vnc desktop sessions, this is useful (and it would be nice if the vnc and ssh options were available even when xpra is available). 2b. I noticed that the "application session" would invoke the application in an openbox window (or icewm, depending on what is available on the server, I guess). 2c. With the foregoing information, I found that I could open a full vnc desktop session from the application "custom command" option, as follows: The following work: ICEWM -- "icewm --replace" LXDE -- "lxsession" XFCE -- "xfwm4 --replace & xfce4-session" KDE4 -- "plasma-desktop & kwin --replace" (but logout doesn't work so you have to use winswitch_applet to kill the session) I could not figure out how to start enlightenment. That is all the window managers/desktops I have installed. 2d. I know worrying about how to get VNC sessions running is sort of the opposite of getting xpra to work well, since its focus is on getting individual remote applications to integrate with the local desktop. But, since the normal winswitch desktop mode does not work for me, this is very useful information. From dougdoole at gmail.com Mon May 25 16:20:54 2015 From: dougdoole at gmail.com (Douglas Doole) Date: Mon, 25 May 2015 11:20:54 -0400 Subject: [winswitch] xpra 0.14.23 - Spinners not going away In-Reply-To: <555B5589.3000508@nagafix.co.uk> References: <5549F1BB.40609@nagafix.co.uk> <555B5589.3000508@nagafix.co.uk> Message-ID: I just opened ticket 871 for this problem. (Sorry for the delay, I wanted to get the Bug Report tool information during an instance of the problem, and xpra had been well behaved last week.) On Tue, May 19, 2015 at 11:23 AM, Antoine Martin wrote: > On 19/05/15 22:20, Douglas Doole wrote: > > I am now running xpra 0.14.24 (both client and server) and I just got the > stuck spinners again. Anything I can gather to help debug this? > > Yes, please file a ticket following the guidelines here: > http://xpra.org/trac/wiki/ReportingBugs > I'll make sure we track it down. > > Cheers > Antoine > > > > On Wed, May 6, 2015 at 11:11 AM, Douglas Doole > wrote: > >> Just hit the problem again. Here's the client log with "-d client" >> starting from the server not responding message >> >> 2015-05-06 11:06:35,078 server is not responding, drawing spinners over >> the windows >> 2015-05-06 11:06:35,196 ping echo server load=(0, 20, 50), measured >> client latency=2ms >> 2015-05-06 11:06:35,205 server is OK again >> 2015-05-06 11:06:35,206 process_draw 109990 bytes for window 1 using png >> encoding with options={'compress_level': 2} >> 2015-05-06 11:06:35,219 process_draw 99427 bytes for window 1 using png >> encoding with options={'compress_level': 2} >> 2015-05-06 11:06:35,228 record_decode_time(True) wid=1, png: 575x768, >> 22.3ms >> 2015-05-06 11:06:35,231 record_decode_time(True) wid=1, png: 575x768, >> 11.0ms >> 2015-05-06 11:06:35,287 process_draw 125023 bytes for window 1 using png >> encoding with options={'compress_level': 2} >> 2015-05-06 11:06:35,297 record_decode_time(True) wid=1, png: 575x768, >> 10.3ms >> 2015-05-06 11:06:40,269 process_draw 122605 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:40,286 record_decode_time(True) wid=1, png: 575x768, >> 17.4ms >> 2015-05-06 11:06:42,228 process_draw 124183 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:42,246 record_decode_time(True) wid=1, png: 575x768, >> 18.0ms >> 2015-05-06 11:06:42,385 process_draw 123751 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:42,403 record_decode_time(True) wid=1, png: 575x768, >> 18.2ms >> 2015-05-06 11:06:44,065 check_echo_timeout(1430924744063) >> last_ping_echoed_time=1430924794068 >> 2015-05-06 11:06:44,069 average server latency=6.5, using max wait 1.01s >> 2015-05-06 11:06:44,072 ping echo server load=(0, 20, 50), measured >> client latency=3ms >> 2015-05-06 11:06:47,007 process_draw 125209 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:47,025 record_decode_time(True) wid=1, png: 575x768, >> 17.4ms >> 2015-05-06 11:06:48,871 process_draw 105618 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:48,884 record_decode_time(True) wid=1, png: 575x768, >> 12.4ms >> 2015-05-06 11:06:54,071 average server latency=6.5, using max wait 1.01s >> 2015-05-06 11:06:54,072 check_echo_timeout(1430924754065) >> last_ping_echoed_time=1430924804069 >> 2015-05-06 11:06:54,074 ping echo server load=(0, 20, 50), measured >> client latency=7ms >> 2015-05-06 11:06:54,231 process_draw 106959 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:54,254 record_decode_time(True) wid=1, png: 575x768, >> 22.5ms >> 2015-05-06 11:06:57,833 process_draw 110440 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:57,847 record_decode_time(True) wid=1, png: 575x768, >> 13.5ms >> 2015-05-06 11:06:58,493 process_draw 108951 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:58,507 record_decode_time(True) wid=1, png: 575x768, >> 13.5ms >> 2015-05-06 11:06:58,922 process_draw 104383 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:58,943 record_decode_time(True) wid=1, png: 575x768, >> 20.0ms >> 2015-05-06 11:06:58,957 process_draw 101628 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:06:58,973 record_decode_time(True) wid=1, png: 575x768, >> 15.9ms >> 2015-05-06 11:06:59,230 process_draw 753 bytes for window 1 using png >> encoding with options={'compress_level': 3, 'store': 634, 'delta': 604} >> 2015-05-06 11:06:59,232 record_decode_time(True) wid=1, png: 553x15, 1.9ms >> 2015-05-06 11:07:03,057 server cursor sizes: default=85, max=(64, 64) >> 2015-05-06 11:07:03,057 new cursor at 6,4 with serial=135, dimensions: >> 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) >> 2015-05-06 11:07:03,276 server cursor sizes: default=85, max=(64, 64) >> 2015-05-06 11:07:03,277 new cursor at 11,11 with serial=3, dimensions: >> 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) >> 2015-05-06 11:07:03,304 server cursor sizes: default=85, max=(64, 64) >> 2015-05-06 11:07:03,305 new cursor at 6,4 with serial=114, dimensions: >> 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) >> 2015-05-06 11:07:03,448 server cursor sizes: default=85, max=(64, 64) >> 2015-05-06 11:07:03,448 new cursor at 11,11 with serial=3, dimensions: >> 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) >> 2015-05-06 11:07:03,871 update_focus(1, True) focused=None, grabbed=None >> 2015-05-06 11:07:03,871 send_focus(1) >> 2015-05-06 11:07:03,888 process_draw 90 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:07:03,891 record_decode_time(True) wid=1, png: 7x15, 2.6ms >> 2015-05-06 11:07:04,067 check_echo_timeout(1430924764066) >> last_ping_echoed_time=1430924814071 >> 2015-05-06 11:07:04,072 average server latency=6.5, using max wait 1.01s >> 2015-05-06 11:07:04,077 ping echo server load=(0, 20, 50), measured >> client latency=3ms >> 2015-05-06 11:07:05,009 handle_key_action(GLClientWindow(1 : >> GLPixmapBacking(1, (575, 768), None)), > {'modifiers': [], 'group': 0, 'string': '\r', 'keyname': 'Return', >> 'pressed': True, 'keyval': 65293, 'keycode': 36}>) wid=1 >> 2015-05-06 11:07:05,035 server cursor sizes: default=85, max=(64, 64) >> 2015-05-06 11:07:05,035 new cursor at 8,8 with serial=4, dimensions: >> 16x16, len(pixels)=1024, default cursor size is 25, maximum=(64, 64) >> 2015-05-06 11:07:05,072 handle_key_action(GLClientWindow(1 : >> GLPixmapBacking(1, (575, 768), None)), > {'modifiers': [], 'group': 0, 'string': '\r', 'keyname': 'Return', >> 'pressed': False, 'keyval': 65293, 'keycode': 36}>) wid=1 >> 2015-05-06 11:07:05,112 process_draw 99622 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:07:05,131 record_decode_time(True) wid=1, png: 575x748, >> 18.8ms >> 2015-05-06 11:07:05,563 server cursor sizes: default=85, max=(64, 64) >> 2015-05-06 11:07:05,563 new cursor at 11,11 with serial=3, dimensions: >> 24x24, len(pixels)=2304, default cursor size is 25, maximum=(64, 64) >> 2015-05-06 11:07:06,183 update_focus(1, False) focused=1, grabbed=None >> 2015-05-06 11:07:06,204 send_focus(0) >> 2015-05-06 11:07:06,218 process_draw 104 bytes for window 1 using png >> encoding with options={'compress_level': 3} >> 2015-05-06 11:07:06,220 record_decode_time(True) wid=1, png: 7x15, 1.0ms >> 2015-05-06 11:07:14,074 average server latency=6.5, using max wait 1.01s >> 2015-05-06 11:07:14,074 check_echo_timeout(1430924774067) >> last_ping_echoed_time=1430924824072 >> 2015-05-06 11:07:14,077 ping echo server load=(0, 20, 50), measured >> client latency=3ms >> 2015-05-06 11:07:24,068 check_echo_timeout(1430924784068) >> last_ping_echoed_time=1430924834073 >> 2015-05-06 11:07:24,074 average server latency=6.5, using max wait 1.01s >> 2015-05-06 11:07:24,077 ping echo server load=(0, 20, 50), measured >> client latency=4ms >> >> Toggling opengl on and off did make the spinner go away. >> >> On Wed, May 6, 2015 at 9:22 AM, Douglas Doole >> wrote: >> >>> > You may also be able to restore things by toggling opengl off then >>> on >>> > again from the tray menu. (assuming your system supports opengl) >>> >>> I am using opengl, so I'll give this a try the next time I see it >>> happen. >>> >>> > Thanks for reporting it. >>> > It would help if I could reproduce the problem on my setup. >>> >>> If I ever determine something that triggers it, I'll be sure to update >>> you. >>> >>> > Can you tell us which applications were running when the problem >>> > occurred? (and also which ones were affected and which ones were not) >>> >>> Every time I've seen it (3 times now), I've had a mix of konsole and >>> gvim up. The problem has affected both window types. On the last >>> occurrence, I had two konsole windows and 4 gvim windows and only one >>> konsole window was affected. Previously I'd had a similar mix of windows, >>> but it was one gvim and two konsole windows that were affected. >>> >>> On the most recent occurrence I noticed that the troublesome spinner >>> is actually static until the window contents change. So, on the stuck >>> konsole, the spinner was frozen until I started typing, at which point it >>> rotated one segment for each character typed. I also noticed that the stuck >>> spinner survives things like window resizing, minimizing, etc. >>> >>> > Unfortunately, there isn't a specific debug switch for this feature, so >>> > you would need to use the big hammer "-d client", which will also log a >>> > lot of unrelated things. >>> > And even if the logging was more specific, it may not tell us enough to >>> > debug further. >>> >>> On the last occurrence, I captured the basic client log, but all it >>> showed was the "server is not responding, drawing spinners over the wind >>> ows" message. I'll add "-d client" and see if I get anything useful. >>> >>> On Wed, May 6, 2015 at 6:49 AM, Antoine Martin >>> wrote: >>> >>>> Hi Douglas, >>>> >>>> On 06/05/15 00:00, Douglas Doole wrote: >>>> > Since upgrading to xpra 0.14.23, I've had a couple instances where >>>> I've had >>>> > a network hiccup and the spinners have appeared. Yet once the network >>>> is >>>> > moving again, the spinners have remained on some of the windows (not >>>> all) >>>> > even though they are otherwise responding properly. That is, I'm >>>> editing >>>> > text, cutting & pasting, etc. but the spinner is sitting in front of >>>> > everything spinning away. Needless to say, it makes the affected >>>> windows >>>> > pretty much unusable. >>>> > >>>> > Once this has happened, the only way I can clear things up is to drop >>>> the >>>> > client connection and re-connect to the server. >>>> You may also be able to restore things by toggling opengl off then on >>>> again from the tray menu. (assuming your system supports opengl) >>>> > I am not able to reproduce this on demand, but it has happened a >>>> couple >>>> > times now. I have no idea what the trigger might be. I had not seen >>>> this >>>> > problem before upgrading to 0.14.23. Bother the server and the client >>>> are >>>> > running Ubuntu 14.04. >>>> Thanks for reporting it. >>>> It would help if I could reproduce the problem on my setup. >>>> Can you tell us which applications were running when the problem >>>> occurred? (and also which ones were affected and which ones were not) >>>> > Unfortunately, I don't have a log from either of the times I've seen >>>> it >>>> > happen. Anything in particular I should capture to help debug it? >>>> Unfortunately, there isn't a specific debug switch for this feature, so >>>> you would need to use the big hammer "-d client", which will also log a >>>> lot of unrelated things. >>>> And even if the logging was more specific, it may not tell us enough to >>>> debug further. >>>> >>>> Looking at the spinner code, I found a couple of issues, maybe one of >>>> those is what was causing your problem. >>>> These fixes will be included in 0.14.24. >>>> >>>> Thanks >>>> Antoine >>>> >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> >>> >>> >>> -- >>> -- Doug Doole >>> >>> aibohphobia - The irrational fear of palindromes >>> >> >> >> >> -- >> -- Doug Doole >> >> aibohphobia - The irrational fear of palindromes >> > > > > -- > -- Doug Doole > > aibohphobia - The irrational fear of palindromes > > > -- -- Doug Doole aibohphobia - The irrational fear of palindromes From fhenryco at yahoo.fr Tue May 26 09:53:51 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Tue, 26 May 2015 08:53:51 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <55245084.5020205@fastbk.com> References: <55245084.5020205@fastbk.com> Message-ID: <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> hello , Now i have tested successfully xpra ?for application forwarding ?between a Linux server station and?an odroid (client) . However i cant make it work for the full desktop forwarding. I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 DISPLAY=:200 fluxbox&and get message Xlib: ?extension "RANDR" missing on display ":200" ?? what does it mean i have no idea Then on the client?xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen best, Fred Le Mardi 7 avril 2015 23h54, basd a ?crit : In my earlier post I mentioned problems connecting to server socket for desktops.? However, with implementation of xpra-0.14.21 I am able to run xpra sessions. Interestingly, I can spawn multiple child windows from an xpra remote application that function as windows on the client -- but can be moved collectively to another client.? This is a reasonable substitute for desktop sessions. Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this appears to give me the same functionality as running these programs in an iceWM desktop session, with the additional advantage that the xpra child windows function as windows on the client desktop itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org FAQs seem to indicate applications are problematic to run under KDE/Plasma. I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. Other points: *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and I can use sftp, ssh, etc. to the server. *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as "unknown".? I can't access or kill this session. *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in opSU 13.2 repositories. For reference: Server 1: 6 core AMD x86_64 openSuSE 13.1 linux kernel 3.11.10-25-desktop KDE platform 4.14.6 winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 xpra-0.14.4 (also in an rpm I built from sources) remote desktops work / remote applications do not work Server 2: 8 core AMD x86_64 openSuSE 13.2 linux kernel 3.19.3-1-gf10e7fc-desktop KDE platform 4.14.6 winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) remote desktops do not work / remote applications do work, per above description. Barrington Daltrey _______________________________________________ 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 May 26 11:57:15 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 26 May 2015 17:57:15 +0700 Subject: [winswitch] interesting development In-Reply-To: <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5564518B.5090902@nagafix.co.uk> On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: > hello , > Now i have tested successfully xpra for application forwarding between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 > DISPLAY=:200 fluxbox&and get message > Xlib: extension "RANDR" missing on display ":200" Some window managers may require randr, though I don't think fluxbox does. You might want to try with Xephyr instead of Xnest. > ?? what does it mean i have no idea > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen By "a black screen", I assume that you mean you get a window whose contents are black? The fact that something shows up at all tells me that xpra is forwarding something, which should be the Xnest window. Have you tried another window manager instead of fluxbox? Have you tried also starting and xterm on that display? Does that show up? Antoine > best, > Fred > > > Le Mardi 7 avril 2015 23h54, basd a ?crit : > > > In my earlier post I mentioned problems connecting to server socket for desktops. However, with > implementation of xpra-0.14.21 I am able to run xpra sessions. > > Interestingly, I can spawn multiple child windows from an xpra remote application that function as > windows on the client -- but can be moved collectively to another client. This is a reasonable > substitute for desktop sessions. > > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu > for launching favorite programs. Using that script, I can launch an xterm session in xpra, run my > menu bash script and launch separate programs from it. For instance, I can run firefox, dolphin > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel). So far, this > appears to give me the same functionality as running these programs in an iceWM desktop session, > with the additional advantage that the xpra child windows function as windows on the client desktop > itself. Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org > FAQs seem to indicate applications are problematic to run under KDE/Plasma. > > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. > > Other points: > > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement > this because I use a VPN, so I have always used direct connections. Ssh is active on the server and > I can use sftp, ssh, etc. to the server. > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as > "unknown". I can't access or kill this session. > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in > opSU 13.2 repositories. > > > For reference: > > Server 1: > 6 core AMD x86_64 > openSuSE 13.1 > linux kernel 3.11.10-25-desktop > KDE platform 4.14.6 > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 > xpra-0.14.4 (also in an rpm I built from sources) > > remote desktops work / remote applications do not work > > Server 2: > 8 core AMD x86_64 > openSuSE 13.2 > linux kernel 3.19.3-1-gf10e7fc-desktop > KDE platform 4.14.6 > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) > > remote desktops do not work / remote applications do work, per above description. > > Barrington Daltrey > > > > > > _______________________________________________ > 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 fhenryco at yahoo.fr Tue May 26 18:37:53 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Tue, 26 May 2015 17:37:53 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <5564518B.5090902@nagafix.co.uk> References: <5564518B.5090902@nagafix.co.uk> Message-ID: <521530237.4186744.1432661873358.JavaMail.yahoo@mail.yahoo.com> thanks for answering, yes xterm forwarding works. and yes i get a window which content is black for Xnest. i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: > hello , > Now i have tested successfully xpra? for application forwarding? between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 > DISPLAY=:200 fluxbox&and get message > Xlib:? extension "RANDR" missing on display ":200" Some window managers may require randr, though I don't think fluxbox does. You might want to try with Xephyr instead of Xnest. > ?? what does it mean i have no idea > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen By "a black screen", I assume that you mean you get a window whose contents are black? The fact that something shows up at all tells me that xpra is forwarding something, which should be the Xnest window. Have you tried another window manager instead of fluxbox? Have you tried also starting and xterm on that display? Does that show up? Antoine > best, > Fred > > >? ? ? Le Mardi 7 avril 2015 23h54, basd a ?crit : >? ? > >? In my earlier post I mentioned problems connecting to server socket for desktops.? However, with > implementation of xpra-0.14.21 I am able to run xpra sessions. > > Interestingly, I can spawn multiple child windows from an xpra remote application that function as > windows on the client -- but can be moved collectively to another client.? This is a reasonable > substitute for desktop sessions. > > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu > for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my > menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this > appears to give me the same functionality as running these programs in an iceWM desktop session, > with the additional advantage that the xpra child windows function as windows on the client desktop > itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org > FAQs seem to indicate applications are problematic to run under KDE/Plasma. > > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. > > Other points: > > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement > this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and > I can use sftp, ssh, etc. to the server. > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as > "unknown".? I can't access or kill this session. > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in > opSU 13.2 repositories. > > > For reference: > > Server 1: > 6 core AMD x86_64 > openSuSE 13.1 > linux kernel 3.11.10-25-desktop > KDE platform 4.14.6 > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 > xpra-0.14.4 (also in an rpm I built from sources) > > remote desktops work / remote applications do not work > > Server 2: > 8 core AMD x86_64 > openSuSE 13.2 > linux kernel 3.19.3-1-gf10e7fc-desktop > KDE platform 4.14.6 > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) > > remote desktops do not work / remote applications do work, per above description. > > Barrington Daltrey > > > > > > _______________________________________________ > 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 basd1 at fastbk.com Tue May 26 19:00:50 2015 From: basd1 at fastbk.com (basd) Date: Tue, 26 May 2015 11:00:50 -0700 Subject: [winswitch] xpra full desktop In-Reply-To: <5564518B.5090902@nagafix.co.uk> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> Message-ID: <5564B4D2.8040605@fastbk.com> @ Fr?d?ric Henry-Couannier: While (so far) I think TigerVNC is a better option for full desktop session, here is how I recently implemented Xpra desktop session: 1. Run xterm via Start Application Session>Custom Command>xterm (or, if running a standalone xpra server without winswitch, probably just start the child-xterm, per the examples at xpra.com) 2. From xterm, run ""Xephyr :200 &" 3. Run "DISPLAY=:200 icewm &" When I do this, #2 opens a Xephyr window, #3 puts an icewm windows manager on it. (You can pick the desktop provided it is installed on the server: twm, lxsessiom, xfce4-session, etc.) The desktop window that opens is not resizeable, so if you want dimensions other than the default, you will need to follow the example at Xpra.org to specify the dimensions of the Xephyr window. This Xephyr is a child of the xterm application window, so you can't close the xterm without losing the desktop. I created a script (xephyr_launch) in ~/bin on the server as follows: #!/bin/bash Xephyr :200 & DISPLAY=:200 icewm & So, if I start the custom application "xterm" and in xterm run "xephyr_launch", the icewm desktop opens. In this manner, it is possible to save the Xephyr settings and not retype them every startup. Or, have alternatives tht launch different desktops, so one could have "icewm_launch" and "xfce_launch" or the like. Alternatively, one could have a "menu" script in ~/bin from which you can have a single key launch for different options, such as "[i] = icewm [x] = xfce" and provide calls to launch the selected desktop. I have not figured out if I can create a script that I can run "xephyr_launch" that will launch the desktop without the xterm window. I think I can probably do something like "xterm -e Xephyr :200 & DISPLAY=:200 icewm &" in my script and launch the whole thing from "xephyr_launch". I think I did successfully launch xterm However, I'm not certain because in my testing I keep locking up the X server/display :200 or crashing my server altogether. I'll report back if I ever get it right. (I have determined that custom command will not launch "xterm -e xephyr_launch" as this will crash my server.) :-) From basd1 at fastbk.com Tue May 26 22:17:15 2015 From: basd1 at fastbk.com (basd) Date: Tue, 26 May 2015 14:17:15 -0700 Subject: [winswitch] xpra full desktop In-Reply-To: <5564B4D2.8040605@fastbk.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> Message-ID: <5564E2DB.2080202@fastbk.com> Some further discussion, in case it's of interest. Below are my notes regarding (1) attempts to run a custom script via "custom command" in winswitch; (2) running an xpra Xephyr desktop and retrieving it from another client; (3) finding the xpra session via Avahi browser. I created a script (xephyr_launch) in ~/bin on the server and run it as a custom command from winswitch. This works: #!/bin/bash xterm -e firefox This does not work: #!/bin/bash firefox & kwrite This does work: #!/bin/bash firefox &disown kwrite (interestingly, closing kwrite also closes firefox) These crash the server (and also require deletion of ~/.winswitch in order to recover the winswitch server). #!/bin/bash Xephyr :200 &disown #!/bin/bash xterm -e Xephyr :200 &disown Separately, using a "konsole" command line AND NOT running winswitch (winswitch will kill the running xpra session), this works: xpra start --start-child="Xephyr :200" :100 DISPLAY=:200 icewm xpra attach :100 (icewm seemingly does not require the &, I just hit a after icewm started up and got another command prompt.) There is a delay before "DISPLAY=:200 icewm" can be run -- first time icewm said no X was running, then I attached and detached, ran the DISPLAY command again, icewm attached to :200 and then I ran "xpra attach :100" again. For testing purposes, I keep having to restart the computer to clear the server, xpra stop :100 doesn't necessarily leave the system clean so I can run the xpra start command again. So, I'd like to try running this from a script instead of a console, but I will probably crash the xpra :100 and display :200 and have to reboot the server to make further tests. In any event, once I have display :200 running and attached via xpra attach :100 on the server, this will bring it onto my client computer: xpra attach ssh:192.168.1.85:100 The benefit of running it this way is that there is no xterm window paired up with the remote desktop, I just have the remote desktop. The disadvantage is that I'm not able to use the Winswitch app to attach and detach. But, I'm not up-to-speed with what you have running on Android, so I don't know how to attach this session to android. Also, I notice this session does show up in the Avahi Zeroconf Browser, though I don't specifically know how to make use of that (other than to be aware the session is available). Lastly, because I run neorouter VPN, Avahi also tells me I can connect via the VPN, so xpra attach ssh:10.0.0.9:100 works as well (but I have to clear the ssh fingerprint or I get an error warning instead). (BTW, on this test I am getting a pretty fast connection and not having the problem with keystrokes repeating or not executing that I often have when I run xpra individual applications.) From basd1 at fastbk.com Wed May 27 03:46:51 2015 From: basd1 at fastbk.com (basd) Date: Tue, 26 May 2015 19:46:51 -0700 Subject: [winswitch] xpra full desktop In-Reply-To: <5564E2DB.2080202@fastbk.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> <5564E2DB.2080202@fastbk.com> Message-ID: <5565301B.6070802@fastbk.com> So, now I have a one-click launcher that runs this script: #!/bin/bash xpra start --start-child="Xephyr :200 -screen 1300x700" :100 & sleep 20 DISPLAY=:200 icewm & xpra attach :100 exit That starts an icewm desktop session on :100, which I then retrieve on my other computer via xpra attach ssh:192.168.85:100 I can retrieve it back by xpra attach :100. It doesn't appear that I can send it into limbo by exiting the window, that seems to kill the X session. I picked 1300 x 700 since it will fit on most of my physical monitors. I installed arandr and lxrandr, so I can resize the running screen to the available pre-sets. This works, although it's not as convenient as dragging the corner of the window to re-size it. I still haven't figured out a method for clean shut down. As a result, the script is only good for one run after I reboot the server. I know there are the Xephyr -terminate and xpra --exit-with-children option, but not certain how to implement them so that I can pass the running session from computer to computer but shut the session down when I want it ended. (In TigerVNC I can usually run a "logout" but I noticed "logout" in the xpra/Xephyr session will trigger a logout of the running desktop session on the server.) I don't know if "sleep 20" is necessary, maybe it can be shortened to 10 or 15 seconds, but if the DISPLAY command runs too quickly after the xpra start, the windowmanager will not find a running X session and so will fail. The attached screenshot shows the running desktop, with an icewm panel at the bottom and a kde3 kicker panel at the top, with the launcher open. From christian.trenkwalder at nxp.com Wed May 27 06:38:07 2015 From: christian.trenkwalder at nxp.com (Christian Trenkwalder) Date: Wed, 27 May 2015 05:38:07 +0000 Subject: [winswitch] [xpra] Missleading Help Description Message-ID: Hello, if i call >xpra --help It gives a short description of the available options, 2 of them are contradicting it seems > --dbus-proxy Enable forwarding of dbus calls from the client > (default: enabled) > --no-dbus-proxy Disable forwarding of dbus calls from the client > (default: enabled) I don't think its right that both options are enabled by default, or do I misunderstand something? Best regards, Christian Trenkwalder From christian.trenkwalder at nxp.com Wed May 27 06:32:36 2015 From: christian.trenkwalder at nxp.com (Christian Trenkwalder) Date: Wed, 27 May 2015 05:32:36 +0000 Subject: [winswitch] [xpra] Misleading Help Description Message-ID: Hello, if i call >xpra --help It gives a short description of the available options, 2 of them are contradicting it seems > --dbus-proxy Enable forwarding of dbus calls from the client > (default: enabled) > --no-dbus-proxy Disable forwarding of dbus calls from the client > (default: enabled) I don't think its right that both options are enabled by default, or do I misunderstand something? Best regards, Christian Trenkwalder From swine at pobox.com Wed May 27 07:09:54 2015 From: swine at pobox.com (Peter Swain) Date: Wed, 27 May 2015 06:09:54 +0000 Subject: [winswitch] [xpra] Missleading Help Description In-Reply-To: References: Message-ID: They are the same option, in positive/negative form, and 'enable' is in the name. But perhaps it would be clearer, and more concise, if all such --xxx/--no-xxx pairs were collapsed together in the help text. On Tue, May 26, 2015, 10:38 PM Christian Trenkwalder < christian.trenkwalder at nxp.com> wrote: > Hello, > if i call > >xpra --help > It gives a short description of the available options, 2 of them are > contradicting it seems > > > --dbus-proxy Enable forwarding of dbus calls from the client > > (default: enabled) > > --no-dbus-proxy Disable forwarding of dbus calls from the client > > (default: enabled) > > I don't think its right that both options are enabled by default, or do I > misunderstand something? > > Best regards, > Christian Trenkwalder > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From swine at pobox.com Wed May 27 07:14:45 2015 From: swine at pobox.com (Peter Swain) Date: Wed, 27 May 2015 06:14:45 +0000 Subject: [winswitch] [xpra] Missleading Help Description In-Reply-To: References: Message-ID: Ok, 'enable' is not in the name, just the explanation. Was replying in haste from small screen phone. I've found the separation of the --no-xxx entries confusing myself, in xpra & other things On Tue, May 26, 2015, 11:09 PM Peter Swain wrote: > They are the same option, in positive/negative form, and 'enable' is in > the name. But perhaps it would be clearer, and more concise, if all such > --xxx/--no-xxx pairs were collapsed together in the help text. > > On Tue, May 26, 2015, 10:38 PM Christian Trenkwalder < > christian.trenkwalder at nxp.com> wrote: > >> Hello, >> if i call >> >xpra --help >> It gives a short description of the available options, 2 of them are >> contradicting it seems >> >> > --dbus-proxy Enable forwarding of dbus calls from the client >> > (default: enabled) >> > --no-dbus-proxy Disable forwarding of dbus calls from the client >> > (default: enabled) >> >> I don't think its right that both options are enabled by default, or do I >> misunderstand something? >> >> Best regards, >> Christian Trenkwalder >> _______________________________________________ >> 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 May 27 08:36:53 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 May 2015 14:36:53 +0700 Subject: [winswitch] [xpra] Missleading Help Description In-Reply-To: References: Message-ID: <55657415.9030205@nagafix.co.uk> On 27/05/15 13:09, Peter Swain wrote: > They are the same option, in positive/negative form, and 'enable' is in the > name. But perhaps it would be clearer, and more concise, if all such > --xxx/--no-xxx pairs were collapsed together in the help text. AFAIK the python optionparser module does not let you do that. Antoine > > On Tue, May 26, 2015, 10:38 PM Christian Trenkwalder < > christian.trenkwalder at nxp.com> wrote: > >> Hello, >> if i call >>> xpra --help >> It gives a short description of the available options, 2 of them are >> contradicting it seems >> >>> --dbus-proxy Enable forwarding of dbus calls from the client >>> (default: enabled) >>> --no-dbus-proxy Disable forwarding of dbus calls from the client >>> (default: enabled) >> I don't think its right that both options are enabled by default, or do I >> misunderstand something? >> >> Best regards, >> Christian Trenkwalder >> _______________________________________________ >> 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 May 27 08:38:03 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 May 2015 14:38:03 +0700 Subject: [winswitch] [xpra] Missleading Help Description In-Reply-To: References: Message-ID: <5565745B.2040400@nagafix.co.uk> On 27/05/15 13:14, Peter Swain wrote: > Ok, 'enable' is not in the name, just the explanation. Was replying in > haste from small screen phone. I've found the separation of the --no-xxx > entries confusing myself, in xpra & other things In newer versions, the preferred form is --xxx=yes|no|etc.. Though the older --no-xx and --xx is still supported. Antoine > > On Tue, May 26, 2015, 11:09 PM Peter Swain wrote: > >> They are the same option, in positive/negative form, and 'enable' is in >> the name. But perhaps it would be clearer, and more concise, if all such >> --xxx/--no-xxx pairs were collapsed together in the help text. >> >> On Tue, May 26, 2015, 10:38 PM Christian Trenkwalder < >> christian.trenkwalder at nxp.com> wrote: >> >>> Hello, >>> if i call >>>> xpra --help >>> It gives a short description of the available options, 2 of them are >>> contradicting it seems >>> >>>> --dbus-proxy Enable forwarding of dbus calls from the client >>>> (default: enabled) >>>> --no-dbus-proxy Disable forwarding of dbus calls from the client >>>> (default: enabled) >>> I don't think its right that both options are enabled by default, or do I >>> misunderstand something? >>> >>> Best regards, >>> Christian Trenkwalder >>> _______________________________________________ >>> 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 May 27 09:55:19 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 May 2015 15:55:19 +0700 Subject: [winswitch] interesting development In-Reply-To: <521530237.4186744.1432661873358.JavaMail.yahoo@mail.yahoo.com> References: <5564518B.5090902@nagafix.co.uk> <521530237.4186744.1432661873358.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55658677.5020708@nagafix.co.uk> On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: > thanks for answering, > > yes xterm forwarding works. and yes i get a window which content is > black for Xnest. > > i will try Xephyr ... so far i confirm that xpra is indeed somewhat > faster than x2go, but it's still slow for youtube video in HD full > screen ... could it be because my client is not powerfull (odroid C1)? Assuming that you are using the right settings, see: http://xpra.org/trac/wiki/Encodings (usually means using lz4+rgb on a LAN, or h264 otherwise) Encoding is almost always CPU bound on the server side, rarely an issue client side. (having opengl rendering client side helps too) Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. Antoine > > > > > Le Mardi 26 mai 2015 12h57, Antoine Martin a > ?crit : > > > On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: > > hello , > > Now i have tested successfully xpra for application forwarding > between a Linux server station and an odroid (client) . However i cant > make it work for the full desktop forwarding. > > I tried on the server:xpra start --start-child="Xnest :200 -ac > -geometry 800x600+24" :100 > > DISPLAY=:200 fluxbox&and get message > > Xlib: extension "RANDR" missing on display ":200" > Some window managers may require randr, though I don't think fluxbox does. > You might want to try with Xephyr instead of Xnest. > > ?? what does it mean i have no idea > > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST > :100gives me a black screen > By "a black screen", I assume that you mean you get a window whose > contents are black? > The fact that something shows up at all tells me that xpra is forwarding > something, which should be the Xnest window. > Have you tried another window manager instead of fluxbox? > Have you tried also starting and xterm on that display? Does that show up? > > Antoine > > best, > > Fred > > > > > > Le Mardi 7 avril 2015 23h54, basd > a ?crit : > > > > > > In my earlier post I mentioned problems connecting to server socket > for desktops. However, with > > implementation of xpra-0.14.21 I am able to run xpra sessions. > > > > Interestingly, I can spawn multiple child windows from an xpra > remote application that function as > > windows on the client -- but can be moved collectively to another > client. This is a reasonable > > substitute for desktop sessions. > > > > Back when I was using iceWM desktop for remote sessions, I wrote a > bash script that provides a menu > > for launching favorite programs. Using that script, I can launch an > xterm session in xpra, run my > > menu bash script and launch separate programs from it. For > instance, I can run firefox, dolphin > > file manager, libreoffice and even Yast2 (openSuSE's administrative > control panel). So far, this > > appears to give me the same functionality as running these programs > in an iceWM desktop session, > > with the additional advantage that the xpra child windows function > as windows on the client desktop > > itself. Both server and clients are running KDE 4.14 -- this is > interesting, because winswitch.org > > FAQs seem to indicate applications are problematic to run under > KDE/Plasma. > > > > I had to mark ssh_tunnel=False in the server.conf file, since ssh > tunnelling is not working for me. > > > > Other points: > > > > *I have concluded that my installs apparently cannot do ssh > tunnelling. I never tried to implement > > this because I use a VPN, so I have always used direct connections. > Ssh is active on the server and > > I can use sftp, ssh, etc. to the server. > > *Sometimes when exiting xpra windows, a "ghost" xpra session is left > in the winswitch menu list, as > > "unknown". I can't access or kill this session. > > *opSU 13.1 repositories have libwep4 series and current xpra > requires libwep5, which is available in > > opSU 13.2 repositories. > > > > > > For reference: > > > > Server 1: > > 6 core AMD x86_64 > > openSuSE 13.1 > > linux kernel 3.11.10-25-desktop > > KDE platform 4.14.6 > > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 > > xpra-0.14.4 (also in an rpm I built from sources) > > > > remote desktops work / remote applications do not work > > > > Server 2: > > 8 core AMD x86_64 > > openSuSE 13.2 > > linux kernel 3.19.3-1-gf10e7fc-desktop > > KDE platform 4.14.6 > > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 > > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) > > > > remote desktops do not work / remote applications do work, per above > description. > > > > Barrington Daltrey > > > > > > > > > > > > _______________________________________________ > > 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 May 27 10:00:51 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 May 2015 16:00:51 +0700 Subject: [winswitch] xpra full desktop In-Reply-To: <5564B4D2.8040605@fastbk.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> Message-ID: <556587C3.10603@nagafix.co.uk> On 27/05/15 01:00, basd wrote: > @ Fr?d?ric Henry-Couannier: > > While (so far) I think TigerVNC is a better option for full desktop session, here is how I recently > implemented Xpra desktop session: > > 1. Run xterm via Start Application Session>Custom Command>xterm > > (or, if running a standalone xpra server without winswitch, probably just start the child-xterm, per > the examples at xpra.com) > > 2. From xterm, run ""Xephyr :200 &" > 3. Run "DISPLAY=:200 icewm &" Judging by the instructions you give, you seem to be using winswitch. Why not just use the "start desktop" option instead? > When I do this, #2 opens a Xephyr window, #3 puts an icewm windows manager on it. > > (You can pick the desktop provided it is installed on the server: twm, lxsessiom, xfce4-session, etc.) > > The desktop window that opens is not resizeable, so if you want dimensions other than the default, > you will need to follow the example at Xpra.org to specify the dimensions of the Xephyr window. > > This Xephyr is a child of the xterm application window, so you can't close the xterm without losing > the desktop. It doesn't have to be, you can just put Xephyr as a "start-child". > I created a script (xephyr_launch) in ~/bin on the server as follows: > > #!/bin/bash > Xephyr :200 & > DISPLAY=:200 icewm & You could also define your own ".desktop" file and place it in /usr/share/applications, or in the winswitch specific applications folder. > So, if I start the custom application "xterm" and in xterm run "xephyr_launch", the icewm desktop > opens. In this manner, it is possible to save the Xephyr settings and not retype them every > startup. Or, have alternatives tht launch different desktops, so one could have "icewm_launch" and > "xfce_launch" or the like. > > Alternatively, one could have a "menu" script in ~/bin from which you can have a single key launch > for different options, such as "[i] = icewm [x] = xfce" and provide calls to launch the selected > desktop. > > I have not figured out if I can create a script that I can run "xephyr_launch" that will launch the > desktop without the xterm window. I think I can probably do something like "xterm -e Xephyr :200 & > DISPLAY=:200 icewm &" in my script and launch the whole thing from "xephyr_launch". I think I did > successfully launch xterm > > However, I'm not certain because in my testing I keep locking up the X server/display :200 or > crashing my server altogether. I'll report back if I ever get it right. > > (I have determined that custom command will not launch "xterm -e xephyr_launch" as this will crash > my server.) You should never be able to crash a server by launching an xterm or xephyr, sounds like a major bug somewhere. Cheers Antoine > > :-) > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed May 27 10:04:36 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 May 2015 16:04:36 +0700 Subject: [winswitch] xpra full desktop In-Reply-To: <5565301B.6070802@fastbk.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> <5564E2DB.2080202@fastbk.com> <5565301B.6070802@fastbk.com> Message-ID: <556588A4.1080304@nagafix.co.uk> On 27/05/15 09:46, basd wrote: > So, now I have a one-click launcher that runs this script: > > #!/bin/bash > xpra start --start-child="Xephyr :200 -screen 1300x700" :100 & > sleep 20 > DISPLAY=:200 icewm & > xpra attach :100 > exit > > That starts an icewm desktop session on :100, which I then retrieve on my other computer via > > xpra attach ssh:192.168.85:100 > > I can retrieve it back by xpra attach :100. It doesn't appear that I can send it into limbo by > exiting the window, that seems to kill the X session. Try: xpra detach Or just exit the client from the tray. Closing the window closes Xephyr, which kills everything running on that display, including icewm. > I picked 1300 x 700 since it will fit on most of my physical monitors. > > I installed arandr and lxrandr, so I can resize the running screen to the available pre-sets. This > works, although it's not as convenient as dragging the corner of the window to re-size it. > > I still haven't figured out a method for clean shut down. As a result, the script is only good for > one run after I reboot the server. I know there are the Xephyr -terminate and xpra > --exit-with-children option, but not certain how to implement them so that I can pass the running > session from computer to computer but shut the session down when I want it ended. (In TigerVNC I > can usually run a "logout" but I noticed "logout" in the xpra/Xephyr session will trigger a logout > of the running desktop session on the server.) There should not be any difference with any other tool, VNC or other. We don't handle the logout buttons in any special way. This is far removed from the role of xpra and is handled (often badly) by the desktop environments. > I don't know if "sleep 20" is necessary, maybe it can be shortened to 10 or 15 seconds, but if the > DISPLAY command runs too quickly after the xpra start, the windowmanager will not find a running X > session and so will fail. > > The attached screenshot shows the running desktop, with an icewm panel at the bottom and a kde3 > kicker panel at the top, with the launcher open. The mailing list scrubs attachments. Antoine From antoine at nagafix.co.uk Wed May 27 10:09:54 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 May 2015 16:09:54 +0700 Subject: [winswitch] openSuSE 13.2 - more observations In-Reply-To: <556106C1.2090703@fastbk.com> References: <5549F1BB.40609@nagafix.co.uk> <555B5589.3000508@nagafix.co.uk> <5560D128.9090007@fastbk.com> <556106C1.2090703@fastbk.com> Message-ID: <556589E2.1050205@nagafix.co.uk> On 24/05/15 06:01, basd wrote: > 1. I was successful creating an xpra-0.14.24 rpm on a different computer with a different .spec > file. No idea what the difference is. > 2. Before I updated xpra, connecting winswitch-0.12.21 to winswitch-0.12.20 reported that xpra was > not available. You were probably running an outdated version. > 2a. This was not a bad thing, because I discovered that if there is no xpra, then it's possible to > choose vnc for an application connection. Since my openSuSE 13.2 computers will not serve vnc > desktop sessions, this is useful (and it would be nice if the vnc and ssh options were available > even when xpra is available). They are always available. There are configuration options to allow you to choose the default session type and drop down menus in the launch dialogs. > 2b. I noticed that the "application session" would invoke the application in an openbox window (or > icewm, depending on what is available on the server, I guess). That should not be the case. "desktop sessions" should start a window manager, "application sessions" should run seamlessly. > 2c. With the foregoing information, I found that I could open a full vnc desktop session from the > application "custom command" option, as follows: > > The following work: > > ICEWM -- "icewm --replace" > LXDE -- "lxsession" > XFCE -- "xfwm4 --replace & xfce4-session" > KDE4 -- "plasma-desktop & kwin --replace" (but logout doesn't work so you have to use > winswitch_applet to kill the session) > > I could not figure out how to start enlightenment. That is all the window managers/desktops I have > installed. As per my other reply, these options should have launch menus as "desktop sessions" already. That's what winswitch does. > 2d. I know worrying about how to get VNC sessions running is sort of the opposite of getting xpra > to work well, since its focus is on getting individual remote applications to integrate with the > local desktop. But, since the normal winswitch desktop mode does not work for me, this is very > useful information. From basd1 at fastbk.com Wed May 27 17:42:45 2015 From: basd1 at fastbk.com (basd) Date: Wed, 27 May 2015 09:42:45 -0700 Subject: [winswitch] xpra openSuSE 13.1 to windows 8.1 (good news) In-Reply-To: <5565301B.6070802@fastbk.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> <5564E2DB.2080202@fastbk.com> <5565301B.6070802@fastbk.com> Message-ID: <5565F405.2010008@fastbk.com> 1. I finally solved the problem of xpra not running on my openSuSE 13.1 server. There were missing dependencies. These were listed in the big spec file I found somewhere on the xpra or winwitch websites, but this spec file would not build. I had used a different spec file that did not have all of the dependencies. (xpra version 0.14.24) 2. This server is successfully serving xpra applications to windows 8.1 (I have a different server that will provide an xterm, but crashes when I open a kde application from the xterm. I guess, debug one problem at a time -- but fortunately, the one that is "working" is my primary server.) 3. I am attaching a screenshot from my windows 8.1 laptop. You can see several features: (a) there is an xterm window with a simple menu on it. This is the xterm I started with winswitch>application>custom command. The menu is a bash script running in ~/bin on the server. 4. The top of the screen is a KDE 3.5 panel that I launched from xterm. 5. Krita is running on the desktop from the server, launched from the KDE 3.5 panel. I can set up the same "system" via an ssh X session, but this xpra session works way better, is persistent and can be handed off to other computers. Totally awesome, Antoine! From fhenryco at yahoo.fr Wed May 27 18:22:42 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Wed, 27 May 2015 17:22:42 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <55658677.5020708@nagafix.co.uk> References: <55658677.5020708@nagafix.co.uk> Message-ID: <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> Well i'm not sur i understand what you mean by... the right settings... May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... for instance i dont have winswitch ... ?The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: thanks for answering, yes xterm forwarding works. and yes i get a window which content is black for Xnest. i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? Assuming that you are using the right settings, see: http://xpra.org/trac/wiki/Encodings (usually means using lz4+rgb on a LAN, or h264 otherwise) Encoding is almost always CPU bound on the server side, rarely an issue client side. (having opengl rendering client side helps too) Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. Antoine Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: > hello , > Now i have tested successfully xpra? for application forwarding? between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 > DISPLAY=:200 fluxbox&and get message > Xlib:? extension "RANDR" missing on display ":200" Some window managers may require randr, though I don't think fluxbox does. You might want to try with Xephyr instead of Xnest. > ?? what does it mean i have no idea > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen By "a black screen", I assume that you mean you get a window whose contents are black? The fact that something shows up at all tells me that xpra is forwarding something, which should be the Xnest window. Have you tried another window manager instead of fluxbox? Have you tried also starting and xterm on that display? Does that show up? Antoine > best, > Fred > > >? ? ? Le Mardi 7 avril 2015 23h54, basd a ?crit : >? ? > >? In my earlier post I mentioned problems connecting to server socket for desktops.? However, with > implementation of xpra-0.14.21 I am able to run xpra sessions. > > Interestingly, I can spawn multiple child windows from an xpra remote application that function as > windows on the client -- but can be moved collectively to another client.? This is a reasonable > substitute for desktop sessions. > > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu > for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my > menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this > appears to give me the same functionality as running these programs in an iceWM desktop session, > with the additional advantage that the xpra child windows function as windows on the client desktop > itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org > FAQs seem to indicate applications are problematic to run under KDE/Plasma. > > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. > > Other points: > > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement > this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and > I can use sftp, ssh, etc. to the server. > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as > "unknown".? I can't access or kill this session. > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in > opSU 13.2 repositories. > > > For reference: > > Server 1: > 6 core AMD x86_64 > openSuSE 13.1 > linux kernel 3.11.10-25-desktop > KDE platform 4.14.6 > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 > xpra-0.14.4 (also in an rpm I built from sources) > > remote desktops work / remote applications do not work > > Server 2: > 8 core AMD x86_64 > openSuSE 13.2 > linux kernel 3.19.3-1-gf10e7fc-desktop > KDE platform 4.14.6 > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) > > remote desktops do not work / remote applications do work, per above description. > > Barrington Daltrey > > > > > > _______________________________________________ > 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 May 27 18:29:28 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 28 May 2015 00:29:28 +0700 Subject: [winswitch] interesting development In-Reply-To: <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> References: <55658677.5020708@nagafix.co.uk> <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5565FEF8.20008@nagafix.co.uk> On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: > Well i'm not sur i understand what you mean by... the right settings... Please see the wiki link, and ask questions once you've read it. > May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... You're not saying which instructions, so that's impossible for me to say. > for instance i dont have winswitch ... It isn't required if all you want is xpra. > The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... Not going to happen I am afraid. We can't support every distro out there. Though we will gladly accept packaging contributions that enhance support for those distros. Cheers Antoine > > > > > > Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : > > > On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: > > thanks for answering, > yes xterm forwarding works. and yes i get a window which content is black for Xnest. > i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? > Assuming that you are using the right settings, see: > http://xpra.org/trac/wiki/Encodings > (usually means using lz4+rgb on a LAN, or h264 otherwise) > Encoding is almost always CPU bound on the server side, rarely an issue client side. > (having opengl rendering client side helps too) > Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. > > Antoine > > > > > > > Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : > > > On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: > > hello , > > Now i have tested successfully xpra for application forwarding between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. > > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 > > DISPLAY=:200 fluxbox&and get message > > Xlib: extension "RANDR" missing on display ":200" > Some window managers may require randr, though I don't think fluxbox does. > You might want to try with Xephyr instead of Xnest. > > ?? what does it mean i have no idea > > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen > By "a black screen", I assume that you mean you get a window whose > contents are black? > The fact that something shows up at all tells me that xpra is forwarding > something, which should be the Xnest window. > Have you tried another window manager instead of fluxbox? > Have you tried also starting and xterm on that display? Does that show up? > > Antoine > > best, > > Fred > > > > > > Le Mardi 7 avril 2015 23h54, basd a ?crit : > > > > > > In my earlier post I mentioned problems connecting to server socket for desktops. However, with > > implementation of xpra-0.14.21 I am able to run xpra sessions. > > > > Interestingly, I can spawn multiple child windows from an xpra remote application that function as > > windows on the client -- but can be moved collectively to another client. This is a reasonable > > substitute for desktop sessions. > > > > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu > > for launching favorite programs. Using that script, I can launch an xterm session in xpra, run my > > menu bash script and launch separate programs from it. For instance, I can run firefox, dolphin > > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel). So far, this > > appears to give me the same functionality as running these programs in an iceWM desktop session, > > with the additional advantage that the xpra child windows function as windows on the client desktop > > itself. Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org > > FAQs seem to indicate applications are problematic to run under KDE/Plasma. > > > > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. > > > > Other points: > > > > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement > > this because I use a VPN, so I have always used direct connections. Ssh is active on the server and > > I can use sftp, ssh, etc. to the server. > > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as > > "unknown". I can't access or kill this session. > > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in > > opSU 13.2 repositories. > > > > > > For reference: > > > > Server 1: > > 6 core AMD x86_64 > > openSuSE 13.1 > > linux kernel 3.11.10-25-desktop > > KDE platform 4.14.6 > > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 > > xpra-0.14.4 (also in an rpm I built from sources) > > > > remote desktops work / remote applications do not work > > > > Server 2: > > 8 core AMD x86_64 > > openSuSE 13.2 > > linux kernel 3.19.3-1-gf10e7fc-desktop > > KDE platform 4.14.6 > > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 > > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) > > > > remote desktops do not work / remote applications do work, per above description. > > > > Barrington Daltrey > > > > > > > > > > > > _______________________________________________ > > 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 > > > > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From basd1 at fastbk.com Wed May 27 18:56:05 2015 From: basd1 at fastbk.com (basd) Date: Wed, 27 May 2015 10:56:05 -0700 Subject: [winswitch] interesting development In-Reply-To: <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> References: <55658677.5020708@nagafix.co.uk> <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55660535.9080708@fastbk.com> Not speaking for developers, just for myself -- to build the RPM for your system requires that someone is running a full "development" version of your system unless it is compatible with the rpms from another system. Both winswitch and xpra can be installed from sources I believe via python installer -- the drawback being that "uninstall" is not necessarily clean, per winswitch website. I use openSuSE -- I tried the various RPMs, such as for Fedora and CentOS -- but they did not work for me. So I have built my own RPMs from sources. You are welcome to try my openSuSE RPMs and if you have a working install of your own system that can run rpmbuild or the like I will be happy to assist your efforts to build your own RPM. Also, as I noted in a recent post, I did not have all of the necessary dependencies iinstalled, you may have a similar problem. If you look through the .spec file, you will see a lot of dependencies that need to be installed and you can install them one by one via your own installer (provided the necessary packages are available). If you can't find the spec file I will be happy to send my copy -- I can't remember actually where I got it from, but it was somewhere on winswitch or xpra sites. Barrington On 05/27/2015 10:22 AM, Fr?d?ric Henry-Couannier wrote: > Well i'm not sur i understand what you mean by... the right settings... > May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... > for instance i dont have winswitch ... > > > The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... > From basd1 at fastbk.com Wed May 27 19:58:03 2015 From: basd1 at fastbk.com (basd) Date: Wed, 27 May 2015 11:58:03 -0700 Subject: [winswitch] winswitch / xpra dependencies In-Reply-To: <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> References: <55658677.5020708@nagafix.co.uk> <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> Message-ID: <556613BB.4050106@fastbk.com> It may help to make certain you have all of these installed (or as much of them as you can locate). Some have different names in different systems, I had to locate the correct packages for some openSuSE versions. I'm only listing the runtime dependencies, not the build dependencies (or maybe some of these are build dependencies, but anyway, I did not include the ones marked "build requires". XPRA DEPENDENCIES python python-lz4 pygtk2 dbus-python (openSuSE dbus-1-python) python-crypto python-netifaces python-rencode (it may be that this is actually built in the xpra install?) python-pillow libefakeXinerama gtk2-immodule-xim xorg-x11-server-utils xorg-x11-drv-dummy xorg-x11-drv-void xorg-x11-auth x264 x265 python-gobject OpenGL pyOopenGL pyOpenGL-accelerate pygtkglext numpy python-websockify python-lzo libwebp libvpx python-gtk python-pycrypto python-Twisted python-Cython (possibly only for building rpm) xrandr libXtst6 libXcomposite1 avahi python-avahi python-pyasn1 python-utmp python-notify perl-Growl-GNTP (? don't know why I put a perl package in here, probably not.) Growl (not sure what the package is) python-nautilus libxkbfile1 (and I think xkbfile?) python-PyVirtualDisplay xorg-x11-server-extra for printing: python-cups cups-pdf for sound: gstreamer gstreamer-plugins-base gstreamer-plugins-good gstreamer-python pulseaudio pusleaudio-utils optional python3: python3 python3-lz4 python3-gobject python3-crypto python3-neticfaces python3-rencode python3-pillow python3-PyOpenGL python3-OpenGL-acclerate gstreamer1 gstreamer1-plugins-base gstreamer1-plugins-good WINSWITCH xorg_utils xorg-x11-server-utils python_base pygtk2 python-crypto python-twisted python-imaging python-xlib python_extras nautilus-python dbus-python nx, rdesktop openssh-clients tigervnc tigervnc-server mdns avahi gstreamer python-pyasn1 xorg_extras dbus-x11 xloadimage devilspie ImageMagick gnome-menus gnome-python2 xfreerdp python-utmp python-svg nautilus-python python-utmp gnome-python2-rsvg avahi avahi-ui-tools python-asn1 xorg-x11-server-extra python_base python-gtk python-crypto python-twisted python-imaging python-xlib python-nautilus dbus-1-python python-utmp dbus-x11 rdesktop openssh avah python-avahi dbus-1-x11 xloadimage devilspie gnome-menus python-gnome openssh-clients dbus-python /usr/lib/nautilus From fhenryco at yahoo.fr Wed May 27 19:58:21 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Wed, 27 May 2015 18:58:21 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <5565FEF8.20008@nagafix.co.uk> References: <5565FEF8.20008@nagafix.co.uk> Message-ID: <1131518488.922961.1432753102040.JavaMail.yahoo@mail.yahoo.com> Yes i had readen but for instance when i tried? xpra control :100 compression lz4 i got server returned error code 5invalid argument for 'compression': must be one of: zlib I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from?lz4 0.7.0 : Python Package Index?and install with? $ pip install lz4$ easy_install lz4 | ? | | ? | | ? | ? | ? | ? | ? | | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python | | | | Afficher sur pypi.... | Aper?u par Yahoo | | | | ? | ?but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC ?:-) Le Mercredi 27 mai 2015 19h29, Antoine Martin a ?crit : On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: > Well i'm not sur i understand what you mean by... the right settings... Please see the wiki link, and ask questions once you've read it. > May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... You're not saying which instructions, so that's impossible for me to say. > for instance i dont have winswitch ... It isn't required if all you want is xpra. >? The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... Not going to happen I am afraid. We can't support every distro out there. Though we will gladly accept packaging contributions that enhance support for those distros. Cheers Antoine > >? > > > >? ? ? Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : >? ? > >? ? On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: >? ? >? ? ? thanks for answering, >? ? yes xterm forwarding works. and yes i get a window which content is black for Xnest. >? ? i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? >? Assuming that you are using the right settings, see: >? http://xpra.org/trac/wiki/Encodings >? (usually means using lz4+rgb on a LAN, or h264 otherwise) >? Encoding is almost always CPU bound on the server side, rarely an issue client side. >? (having opengl rendering client side helps too) >? Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. >? >? Antoine >? >? >? ? ? >? ? >? >? >? ? ? ? ? ? Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : >? ? >? >? On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: >? > hello , >? > Now i have tested successfully xpra? for application forwarding? between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. >? > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 >? > DISPLAY=:200 fluxbox&and get message >? > Xlib:? extension "RANDR" missing on display ":200" >? Some window managers may require randr, though I don't think fluxbox does. >? You might want to try with Xephyr instead of Xnest. >? > ?? what does it mean i have no idea >? > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen >? By "a black screen", I assume that you mean you get a window whose >? contents are black? >? The fact that something shows up at all tells me that xpra is forwarding >? something, which should be the Xnest window. >? Have you tried another window manager instead of fluxbox? >? Have you tried also starting and xterm on that display? Does that show up? >? >? Antoine >? > best, >? > Fred >? > >? > >? >? ? ? Le Mardi 7 avril 2015 23h54, basd a ?crit : >? > >? > >? >? In my earlier post I mentioned problems connecting to server socket for desktops.? However, with >? > implementation of xpra-0.14.21 I am able to run xpra sessions. >? > >? > Interestingly, I can spawn multiple child windows from an xpra remote application that function as >? > windows on the client -- but can be moved collectively to another client.? This is a reasonable >? > substitute for desktop sessions. >? > >? > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu >? > for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my >? > menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin >? > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this >? > appears to give me the same functionality as running these programs in an iceWM desktop session, >? > with the additional advantage that the xpra child windows function as windows on the client desktop >? > itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org >? > FAQs seem to indicate applications are problematic to run under KDE/Plasma. >? > >? > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. >? > >? > Other points: >? > >? > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement >? > this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and >? > I can use sftp, ssh, etc. to the server. >? > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as >? > "unknown".? I can't access or kill this session. >? > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in >? > opSU 13.2 repositories. >? > >? > >? > For reference: >? > >? > Server 1: >? > 6 core AMD x86_64 >? > openSuSE 13.1 >? > linux kernel 3.11.10-25-desktop >? > KDE platform 4.14.6 >? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 >? > xpra-0.14.4 (also in an rpm I built from sources) >? > >? > remote desktops work / remote applications do not work >? > >? > Server 2: >? > 8 core AMD x86_64 >? > openSuSE 13.2 >? > linux kernel 3.19.3-1-gf10e7fc-desktop >? > KDE platform 4.14.6 >? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 >? > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) >? > >? > remote desktops do not work / remote applications do work, per above description. >? > >? > Barrington Daltrey >? > >? > >? > >? > >? > >? > _______________________________________________ >? > 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 >? ? >? >? ? ? ? >? >? > >? ? > _______________________________________________ > 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 May 28 04:23:38 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 28 May 2015 10:23:38 +0700 Subject: [winswitch] winswitch / xpra dependencies In-Reply-To: <556613BB.4050106@fastbk.com> References: <55658677.5020708@nagafix.co.uk> <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> <556613BB.4050106@fastbk.com> Message-ID: <55668A3A.1070406@nagafix.co.uk> On 28/05/15 01:58, basd wrote: > It may help to make certain you have all of these installed (or as much of them as you can locate). > Some have different names in different systems, I had to locate the correct packages for some > openSuSE versions. I'm only listing the runtime dependencies, not the build dependencies (or maybe > some of these are build dependencies, but anyway, I did not include the ones marked "build requires". > > XPRA DEPENDENCIES > > python > python-lz4 > pygtk2 > dbus-python (openSuSE dbus-1-python) > python-crypto > python-netifaces > python-rencode (it may be that this is actually built in the xpra install?) > python-pillow > libefakeXinerama Typo: libfakeXinerama > gtk2-immodule-xim Not strictly required. > xorg-x11-server-utils > xorg-x11-drv-dummy > xorg-x11-drv-void > xorg-x11-auth > x264 > x265 Not required or even desirable. > python-gobject > OpenGL No such package. > pyOopenGL Typo: pyOpenGL > pyOpenGL-accelerate > pygtkglext > numpy > python-websockify > python-lzo Note: you're missing python-lz4, but python-lzo is still better than plain zlib. > libwebp > libvpx > python-gtk > python-pycrypto > python-Twisted Not required for xpra, only for winswitch. > python-Cython (possibly only for building rpm) Only for building. > xrandr > libXtst6 > libXcomposite1 > avahi Not strictly required. Only for mdns. > python-avahi > python-pyasn1 Only for winswitch. > python-utmp Only for winswitch. > python-notify Only for winswitch. > perl-Growl-GNTP (? don't know why I put a perl package in here, probably not.) Not needed. > Growl (not sure what the package is) Not needed. > python-nautilus > libxkbfile1 > (and I think xkbfile?) > python-PyVirtualDisplay I don't know what this is, doubt it is needed. > xorg-x11-server-extra > > > for printing: > > python-cups > cups-pdf > > for sound: > gstreamer > gstreamer-plugins-base > gstreamer-plugins-good > gstreamer-python > pulseaudio > pusleaudio-utils > > > > optional python3: > > python3 > python3-lz4 > > > > python3-gobject > python3-crypto > python3-neticfaces > python3-rencode > python3-pillow > python3-PyOpenGL > python3-OpenGL-acclerate > gstreamer1 > gstreamer1-plugins-base > gstreamer1-plugins-good > > WINSWITCH Note: the vast majority of those dependencies are optional. Winswitch can figure out what is installed and use whatever is there. > xorg_utils > xorg-x11-server-utils > python_base pygtk2 > python-crypto > python-twisted > python-imaging > python-xlib > python_extras > nautilus-python > dbus-python > nx, > rdesktop > openssh-clients > tigervnc > tigervnc-server > mdns > avahi > gstreamer > python-pyasn1 > xorg_extras > dbus-x11 > xloadimage > devilspie > ImageMagick > gnome-menus > gnome-python2 > xfreerdp > python-utmp > python-svg > nautilus-python > python-utmp > gnome-python2-rsvg > avahi > avahi-ui-tools > python-asn1 > xorg-x11-server-extra > python_base > python-gtk > python-crypto > python-twisted > python-imaging > python-xlib > python-nautilus > dbus-1-python > python-utmp > dbus-x11 > rdesktop > openssh > avah > python-avahi > dbus-1-x11 > xloadimage > devilspie > gnome-menus > python-gnome > openssh-clients > dbus-python > /usr/lib/nautilus > > > _______________________________________________ > 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 May 28 04:28:42 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 28 May 2015 10:28:42 +0700 Subject: [winswitch] interesting development In-Reply-To: <1131518488.922961.1432753102040.JavaMail.yahoo@mail.yahoo.com> References: <5565FEF8.20008@nagafix.co.uk> <1131518488.922961.1432753102040.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55668B6A.1050500@nagafix.co.uk> On 28/05/15 01:58, Fr?d?ric Henry-Couannier wrote: > Yes i had readen but for instance when i tried > xpra control :100 compression lz4 > i got > server returned error code 5invalid argument for 'compression': must be one of: zlib > I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from lz4 0.7.0 : Python Package Index and install with $ pip install lz4$ easy_install lz4 > | | > | | | | | | | | > | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python | > | | > | Afficher sur pypi.... | Aper?u par Yahoo | > | | > | | > > but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC :-) Installing things is always best done through your distribution's package manager - whatever that is. Though in this particular case, it should be pretty safe to just pip or easy_install lz4. (the only downside is that unlike regular packages, you will not get updates automatically) Antoine > > > Le Mercredi 27 mai 2015 19h29, Antoine Martin a ?crit : > > > On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: >> Well i'm not sur i understand what you mean by... the right settings... > Please see the wiki link, and ask questions once you've read it. >> May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... > You're not saying which instructions, so that's impossible for me to say. >> for instance i dont have winswitch ... > It isn't required if all you want is xpra. >> The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... > Not going to happen I am afraid. We can't support every distro out there. > Though we will gladly accept packaging contributions that enhance > support for those distros. > > Cheers > Antoine > >> >> >> >> >> Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : >> >> >> On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: >> >> thanks for answering, >> yes xterm forwarding works. and yes i get a window which content is black for Xnest. >> i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? >> Assuming that you are using the right settings, see: >> http://xpra.org/trac/wiki/Encodings >> (usually means using lz4+rgb on a LAN, or h264 otherwise) >> Encoding is almost always CPU bound on the server side, rarely an issue client side. >> (having opengl rendering client side helps too) >> Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. >> >> Antoine >> >> >> >> >> >> >> Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : >> >> >> On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: >> > hello , >> > Now i have tested successfully xpra for application forwarding between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. >> > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 >> > DISPLAY=:200 fluxbox&and get message >> > Xlib: extension "RANDR" missing on display ":200" >> Some window managers may require randr, though I don't think fluxbox does. >> You might want to try with Xephyr instead of Xnest. >> > ?? what does it mean i have no idea >> > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen >> By "a black screen", I assume that you mean you get a window whose >> contents are black? >> The fact that something shows up at all tells me that xpra is forwarding >> something, which should be the Xnest window. >> Have you tried another window manager instead of fluxbox? >> Have you tried also starting and xterm on that display? Does that show up? >> >> Antoine >> > best, >> > Fred >> > >> > >> > Le Mardi 7 avril 2015 23h54, basd a ?crit : >> > >> > >> > In my earlier post I mentioned problems connecting to server socket for desktops. However, with >> > implementation of xpra-0.14.21 I am able to run xpra sessions. >> > >> > Interestingly, I can spawn multiple child windows from an xpra remote application that function as >> > windows on the client -- but can be moved collectively to another client. This is a reasonable >> > substitute for desktop sessions. >> > >> > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu >> > for launching favorite programs. Using that script, I can launch an xterm session in xpra, run my >> > menu bash script and launch separate programs from it. For instance, I can run firefox, dolphin >> > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel). So far, this >> > appears to give me the same functionality as running these programs in an iceWM desktop session, >> > with the additional advantage that the xpra child windows function as windows on the client desktop >> > itself. Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org >> > FAQs seem to indicate applications are problematic to run under KDE/Plasma. >> > >> > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. >> > >> > Other points: >> > >> > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement >> > this because I use a VPN, so I have always used direct connections. Ssh is active on the server and >> > I can use sftp, ssh, etc. to the server. >> > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as >> > "unknown". I can't access or kill this session. >> > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in >> > opSU 13.2 repositories. >> > >> > >> > For reference: >> > >> > Server 1: >> > 6 core AMD x86_64 >> > openSuSE 13.1 >> > linux kernel 3.11.10-25-desktop >> > KDE platform 4.14.6 >> > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 >> > xpra-0.14.4 (also in an rpm I built from sources) >> > >> > remote desktops work / remote applications do not work >> > >> > Server 2: >> > 8 core AMD x86_64 >> > openSuSE 13.2 >> > linux kernel 3.19.3-1-gf10e7fc-desktop >> > KDE platform 4.14.6 >> > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 >> > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) >> > >> > remote desktops do not work / remote applications do work, per above description. >> > >> > Barrington Daltrey >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> >> >> >> >> >> >> _______________________________________________ >> 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 fhenryco at yahoo.fr Thu May 28 07:32:21 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Thu, 28 May 2015 06:32:21 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <55668B6A.1050500@nagafix.co.uk> References: <55668B6A.1050500@nagafix.co.uk> Message-ID: <606561644.87455.1432794741829.JavaMail.yahoo@mail.yahoo.com> thanks for advices and helpful support I installed pip , lz4 and could choose rgb and lz4 for my window , result fluid in 420p youtube but becomes slow in 720p and beyond...i'm wondering what kind of other parameters could improve ?... however openGL is not supported by my small client board (odroid , a little bit more powerful than last raspberry pi) ... Is it foreseen to implement OpenGL-ES in xpra ? this might allow better performances on such small board , very low prices clients... Le Jeudi 28 mai 2015 5h28, Antoine Martin a ?crit : On 28/05/15 01:58, Fr?d?ric Henry-Couannier wrote: > Yes i had readen but for instance when i tried > xpra control :100 compression lz4 > i got > server returned error code 5invalid argument for 'compression': must be one of: zlib >? I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from lz4 0.7.0 : Python Package Index and install with? $ pip install lz4$ easy_install lz4 > |? | > |? |? |? |? |? |? |? | > | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python | > |? | > | Afficher sur pypi.... | Aper?u par Yahoo | > |? | > |? | > >? but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC? :-) Installing things is always best done through your distribution's package manager - whatever that is. Though in this particular case, it should be pretty safe to just pip or easy_install lz4. (the only downside is that unlike regular packages, you will not get updates automatically) Antoine > > >? ? ? Le Mercredi 27 mai 2015 19h29, Antoine Martin a ?crit : >? ? > >? On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: >> Well i'm not sur i understand what you mean by... the right settings... > Please see the wiki link, and ask questions once you've read it. >> May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... > You're not saying which instructions, so that's impossible for me to say. >> for instance i dont have winswitch ... > It isn't required if all you want is xpra. >>? ? The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... > Not going to happen I am afraid. We can't support every distro out there. > Though we will gladly accept packaging contributions that enhance > support for those distros. > > Cheers > Antoine > >>? ? >> >> >> >>? ? ? ? Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : >>? ? ? >> >>? ? ? On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: >>? ? ? >>? ? ? ? thanks for answering, >>? ? ? yes xterm forwarding works. and yes i get a window which content is black for Xnest. >>? ? ? i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? >>? ? Assuming that you are using the right settings, see: >>? ? http://xpra.org/trac/wiki/Encodings >>? ? (usually means using lz4+rgb on a LAN, or h264 otherwise) >>? ? Encoding is almost always CPU bound on the server side, rarely an issue client side. >>? ? (having opengl rendering client side helps too) >>? ? Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. >>? ? >>? ? Antoine >>? ? >>? ? >>? ? ? ? >>? ? ? >>? ? >>? ? >>? ? ? ? ? ? ? Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : >>? ? ? >>? ? >>? ? On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: >>? ? > hello , >>? ? > Now i have tested successfully xpra? for application forwarding? between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. >>? ? > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 >>? ? > DISPLAY=:200 fluxbox&and get message >>? ? > Xlib:? extension "RANDR" missing on display ":200" >>? ? Some window managers may require randr, though I don't think fluxbox does. >>? ? You might want to try with Xephyr instead of Xnest. >>? ? > ?? what does it mean i have no idea >>? ? > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen >>? ? By "a black screen", I assume that you mean you get a window whose >>? ? contents are black? >>? ? The fact that something shows up at all tells me that xpra is forwarding >>? ? something, which should be the Xnest window. >>? ? Have you tried another window manager instead of fluxbox? >>? ? Have you tried also starting and xterm on that display? Does that show up? >>? ? >>? ? Antoine >>? ? > best, >>? ? > Fred >>? ? > >>? ? > >>? ? >? ? ? Le Mardi 7 avril 2015 23h54, basd a ?crit : >>? ? > >>? ? > >>? ? >? In my earlier post I mentioned problems connecting to server socket for desktops.? However, with >>? ? > implementation of xpra-0.14.21 I am able to run xpra sessions. >>? ? > >>? ? > Interestingly, I can spawn multiple child windows from an xpra remote application that function as >>? ? > windows on the client -- but can be moved collectively to another client.? This is a reasonable >>? ? > substitute for desktop sessions. >>? ? > >>? ? > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu >>? ? > for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my >>? ? > menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin >>? ? > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this >>? ? > appears to give me the same functionality as running these programs in an iceWM desktop session, >>? ? > with the additional advantage that the xpra child windows function as windows on the client desktop >>? ? > itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org >>? ? > FAQs seem to indicate applications are problematic to run under KDE/Plasma. >>? ? > >>? ? > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. >>? ? > >>? ? > Other points: >>? ? > >>? ? > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement >>? ? > this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and >>? ? > I can use sftp, ssh, etc. to the server. >>? ? > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as >>? ? > "unknown".? I can't access or kill this session. >>? ? > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in >>? ? > opSU 13.2 repositories. >>? ? > >>? ? > >>? ? > For reference: >>? ? > >>? ? > Server 1: >>? ? > 6 core AMD x86_64 >>? ? > openSuSE 13.1 >>? ? > linux kernel 3.11.10-25-desktop >>? ? > KDE platform 4.14.6 >>? ? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 >>? ? > xpra-0.14.4 (also in an rpm I built from sources) >>? ? > >>? ? > remote desktops work / remote applications do not work >>? ? > >>? ? > Server 2: >>? ? > 8 core AMD x86_64 >>? ? > openSuSE 13.2 >>? ? > linux kernel 3.19.3-1-gf10e7fc-desktop >>? ? > KDE platform 4.14.6 >>? ? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 >>? ? > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) >>? ? > >>? ? > remote desktops do not work / remote applications do work, per above description. >>? ? > >>? ? > Barrington Daltrey >>? ? > >>? ? > >>? ? > >>? ? > >>? ? > >>? ? > _______________________________________________ >>? ? > 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 >>? ? ? >>? ? >>? ? ? ? ? >>? ? >>? ? >> >>? ? ? >> _______________________________________________ >> 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 _______________________________________________ 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 May 28 10:45:44 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 28 May 2015 16:45:44 +0700 Subject: [winswitch] interesting development In-Reply-To: <606561644.87455.1432794741829.JavaMail.yahoo@mail.yahoo.com> References: <55668B6A.1050500@nagafix.co.uk> <606561644.87455.1432794741829.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5566E3C8.6080304@nagafix.co.uk> On 28/05/15 13:32, Fr?d?ric Henry-Couannier wrote: > thanks for advices and helpful support > I installed pip , lz4 and could choose rgb and lz4 for my window , result fluid in 420p youtube but becomes slow in 720p and beyond...i'm wondering what kind of other parameters could improve Try "--compress=0" Then I guess you need to figure out where the bottleneck is: * are you CPU bound on the server? On the client? * is your network maxed out? etc.. > ... however openGL is not supported by my small client board (odroid , a little bit more powerful than last raspberry pi) ... Is it foreseen to implement OpenGL-ES in xpra ? This is not planned, yet. > this might allow better performances on such small board , very low prices clients... > > > Le Jeudi 28 mai 2015 5h28, Antoine Martin a ?crit : > > > On 28/05/15 01:58, Fr?d?ric Henry-Couannier wrote: >> Yes i had readen but for instance when i tried >> xpra control :100 compression lz4 >> i got >> server returned error code 5invalid argument for 'compression': must be one of: zlib >> I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from lz4 0.7.0 : Python Package Index and install with $ pip install lz4$ easy_install lz4 >> | | >> | | | | | | | | >> | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python | >> | | >> | Afficher sur pypi.... | Aper?u par Yahoo | >> | | >> | | >> >> but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC :-) > Installing things is always best done through your distribution's > package manager - whatever that is. > Though in this particular case, it should be pretty safe to just pip or > easy_install lz4. > (the only downside is that unlike regular packages, you will not get > updates automatically) > > Antoine > > >> >> Le Mercredi 27 mai 2015 19h29, Antoine Martin a ?crit : >> >> >> On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: >>> Well i'm not sur i understand what you mean by... the right settings... >> Please see the wiki link, and ask questions once you've read it. >>> May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... >> You're not saying which instructions, so that's impossible for me to say. >>> for instance i dont have winswitch ... >> It isn't required if all you want is xpra. >>> The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... >> Not going to happen I am afraid. We can't support every distro out there. >> Though we will gladly accept packaging contributions that enhance >> support for those distros. >> >> Cheers >> Antoine >> >>> >>> >>> >>> >>> Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : >>> >>> >>> On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: >>> >>> thanks for answering, >>> yes xterm forwarding works. and yes i get a window which content is black for Xnest. >>> i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? >>> Assuming that you are using the right settings, see: >>> http://xpra.org/trac/wiki/Encodings >>> (usually means using lz4+rgb on a LAN, or h264 otherwise) >>> Encoding is almost always CPU bound on the server side, rarely an issue client side. >>> (having opengl rendering client side helps too) >>> Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. >>> >>> Antoine >>> >>> >>> >>> >>> >>> >>> Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : >>> >>> >>> On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: >>> > hello , >>> > Now i have tested successfully xpra for application forwarding between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. >>> > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 >>> > DISPLAY=:200 fluxbox&and get message >>> > Xlib: extension "RANDR" missing on display ":200" >>> Some window managers may require randr, though I don't think fluxbox does. >>> You might want to try with Xephyr instead of Xnest. >>> > ?? what does it mean i have no idea >>> > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen >>> By "a black screen", I assume that you mean you get a window whose >>> contents are black? >>> The fact that something shows up at all tells me that xpra is forwarding >>> something, which should be the Xnest window. >>> Have you tried another window manager instead of fluxbox? >>> Have you tried also starting and xterm on that display? Does that show up? >>> >>> Antoine >>> > best, >>> > Fred >>> > >>> > >>> > Le Mardi 7 avril 2015 23h54, basd a ?crit : >>> > >>> > >>> > In my earlier post I mentioned problems connecting to server socket for desktops. However, with >>> > implementation of xpra-0.14.21 I am able to run xpra sessions. >>> > >>> > Interestingly, I can spawn multiple child windows from an xpra remote application that function as >>> > windows on the client -- but can be moved collectively to another client. This is a reasonable >>> > substitute for desktop sessions. >>> > >>> > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu >>> > for launching favorite programs. Using that script, I can launch an xterm session in xpra, run my >>> > menu bash script and launch separate programs from it. For instance, I can run firefox, dolphin >>> > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel). So far, this >>> > appears to give me the same functionality as running these programs in an iceWM desktop session, >>> > with the additional advantage that the xpra child windows function as windows on the client desktop >>> > itself. Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org >>> > FAQs seem to indicate applications are problematic to run under KDE/Plasma. >>> > >>> > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. >>> > >>> > Other points: >>> > >>> > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement >>> > this because I use a VPN, so I have always used direct connections. Ssh is active on the server and >>> > I can use sftp, ssh, etc. to the server. >>> > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as >>> > "unknown". I can't access or kill this session. >>> > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in >>> > opSU 13.2 repositories. >>> > >>> > >>> > For reference: >>> > >>> > Server 1: >>> > 6 core AMD x86_64 >>> > openSuSE 13.1 >>> > linux kernel 3.11.10-25-desktop >>> > KDE platform 4.14.6 >>> > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 >>> > xpra-0.14.4 (also in an rpm I built from sources) >>> > >>> > remote desktops work / remote applications do not work >>> > >>> > Server 2: >>> > 8 core AMD x86_64 >>> > openSuSE 13.2 >>> > linux kernel 3.19.3-1-gf10e7fc-desktop >>> > KDE platform 4.14.6 >>> > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 >>> > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) >>> > >>> > remote desktops do not work / remote applications do work, per above description. >>> > >>> > Barrington Daltrey >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 fhenryco at yahoo.fr Thu May 28 11:04:36 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Thu, 28 May 2015 10:04:36 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <5566E3C8.6080304@nagafix.co.uk> References: <5566E3C8.6080304@nagafix.co.uk> Message-ID: <1713162320.370632.1432807476128.JavaMail.yahoo@mail.yahoo.com> the server is very powerful and the link is just an ethernet cable .... so in principle the bottleneck can only be the client (?Amlogic ARM? Cortex?-A5(ARMv7) 1.5Ghz quad core CPUs?.. But even with no compression it's slow (?!), so i'm going to investigate with another machine as client ... F H-C ? Le Jeudi 28 mai 2015 11h45, Antoine Martin a ?crit : On 28/05/15 13:32, Fr?d?ric Henry-Couannier wrote: > thanks for advices and helpful support > I installed pip , lz4 and could choose rgb and lz4 for my window , result fluid in 420p youtube but becomes slow in 720p and beyond...i'm wondering what kind of other parameters could improve Try "--compress=0" Then I guess you need to figure out where the bottleneck is: * are you CPU bound on the server? On the client? * is your network maxed out? etc.. >? ... however openGL is not supported by my small client board (odroid , a little bit more powerful than last raspberry pi) ... Is it foreseen to implement OpenGL-ES in xpra ? This is not planned, yet. > this might allow better performances on such small board , very low prices clients... > > >? ? ? Le Jeudi 28 mai 2015 5h28, Antoine Martin a ?crit : >? ? > >? On 28/05/15 01:58, Fr?d?ric Henry-Couannier wrote: >> Yes i had readen but for instance when i tried >> xpra control :100 compression lz4 >> i got >> server returned error code 5invalid argument for 'compression': must be one of: zlib >>? ? I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from lz4 0.7.0 : Python Package Index and install with? $ pip install lz4$ easy_install lz4 >> |? | >> |? |? |? |? |? |? |? | >> | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python | >> |? | >> | Afficher sur pypi.... | Aper?u par Yahoo | >> |? | >> |? | >> >>? ? but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC? :-) > Installing things is always best done through your distribution's > package manager - whatever that is. > Though in this particular case, it should be pretty safe to just pip or > easy_install lz4. > (the only downside is that unlike regular packages, you will not get > updates automatically) > > Antoine > > >> >>? ? ? ? Le Mercredi 27 mai 2015 19h29, Antoine Martin a ?crit : >>? ? ? >> >>? ? On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: >>> Well i'm not sur i understand what you mean by... the right settings... >> Please see the wiki link, and ask questions once you've read it. >>> May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... >> You're not saying which instructions, so that's impossible for me to say. >>> for instance i dont have winswitch ... >> It isn't required if all you want is xpra. >>>? ? ? The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... >> Not going to happen I am afraid. We can't support every distro out there. >> Though we will gladly accept packaging contributions that enhance >> support for those distros. >> >> Cheers >> Antoine >> >>>? ? ? >>> >>> >>> >>>? ? ? ? ? Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : >>>? ? ? ? >>> >>>? ? ? ? On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: >>>? ? ? ? >>>? ? ? ? ? thanks for answering, >>>? ? ? ? yes xterm forwarding works. and yes i get a window which content is black for Xnest. >>>? ? ? ? i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? >>>? ? ? Assuming that you are using the right settings, see: >>>? ? ? http://xpra.org/trac/wiki/Encodings >>>? ? ? (usually means using lz4+rgb on a LAN, or h264 otherwise) >>>? ? ? Encoding is almost always CPU bound on the server side, rarely an issue client side. >>>? ? ? (having opengl rendering client side helps too) >>>? ? ? Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. >>>? ? ? >>>? ? ? Antoine >>>? ? ? >>>? ? ? >>>? ? ? ? ? >>>? ? ? ? >>>? ? ? >>>? ? ? >>>? ? ? ? ? ? ? ? Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : >>>? ? ? ? >>>? ? ? >>>? ? ? On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: >>>? ? ? > hello , >>>? ? ? > Now i have tested successfully xpra? for application forwarding? between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. >>>? ? ? > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 >>>? ? ? > DISPLAY=:200 fluxbox&and get message >>>? ? ? > Xlib:? extension "RANDR" missing on display ":200" >>>? ? ? Some window managers may require randr, though I don't think fluxbox does. >>>? ? ? You might want to try with Xephyr instead of Xnest. >>>? ? ? > ?? what does it mean i have no idea >>>? ? ? > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen >>>? ? ? By "a black screen", I assume that you mean you get a window whose >>>? ? ? contents are black? >>>? ? ? The fact that something shows up at all tells me that xpra is forwarding >>>? ? ? something, which should be the Xnest window. >>>? ? ? Have you tried another window manager instead of fluxbox? >>>? ? ? Have you tried also starting and xterm on that display? Does that show up? >>>? ? ? >>>? ? ? Antoine >>>? ? ? > best, >>>? ? ? > Fred >>>? ? ? > >>>? ? ? > >>>? ? ? >? ? ? Le Mardi 7 avril 2015 23h54, basd a ?crit : >>>? ? ? > >>>? ? ? > >>>? ? ? >? In my earlier post I mentioned problems connecting to server socket for desktops.? However, with >>>? ? ? > implementation of xpra-0.14.21 I am able to run xpra sessions. >>>? ? ? > >>>? ? ? > Interestingly, I can spawn multiple child windows from an xpra remote application that function as >>>? ? ? > windows on the client -- but can be moved collectively to another client.? This is a reasonable >>>? ? ? > substitute for desktop sessions. >>>? ? ? > >>>? ? ? > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu >>>? ? ? > for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my >>>? ? ? > menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin >>>? ? ? > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this >>>? ? ? > appears to give me the same functionality as running these programs in an iceWM desktop session, >>>? ? ? > with the additional advantage that the xpra child windows function as windows on the client desktop >>>? ? ? > itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org >>>? ? ? > FAQs seem to indicate applications are problematic to run under KDE/Plasma. >>>? ? ? > >>>? ? ? > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. >>>? ? ? > >>>? ? ? > Other points: >>>? ? ? > >>>? ? ? > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement >>>? ? ? > this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and >>>? ? ? > I can use sftp, ssh, etc. to the server. >>>? ? ? > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as >>>? ? ? > "unknown".? I can't access or kill this session. >>>? ? ? > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in >>>? ? ? > opSU 13.2 repositories. >>>? ? ? > >>>? ? ? > >>>? ? ? > For reference: >>>? ? ? > >>>? ? ? > Server 1: >>>? ? ? > 6 core AMD x86_64 >>>? ? ? > openSuSE 13.1 >>>? ? ? > linux kernel 3.11.10-25-desktop >>>? ? ? > KDE platform 4.14.6 >>>? ? ? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 >>>? ? ? > xpra-0.14.4 (also in an rpm I built from sources) >>>? ? ? > >>>? ? ? > remote desktops work / remote applications do not work >>>? ? ? > >>>? ? ? > Server 2: >>>? ? ? > 8 core AMD x86_64 >>>? ? ? > openSuSE 13.2 >>>? ? ? > linux kernel 3.19.3-1-gf10e7fc-desktop >>>? ? ? > KDE platform 4.14.6 >>>? ? ? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 >>>? ? ? > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) >>>? ? ? > >>>? ? ? > remote desktops do not work / remote applications do work, per above description. >>>? ? ? > >>>? ? ? > Barrington Daltrey >>>? ? ? > >>>? ? ? > >>>? ? ? > >>>? ? ? > >>>? ? ? > >>>? ? ? > _______________________________________________ >>>? ? ? > 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 >>>? ? ? ? >>>? ? ? >>>? ? ? ? ? ? >>>? ? ? >>>? ? ? >>> >>>? ? ? ? >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 fhenryco at yahoo.fr Thu May 28 13:14:55 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Thu, 28 May 2015 12:14:55 +0000 (UTC) Subject: [winswitch] interesting development In-Reply-To: <1713162320.370632.1432807476128.JavaMail.yahoo@mail.yahoo.com> References: <1713162320.370632.1432807476128.JavaMail.yahoo@mail.yahoo.com> Message-ID: <948837354.524808.1432815295345.JavaMail.yahoo@mail.yahoo.com> Yes the problem is with my client: odroid C1: ?it is slow anyway (without xpra but direct web access) on youtube without Opengl ES acceleration... only with Opengl ES does it give a correct HD experience ... I's a pity but i think i'll have to wait for improved hardware low cost small boards to reach the perfect low cost polyvalent client that will work with xpra... hope coming soon? thank's again F Le Jeudi 28 mai 2015 12h04, Fr?d?ric Henry-Couannier a ?crit : the server is very powerful and the link is just an ethernet cable .... so in principle the bottleneck can only be the client (?Amlogic ARM? Cortex?-A5(ARMv7) 1.5Ghz quad core CPUs?.. But even with no compression it's slow (?!), so i'm going to investigate with another machine as client ... F H-C ? ? ? Le Jeudi 28 mai 2015 11h45, Antoine Martin a ?crit : ? On 28/05/15 13:32, Fr?d?ric Henry-Couannier wrote: > thanks for advices and helpful support > I installed pip , lz4 and could choose rgb and lz4 for my window , result fluid in 420p youtube but becomes slow in 720p and beyond...i'm wondering what kind of other parameters could improve Try "--compress=0" Then I guess you need to figure out where the bottleneck is: * are you CPU bound on the server? On the client? * is your network maxed out? etc.. >? ... however openGL is not supported by my small client board (odroid , a little bit more powerful than last raspberry pi) ... Is it foreseen to implement OpenGL-ES in xpra ? This is not planned, yet. > this might allow better performances on such small board , very low prices clients... > > >? ? ? Le Jeudi 28 mai 2015 5h28, Antoine Martin a ?crit : >? ? > >? On 28/05/15 01:58, Fr?d?ric Henry-Couannier wrote: >> Yes i had readen but for instance when i tried >> xpra control :100 compression lz4 >> i got >> server returned error code 5invalid argument for 'compression': must be one of: zlib >>? ? I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from lz4 0.7.0 : Python Package Index and install with? $ pip install lz4$ easy_install lz4 >> |? | >> |? |? |? |? |? |? |? | >> | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python | >> |? | >> | Afficher sur pypi.... | Aper?u par Yahoo | >> |? | >> |? | >> >>? ? but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC? :-) > Installing things is always best done through your distribution's > package manager - whatever that is. > Though in this particular case, it should be pretty safe to just pip or > easy_install lz4. > (the only downside is that unlike regular packages, you will not get > updates automatically) > > Antoine > > >> >>? ? ? ? Le Mercredi 27 mai 2015 19h29, Antoine Martin a ?crit : >>? ? ? >> >>? ? On 28/05/15 00:22, Fr?d?ric Henry-Couannier wrote: >>> Well i'm not sur i understand what you mean by... the right settings... >> Please see the wiki link, and ask questions once you've read it. >>> May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete... >> You're not saying which instructions, so that's impossible for me to say. >>> for instance i dont have winswitch ... >> It isn't required if all you want is xpra. >>>? ? ? The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ... >> Not going to happen I am afraid. We can't support every distro out there. >> Though we will gladly accept packaging contributions that enhance >> support for those distros. >> >> Cheers >> Antoine >> >>>? ? ? >>> >>> >>> >>>? ? ? ? ? Le Mercredi 27 mai 2015 10h55, Antoine Martin a ?crit : >>>? ? ? ? >>> >>>? ? ? ? On 27/05/15 00:37, Fr?d?ric Henry-Couannier wrote: >>>? ? ? ? >>>? ? ? ? ? thanks for answering, >>>? ? ? ? yes xterm forwarding works. and yes i get a window which content is black for Xnest. >>>? ? ? ? i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)? >>>? ? ? Assuming that you are using the right settings, see: >>>? ? ? http://xpra.org/trac/wiki/Encodings >>>? ? ? (usually means using lz4+rgb on a LAN, or h264 otherwise) >>>? ? ? Encoding is almost always CPU bound on the server side, rarely an issue client side. >>>? ? ? (having opengl rendering client side helps too) >>>? ? ? Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases. >>>? ? ? >>>? ? ? Antoine >>>? ? ? >>>? ? ? >>>? ? ? ? ? >>>? ? ? ? >>>? ? ? >>>? ? ? >>>? ? ? ? ? ? ? ? Le Mardi 26 mai 2015 12h57, Antoine Martin a ?crit : >>>? ? ? ? >>>? ? ? >>>? ? ? On 26/05/15 15:53, Fr?d?ric Henry-Couannier wrote: >>>? ? ? > hello , >>>? ? ? > Now i have tested successfully xpra? for application forwarding? between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding. >>>? ? ? > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100 >>>? ? ? > DISPLAY=:200 fluxbox&and get message >>>? ? ? > Xlib:? extension "RANDR" missing on display ":200" >>>? ? ? Some window managers may require randr, though I don't think fluxbox does. >>>? ? ? You might want to try with Xephyr instead of Xnest. >>>? ? ? > ?? what does it mean i have no idea >>>? ? ? > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen >>>? ? ? By "a black screen", I assume that you mean you get a window whose >>>? ? ? contents are black? >>>? ? ? The fact that something shows up at all tells me that xpra is forwarding >>>? ? ? something, which should be the Xnest window. >>>? ? ? Have you tried another window manager instead of fluxbox? >>>? ? ? Have you tried also starting and xterm on that display? Does that show up? >>>? ? ? >>>? ? ? Antoine >>>? ? ? > best, >>>? ? ? > Fred >>>? ? ? > >>>? ? ? > >>>? ? ? >? ? ? Le Mardi 7 avril 2015 23h54, basd a ?crit : >>>? ? ? > >>>? ? ? > >>>? ? ? >? In my earlier post I mentioned problems connecting to server socket for desktops.? However, with >>>? ? ? > implementation of xpra-0.14.21 I am able to run xpra sessions. >>>? ? ? > >>>? ? ? > Interestingly, I can spawn multiple child windows from an xpra remote application that function as >>>? ? ? > windows on the client -- but can be moved collectively to another client.? This is a reasonable >>>? ? ? > substitute for desktop sessions. >>>? ? ? > >>>? ? ? > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu >>>? ? ? > for launching favorite programs.? Using that script, I can launch an xterm session in xpra, run my >>>? ? ? > menu bash script and launch separate programs from it.? For instance, I can run firefox, dolphin >>>? ? ? > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel).? So far, this >>>? ? ? > appears to give me the same functionality as running these programs in an iceWM desktop session, >>>? ? ? > with the additional advantage that the xpra child windows function as windows on the client desktop >>>? ? ? > itself.? Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org >>>? ? ? > FAQs seem to indicate applications are problematic to run under KDE/Plasma. >>>? ? ? > >>>? ? ? > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me. >>>? ? ? > >>>? ? ? > Other points: >>>? ? ? > >>>? ? ? > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement >>>? ? ? > this because I use a VPN, so I have always used direct connections.? Ssh is active on the server and >>>? ? ? > I can use sftp, ssh, etc. to the server. >>>? ? ? > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as >>>? ? ? > "unknown".? I can't access or kill this session. >>>? ? ? > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in >>>? ? ? > opSU 13.2 repositories. >>>? ? ? > >>>? ? ? > >>>? ? ? > For reference: >>>? ? ? > >>>? ? ? > Server 1: >>>? ? ? > 6 core AMD x86_64 >>>? ? ? > openSuSE 13.1 >>>? ? ? > linux kernel 3.11.10-25-desktop >>>? ? ? > KDE platform 4.14.6 >>>? ? ? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1 >>>? ? ? > xpra-0.14.4 (also in an rpm I built from sources) >>>? ? ? > >>>? ? ? > remote desktops work / remote applications do not work >>>? ? ? > >>>? ? ? > Server 2: >>>? ? ? > 8 core AMD x86_64 >>>? ? ? > openSuSE 13.2 >>>? ? ? > linux kernel 3.19.3-1-gf10e7fc-desktop >>>? ? ? > KDE platform 4.14.6 >>>? ? ? > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2 >>>? ? ? > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2) >>>? ? ? > >>>? ? ? > remote desktops do not work / remote applications do work, per above description. >>>? ? ? > >>>? ? ? > Barrington Daltrey >>>? ? ? > >>>? ? ? > >>>? ? ? > >>>? ? ? > >>>? ? ? > >>>? ? ? > _______________________________________________ >>>? ? ? > 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 >>>? ? ? ? >>>? ? ? >>>? ? ? ? ? ? >>>? ? ? >>>? ? ? >>> >>>? ? ? ? >>> _______________________________________________ >>> 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 > _______________________________________________ > 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 ? _______________________________________________ shifter-users mailing list shifter-users at lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users From basd1 at fastbk.com Thu May 28 17:03:01 2015 From: basd1 at fastbk.com (basd) Date: Thu, 28 May 2015 09:03:01 -0700 Subject: [winswitch] crashing server In-Reply-To: <556587C3.10603@nagafix.co.uk> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> <556587C3.10603@nagafix.co.uk> Message-ID: <55673C35.9040805@fastbk.com> Um, yep. I can consistently crash my server. But, is it possible this has something to do with the RPM build I made, such as if the .spec file was not correct? (openSuSE 13.2) On 05/27/2015 02:00 AM, Antoine Martin wrote: > You should never be able to crash a server by launching an xterm or xephyr, sounds like a major > bug somewhere. From daltrey at daltrey.org Thu May 28 17:08:29 2015 From: daltrey at daltrey.org (Barrington Daltrey) Date: Thu, 28 May 2015 09:08:29 -0700 Subject: [winswitch] xpra full desktop In-Reply-To: <556588A4.1080304@nagafix.co.uk> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> <5564E2DB.2080202@fastbk.com> <5565301B.6070802@fastbk.com> <556588A4.1080304@nagafix.co.uk> Message-ID: <55673D7D.1010300@daltrey.org> That makes sense, but ... I'm just reporting what happens. If I use Winswitch to open VNC sessions, "logout" terminates the session. If I use Xpra in the manner described, "logout" triggers server logout. Between this and the server crashes it seems that at least on my installs some commands are "leaking" to the server as opposed t the virtual environment. (Server crash essentially shuts down the running X on the server, but does not send me to command console, just limbo.) On 05/27/2015 02:04 AM, Antoine Martin wrote: > There should not be any difference with any other tool, VNC or other. > We don't handle the logout buttons in any special way. This is far removed from the role of xpra > and is handled (often badly) by the desktop environments. From basd1 at fastbk.com Thu May 28 17:42:33 2015 From: basd1 at fastbk.com (basd) Date: Thu, 28 May 2015 09:42:33 -0700 Subject: [winswitch] winswitch / xpra dependencies In-Reply-To: <55668A3A.1070406@nagafix.co.uk> References: <55658677.5020708@nagafix.co.uk> <380666757.828388.1432747362887.JavaMail.yahoo@mail.yahoo.com> <556613BB.4050106@fastbk.com> <55668A3A.1070406@nagafix.co.uk> Message-ID: <55674579.3070708@fastbk.com> I assume your comments reference the package immediately above the comment? python-lz4 (listed as the second one in my list, later I listed python-lzo because it was in another section of the .spec file). X265 -- I think I added this as the result of runtime feedback asking for it. OpenGL -- true, I don't think there is specifically an OpenGL package, but as far as I can tell, OpenGL is needed. Growl I added as the result of runtime errors specifically referring to missing Growl. python-PyVirtualDisplay > I don't know what this is, doubt it is needed. Don't know either, actually. I think I just put it in one of my spec files because it sounded like it might help. >> WINSWITCH > Note: the vast majority of those dependencies are optional. > Winswitch can figure out what is installed and use whatever is there. Makes sense. I was just trying to provide a complete reference, I pasted these directly from the .spec file. From jiang.qian at gmail.com Fri May 29 06:15:47 2015 From: jiang.qian at gmail.com (Jiang Qian) Date: Fri, 29 May 2015 01:15:47 -0400 Subject: [winswitch] Xpra man page confusion: compression level and compressor Message-ID: Perhaps I am missing something, but this line in the entry about --compress=LEVEL in the manpage of xpra confuses me: "If lz4 compression is available, it will be enabled *when the level is set to 1*, lz4 compresses a lot less than zlib but it is also much faster." I use RBG encoding, and I certainly have lz4 compression available. I enable them in command line by "--encoding=rgb --compressor=lz4" Does that mean I need to put "--compress=1" to set compression level to 1 in order for xpra to use lz4? What will happen if I put --compress=0 --compressor=lz4? What about --compress=3 --compressor=lz4? I am using xpra over a gigabit lan, but on a weaker client side processor (the server have very powerful processor). I want rgb for display quality. I watch flash videos (e.g. nytimes, daily show) that are too slow to play on the client side, obviously with sound. So are --encode=rgb --packet-encoder=rencode --compress=1 --compresspr=lz4 --speaker-encoder=wav the best options to have? Right now there are occassional lags and out of sync in sound. I'm running 0.14.24 on both server and clients, both running Ubuntu 14.04. I only forward individual window, not whole desktop. And yes, I use xvfb. Thanks in advance for any advice. Regards Jiang From basd1 at fastbk.com Sat May 30 17:14:03 2015 From: basd1 at fastbk.com (daltrey) Date: Sat, 30 May 2015 09:14:03 -0700 Subject: [winswitch] xpra build error In-Reply-To: <5564E2DB.2080202@fastbk.com> References: <55245084.5020205@fastbk.com> <730571777.3436624.1432630431342.JavaMail.yahoo@mail.yahoo.com> <5564518B.5090902@nagafix.co.uk> <5564B4D2.8040605@fastbk.com> <5564E2DB.2080202@fastbk.com> Message-ID: <5569E1CB.7020801@fastbk.com> Is this something that can be fixed? Revised spec file has better set of "Requires" and builds on openSuSE 13.1 but I get the following on openSuSE 13.2. Maybe I have an uninstalled build dependency? If so, rpmbuild does not give me that error... I will re-check and let you know. building 'xpra.codecs.dec_avcodec.decoder' extension creating build/temp.linux-x86_64-2.7/xpra/codecs/dec_avcodec gcc -pthread -fno-strict-aliasing -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DOPENSSL_LOAD_CONF -fPIC -I/usr/include/python2.7 -c xpra/codecs/dec_avcodec/decoder.c -o build/temp.linux-x86_64-2.7/xpra/codecs/dec_avcodec/decoder.o -Wall -Werror=implicit-function-declaration -fPIC xpra/codecs/dec_avcodec/decoder.c: In function 'initdecoder': xpra/codecs/dec_avcodec/decoder.c:11087:45: error: 'AV_PIX_FMT_YUV420P' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_YUV420P); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 13; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11087:45: note: each undeclared identifier is reported only once for each function it appears in xpra/codecs/dec_avcodec/decoder.c:11099:45: error: 'AV_PIX_FMT_YUV422P' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_YUV422P); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 14; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11111:45: error: 'AV_PIX_FMT_YUV444P' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_YUV444P); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 15; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11123:45: error: 'AV_PIX_FMT_RGB24' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_RGB24); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 16; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11135:45: error: 'AV_PIX_FMT_0RGB' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_0RGB); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 17; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11147:45: error: 'AV_PIX_FMT_BGR0' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_BGR0); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 18; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11159:45: error: 'AV_PIX_FMT_ARGB' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_ARGB); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 19; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11171:45: error: 'AV_PIX_FMT_BGRA' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_BGRA); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 20; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ xpra/codecs/dec_avcodec/decoder.c:11183:45: error: 'AV_PIX_FMT_GBRP' undeclared (first use in this function) __pyx_t_1 = __Pyx_PyInt_From_unsigned_int(AV_PIX_FMT_GBRP); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[1]; __pyx_lineno = 21; __pyx_clineno = __LINE__; goto __pyx_L1_error;} ^ error: command 'gcc' failed with exit status 1 error: Bad exit status from /var/tmp/rpm-tmp.dWwekV (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.dWwekV (%build) From antoine at nagafix.co.uk Sun May 31 10:52:05 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 31 May 2015 16:52:05 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.15.0 (new major release) Message-ID: <556AD9C5.8060506@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, It took a lot longer than planned, but it is finally here and we think it was worth the wait. The fact that the 0.14 LTS branch will continue to be supported for a while allows us to drop compatibility with older platforms, remove workarounds and the ugly code that goes with it. This new release also received more regression testing than any release before it. You can find a more details on the new features and changes here: http://xpra.org/trac/wiki/News#a0.15.0Release Here is quick summary of the most noteworthy changes: * the HTML5 client is now usable * printer forwarding is supported * NVENC: SDK version 4 and 5, including YUV444 and lossless mode * VP9 support: a free software alternative to x264 * Sound forwarding: more stable, more configurable * Remote client logging: centralizing the debug and error logging * more standards compliant window management * Python 3 support (still work in progress) * OSX build infrastructure work * Picture encoding improvements: faster re-striding, multi-regions, etc * start new commands from the system tray * an HTML version of the manual is bundled with the installers * fixed window grouping in the taskbar (MS Windows 7 onwards) * added unit tests, more regression testing * better logging and debugging tools As usual, if you find issues or regressions, please let us know. It is difficult to fix issues we don't know about! And now that the development has started for version 0.16, feel free to suggest features or areas that need improvement: http://xpra.org/trac/milestone/0.16 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVq2cEACgkQGK2zHPGK1rt9LwCfRY4rx1nZr0aPkYALwZnKSxbg T2cAn1sphB6Y9KWhA3gpJofw8MbrWrFV =ycJC -----END PGP SIGNATURE-----