From johnss1221 at gmail.com Mon Nov 3 08:03:15 2014 From: johnss1221 at gmail.com (John Smith) Date: Mon, 3 Nov 2014 15:03:15 +0700 Subject: [winswitch] [Xpra] Limit maximum number of windows Message-ID: Hi, Can we limit maximum number of windows that we allow in client-side ? I saw a number of current windows which are opening, but I don't know how to limit it. From antoine at nagafix.co.uk Mon Nov 3 09:13:51 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 03 Nov 2014 16:13:51 +0700 Subject: [winswitch] [Xpra] Limit maximum number of windows In-Reply-To: References: Message-ID: <5457474F.30809@nagafix.co.uk> On 03/11/14 15:03, John Smith wrote: > Hi, > > Can we limit maximum number of windows that we allow in client-side ? I saw > a number of current windows which are opening, but I don't know how to > limit it. Definitely not. There is no way to know in advance how many windows a session will need. Almost every tooltip, every drop down menu, every alert box is in fact its own window. Stopping at an arbitrary set number would be a recipe for disaster. If you have applications that misbehave, fix those applications. (though obviously, if they only misbehave in Xpra, we should fix that) Antoine From ntlong0210 at gmail.com Thu Nov 6 09:26:05 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Thu, 6 Nov 2014 02:26:05 -0700 Subject: [winswitch] xpra control argument In-Reply-To: <5453041A.70901@nagafix.co.uk> References: <545200F2.4000005@nagafix.co.uk> <5453041A.70901@nagafix.co.uk> Message-ID: Hi, On Thu, Oct 30, 2014 at 8:38 PM, Antoine Martin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 31/10/14 08:26, Long Nguyen Thanh wrote: > > Hi all, > > > > I also need more info about this command. > > I tried : > > xpra control :DISPLAY encoding help > > Result is "set encoding to help for 2 windows" > encoding does not support "help" > It is one of the ones deemed too "obvious": as you figured out, the > encoding options are the same as everywhere else. > See man page. See also: > xpra attach --encoding=help > > But encoding must be rgb, png, jpeg, webp,... > > Try with other 1st argument : > > xpra control :DISPLAY client help > > Result is "client control command 'help' forwarded to 0 clients > > Inthis ticket > , I found "xpra control :DISPLAY client > show_session_info" > > It will show session info dialog in client-side. > > Can I get more 2nd, 3rd argument similiar with 'show_session_info' ? > Maybe 'show_bug_report', 'show_bug_report save path' , or 'raise_windows' ? > Sure, if someone implements it. > Feel free to file tickets for that. > > Can I get all info in statistic tab of session info and put it to a file > by a/some command(s) at client-side ? > "xpra info" contains this data, and more. > > In "xpra info", it contains some data like this : *encoding.pixels_per_ns*, "ns" is nano seconds ? And how to find "pixels/region" data ( which I found from session info ) in "xpra info" ? I don't see anything like "region". Thanks :) > Antoine > > > > > > On Thu, Oct 30, 2014 at 4:12 PM, Antoine Martin > wrote: > > > > On 29/10/14 08:38, John Smith wrote: > > > Hi, > > > > > > xpra control :DISPLAY help will return 1st argument of "xpra > control" > > > xpra control :100 help > > > "control supports: hello, help, debug, encoding, auto-refresh, > quality, > > > min-quality, speed, min-speed, compression, encoder, refresh, > > sound-output, > > > scaling, suspend, resume, name, ungrab, key, focus, client" > > > > > > How to get 2nd argument ? I know only a bit of it. > > > xpra control :100 encoding => 2nd arg will be rgb, png, jpeg, ... > > You can try: > > xpra control :100 encoding help > > The "help" argument is supported by some of the control options, and > > others are deemed to be too obvious (ie: quality, speed, etc) > > This interface is not meant to be API stable, so you will not find > > anything about it in the man page. > > You may find some examples in the original ticket: > > http://xpra.org/trac/ticket/461 > > > > Cheers > > Antoine > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlRTBBkACgkQGK2zHPGK1rt+cwCbB/bh3hT3L1F+SSQOGzDnAdcK > UxQAn1KiGms3d08Pd6VMEAuasVeMYUGz > =OxYp > -----END PGP SIGNATURE----- > > From antoine at nagafix.co.uk Thu Nov 6 13:22:43 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 06 Nov 2014 20:22:43 +0700 Subject: [winswitch] xpra control argument In-Reply-To: References: <545200F2.4000005@nagafix.co.uk> <5453041A.70901@nagafix.co.uk> Message-ID: <545B7623.20401@nagafix.co.uk> Please turn off HTML mail when posting to the list. > In "xpra info", it contains some data like this : *encoding.pixels_per_ns*, "ns" is nano seconds ? OTOH, it should probably be microseconds or something. > And how to find "pixels/region" data ( which I found from session info ) in "xpra info" ? I don't see anything like "region". You are looking for the "total_frames" values. Antoine From lukashaase at gmx.at Fri Nov 7 07:14:36 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Fri, 7 Nov 2014 08:14:36 +0100 Subject: [winswitch] xpra unuseable on CentOS 5 Message-ID: Hi, Unfortunately my problem is difficult to describe. First of all, I used an old xpra v0.11.2 happily on an Ubuntu machine for over 1 year. I did not have root rights so I needed to hack around with $PYTHONPATH, manually extracting files from debs to my home directory and finally, this old version was the one worked. Now I have a machine with CentOS 5.11 and I am facing heavy problems with xpra. I use the winswitch repository and just did "yum install xpra". When I use xpra is it very slaggish, it sometimes does not react to keystrokes. Also, when there is text input, I cannot place the cursor there (it just does not react). Or it marks multiple test block in different text fields (which technically can't happen) or the cursor jumps around wildly in different text fields. Anyway, it's really hard to describe exactly. Sometimes it works at the beginning, then stopes. Sometimes it does not work at all. It just makes it completely unuseable! The connection is a GB connection directly to the server (client is Win7 with cygwin), the server is a 2 core virtual machine with 8GB RAM, no load. This is neither a hardware, nor a network problem. It is also evident in the sense that I use X forwarding directly with the *same* setup but without xpra, it works flawlessly and perfectly! I tried setting "--encoding=rgb". This helped a little bit. But not much. I tried setting "--no-keybard-sync". This did not change anything. In the terminal I get: $ xpra attach :1984 --encoding=rgb 2014-11-06 21:08:29,194 xpra client version 0.14.9 2014-11-06 21:08:29,213 OpenGL support could not be enabled: 2014-11-06 21:08:29,213 No module named gdkgl 2014-11-06 21:08:29,219 error running '['setxkbmap', '-print']': [Errno 2] No such file or directory 2014-11-06 21:08:29,351 dbus setup error: No module named mainloop.glib 2014-11-06 21:08:29,356 cannot use mmap: python version is too old? 2014-11-06 21:08:29,364 detected keyboard: rules=base, model=pc105, layout=us 2014-11-06 21:08:29,366 desktop size is 3200x1200 with 1 screen(s): 2014-11-06 21:08:29,367 'localhost:10.0' (847x318 mm) 2014-11-06 21:08:29,367 monitor 1 1920x1200 at 1280x0 2014-11-06 21:08:29,367 monitor 2 1280x768 at 0x193 2014-11-06 21:08:29,371 sound support not available: No module named sound 2014-11-06 21:08:29,398 server: Linux Linux-2.6.18-398.el5-x86_64-with-redhat-5.11-Final, Xpra version 0.14.9 (runknown) 2014-11-06 21:08:29,443 Attached to :1984 (press Control-C to detach) 2014-11-06 21:20:55,061 server is not responding, drawing spinners over the windows 2014-11-06 21:20:55,568 server is OK again 2014-11-06 21:23:10,510 server is not responding, drawing spinners over the windows 2014-11-06 21:23:11,039 server is OK again The last lines appear over and over again. But as mentioned: No network latency, no load on either server and client! What bothers me a little bit is "cannot use mmap: python version is too old?". I have "Python 2.4.3", the standard from CentOS. Is this really too old? Would anyone be kind to help me to debug this problem and hopefully get xpra working? I don't want to use VNC (which forwards the whole desktop)... :-( Thanks so much From antoine at nagafix.co.uk Fri Nov 7 15:26:42 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 07 Nov 2014 22:26:42 +0700 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: References: Message-ID: <545CE4B2.9000105@nagafix.co.uk> Hi, On 07/11/14 14:14, Lukas Haase wrote: > Hi, > > Unfortunately my problem is difficult to describe. > First of all, I used an old xpra v0.11.2 happily on an Ubuntu machine for over 1 year. > I did not have root rights so I needed to hack around with $PYTHONPATH, manually extracting files from debs to my home directory and finally, this old version was the one worked. > > Now I have a machine with CentOS 5.11 and I am facing heavy problems with xpra. I use the winswitch repository and just did "yum install xpra". > > When I use xpra is it very slaggish, it sometimes does not react to keystrokes. Also, when there is text input, I cannot place the cursor there (it just does not react). > Or it marks multiple test block in different text fields (which technically can't happen) or the cursor jumps around wildly in different text fields. > Anyway, it's really hard to describe exactly. Sometimes it works at the beginning, then stopes. Sometimes it does not work at all. > It just makes it completely unuseable! Try the usual suspects: turn off clipboard, opengl, sound, etc.. If the problem persists, it would be worth downgrading the server (try 0.13.x or 0.12.x), to see if it helps. > The connection is a GB connection directly to the server (client is Win7 with cygwin), the server is a 2 core virtual machine with 8GB RAM, no load. You are using the native MS Windows client right? Anything else, like a cygwin build for example, is not supported and will not work well - if at all. > This is neither a hardware, nor a network problem. > It is also evident in the sense that I use X forwarding directly with the *same* setup but without xpra, it works flawlessly and perfectly! With a gigabit connection, you should get near-local performance. > I tried setting "--encoding=rgb". This helped a little bit. But not much. > I tried setting "--no-keybard-sync". This did not change anything. > > In the terminal I get: > $ xpra attach :1984 --encoding=rgb > 2014-11-06 21:08:29,194 xpra client version 0.14.9 > 2014-11-06 21:08:29,213 OpenGL support could not be enabled: > 2014-11-06 21:08:29,213 No module named gdkgl > 2014-11-06 21:08:29,219 error running '['setxkbmap', '-print']': [Errno 2] No such file or directory > 2014-11-06 21:08:29,351 dbus setup error: No module named mainloop.glib > 2014-11-06 21:08:29,356 cannot use mmap: python version is too old? > 2014-11-06 21:08:29,364 detected keyboard: rules=base, model=pc105, layout=us > 2014-11-06 21:08:29,366 desktop size is 3200x1200 with 1 screen(s): > 2014-11-06 21:08:29,367 'localhost:10.0' (847x318 mm) > 2014-11-06 21:08:29,367 monitor 1 1920x1200 at 1280x0 > 2014-11-06 21:08:29,367 monitor 2 1280x768 at 0x193 > 2014-11-06 21:08:29,371 sound support not available: No module named sound > 2014-11-06 21:08:29,398 server: Linux Linux-2.6.18-398.el5-x86_64-with-redhat-5.11-Final, Xpra version 0.14.9 (runknown) > 2014-11-06 21:08:29,443 Attached to :1984 (press Control-C to detach) > 2014-11-06 21:20:55,061 server is not responding, drawing spinners over the windows > 2014-11-06 21:20:55,568 server is OK again > 2014-11-06 21:23:10,510 server is not responding, drawing spinners over the windows > 2014-11-06 21:23:11,039 server is OK again > > > The last lines appear over and over again. But as mentioned: No network latency, no load on either server and client! > What bothers me a little bit is "cannot use mmap: python version is too old?". > I have "Python 2.4.3", the standard from CentOS. Is this really too old? Very much so. Python 2.4.3 was released in early 2006 and upstream support has stopped a long time ago. CentOS 5 is supported in the 0.14 LTS branch only, but barely: it should run but it is not meant to provide the features or performance found on more recent OSes, versions 0.15 onwards will not support CentOS 5.x It is time to move on. > Would anyone be kind to help me to debug this problem and hopefully get xpra working? I've just tried my CentOS 5.x test VMs and did not experience any problems, no slow downs connecting with a Windows 7 client. There must be something unusual in your setup or the application that you use. Please file a ticket with as many details as you can provide and we can try to get to the bottom of it: http://xpra.org/trac/wiki/ReportingBugs > I don't want to use VNC (which forwards the whole desktop)... :-( Fair enough! Cheers Antoine > > > > Thanks so much From ntlong0210 at gmail.com Sat Nov 8 01:01:29 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Sat, 8 Nov 2014 08:01:29 +0700 Subject: [winswitch] xpra control argument In-Reply-To: <545B7623.20401@nagafix.co.uk> References: <545200F2.4000005@nagafix.co.uk> <5453041A.70901@nagafix.co.uk> <545B7623.20401@nagafix.co.uk> Message-ID: On Thu, Nov 6, 2014 at 8:22 PM, Antoine Martin wrote: > Please turn off HTML mail when posting to the list. > >> In "xpra info", it contains some data like this : *encoding.pixels_per_ns*, "ns" is nano seconds ? > OTOH, it should probably be microseconds or something. > >> And how to find "pixels/region" data ( which I found from session info ) in "xpra info" ? I don't see anything like "region". > You are looking for the "total_frames" values. I found it, thank you again for everything you?ve done. From lukashaase at gmx.at Sat Nov 8 04:57:45 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Sat, 8 Nov 2014 05:57:45 +0100 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: <545CE4B2.9000105@nagafix.co.uk> References: , <545CE4B2.9000105@nagafix.co.uk> Message-ID: Hi Antoine, Thanks for your answer. Before I file a bug report I want to try it again here because I think I got a better handle what is wrong. So in my application, when a child window opens, I realized that it largly reacts to mouse input but not to keyboard input. As mentioned, this does not happen from the beginning but starts somewhen "randomly". Reconnecting with "xpra attach" does not help, only restarting the whole server helps. When this happens it seems that although the child window has focus, the keyboard input is redirected to its parent window (!). I can observe this when I have focus on the child window (clicked on it, cursor above it) and when I press a button, instead of typing in the child window I see the action taking place in the parent window. Also, when this happens I can mark every entry in every input field and the cursor appears in every input field. This screenshot shows an example of such a child window: http://snag.gy/VbuxV.jpg It can be seen that all text is marked (because I made a double click in every field) which should not happen. Also, the cursor flashes in each of the input fields. When I press 'r' for example, it is not typed into any field but instead, an action associated with 'r' key is taken in the *parent* window which has no focus! For the rest if the answers, see below: > On 07/11/14 14:14, Lukas Haase wrote: > > [...] > > I have "Python 2.4.3", the standard from CentOS. Is this really too old? > Very much so. Python 2.4.3 was released in early 2006 and upstream > support has stopped a long time ago. > CentOS 5 is supported in the 0.14 LTS branch only, but barely: it should > run but it is not meant to provide the features or performance found on > more recent OSes, versions 0.15 onwards will not support CentOS 5.x > It is time to move on. Unfortunately I can't switch the OS. At least I have root rights now but I can't upgrade the system. Would you recommend to move to 0.14 LTS banch? If so, is there an easy way to install it via yum and winswitch repository? Is there a way to install an appropriate python on CentOS 5? If not, install it at least to something like /opt/new_python and let xpra use it? I am also facing other weird messages like on the server: $ xpra start :1984 --no-daemon --no-mdns --no-notification --no-pulseaudio 2014-11-07 16:39:22,591 your version of PyGTK is too old - expect some bugs [...] 2014-11-07 16:39:22,665 cannot load dbus helper: No module named mainloop.glib 2014-11-07 16:39:22,667 Warning: outdated/buggy version of Python: 2.4.3.final.0 [...] 2014-11-07 16:40:05,546 Your Cairo is too old! Carrying on as best I can, but don't expect a miracle [...] 2014-11-07 16:40:30,805 signal_safe_exec(['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'us'],None) stdout='Couldn't interpret _XKB_RULES_NAMES property Use defaults: rules - 'xorg' model - 'pc101' layout - 'us' ' 2014-11-07 16:40:30,805 signal_safe_exec(['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'us'],None) stderr='Couldn't find rules file (base) ' 2014-11-07 16:40:30,805 ['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'us'] with stdin=None, failed with exit code 252 [...] And on the client: $ xpra attach :1984 --encoding=rgb [...] 2014-11-07 17:11:21,871 OpenGL support could not be enabled: 2014-11-07 17:11:21,871 No module named gdkgl [...] 2014-11-07 17:11:21,910 signal_safe_exec(['setxkbmap', '-print'],None) stderr='Couldn't find rules file (base) ' 2014-11-07 17:11:21,910 '['setxkbmap', '-print']' failed with exit code 252 2014-11-07 17:11:22,155 dbus setup error: No module named mainloop.glib 2014-11-07 17:11:22,162 cannot use mmap: python version is too old? [...] 2014-11-07 17:11:22,205 sound support not available: No module named sound 2014-11-07 17:11:22,239 server: Linux Linux-2.6.18-398.el5-x86_64-with-redhat-5.11-Final, Xpra version 0.14.10 (runknown) [...] Is there anything I could do w/o upgrading from CentOS 5? Thanks, Lukas From antoine at nagafix.co.uk Sat Nov 8 05:25:50 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 08 Nov 2014 12:25:50 +0700 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: References: , <545CE4B2.9000105@nagafix.co.uk> Message-ID: <545DA95E.3050209@nagafix.co.uk> On 08/11/14 11:57, Lukas Haase wrote: > Hi Antoine, > > Thanks for your answer. > > Before I file a bug report I want to try it again here because I think I got a better handle what is wrong. I still think a ticket is a better place for this. > So in my application, when a child window opens, I realized that it largly reacts to mouse input but not to keyboard input. > As mentioned, this does not happen from the beginning but starts somewhen "randomly". > Reconnecting with "xpra attach" does not help, only restarting the whole server helps. xpra upgrade? > When this happens it seems that although the child window has focus, the keyboard input is redirected to its parent window (!). > I can observe this when I have focus on the child window (clicked on it, cursor above it) and when I press a button, instead of typing in > the child window I see the action taking place in the parent window. > > Also, when this happens I can mark every entry in every input field and the cursor appears in every input field. > > This screenshot shows an example of such a child window: > > http://snag.gy/VbuxV.jpg > > It can be seen that all text is marked (because I made a double click in every field) which should not happen. Also, the cursor flashes in each of the input fields. > When I press 'r' for example, it is not typed into any field but instead, an action associated with 'r' key is taken in the *parent* window which has no focus! The focus code is fiddly, you can try running both the client and server with "-d focus,grab" to get more debugging output. What toolkit is this application written in? Can you post sample code? > For the rest if the answers, see below: > >> On 07/11/14 14:14, Lukas Haase wrote: >>> [...] >>> I have "Python 2.4.3", the standard from CentOS. Is this really too old? >> Very much so. Python 2.4.3 was released in early 2006 and upstream >> support has stopped a long time ago. >> CentOS 5 is supported in the 0.14 LTS branch only, but barely: it should >> run but it is not meant to provide the features or performance found on >> more recent OSes, versions 0.15 onwards will not support CentOS 5.x >> It is time to move on. > > Unfortunately I can't switch the OS. At least I have root rights now but I can't upgrade the system. > > Would you recommend to move to 0.14 LTS banch? If so, is there an easy way to install it via yum and winswitch repository? There's nothing to do if you have 0.14 installed already. 0.14 is the latest in the repository and will be maintained for another ~16 months. CentOS 5 will not be getting the newer branches (0.15 onwards). > Is there a way to install an appropriate python on CentOS 5? > If not, install it at least to something like /opt/new_python and let xpra use it? Not really: before being able to build xpra from source against the newer python, you have to rebuild dozens of other system libraries and manage them (pygtk, etc), and you would still have dozens of outdated libraries being used anyway. > I am also facing other weird messages like on the server: > > $ xpra start :1984 --no-daemon --no-mdns --no-notification --no-pulseaudio > 2014-11-07 16:39:22,591 your version of PyGTK is too old - expect some bugs > [...] > 2014-11-07 16:39:22,665 cannot load dbus helper: No module named mainloop.glib > 2014-11-07 16:39:22,667 Warning: outdated/buggy version of Python: 2.4.3.final.0 > [...] > 2014-11-07 16:40:05,546 Your Cairo is too old! Carrying on as best I can, but don't expect a miracle > [...] > 2014-11-07 16:40:30,805 signal_safe_exec(['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'us'],None) stdout='Couldn't interpret _XKB_RULES_NAMES property > Use defaults: rules - 'xorg' model - 'pc101' layout - 'us' > ' > 2014-11-07 16:40:30,805 signal_safe_exec(['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'us'],None) stderr='Couldn't find rules file (base) > ' > 2014-11-07 16:40:30,805 ['setxkbmap', '-rules', 'base', '-model', 'pc105', '-layout', 'us'] with stdin=None, failed with exit code 252 > [...] All due to outdated (or missing) software in CentOS 5. > And on the client: > > $ xpra attach :1984 --encoding=rgb > [...] > 2014-11-07 17:11:21,871 OpenGL support could not be enabled: > 2014-11-07 17:11:21,871 No module named gdkgl > [...] > 2014-11-07 17:11:21,910 signal_safe_exec(['setxkbmap', '-print'],None) stderr='Couldn't find rules file (base) > ' > 2014-11-07 17:11:21,910 '['setxkbmap', '-print']' failed with exit code 252 > 2014-11-07 17:11:22,155 dbus setup error: No module named mainloop.glib > 2014-11-07 17:11:22,162 cannot use mmap: python version is too old? > [...] > 2014-11-07 17:11:22,205 sound support not available: No module named sound > 2014-11-07 17:11:22,239 server: Linux Linux-2.6.18-398.el5-x86_64-with-redhat-5.11-Final, Xpra version 0.14.10 (runknown) > [...] > > Is there anything I could do w/o upgrading from CentOS 5? No. Nothing worth the effort. Cheers Antoine From lukashaase at gmx.at Sat Nov 8 10:44:09 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Sat, 8 Nov 2014 11:44:09 +0100 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: <545DA95E.3050209@nagafix.co.uk> References: , <545CE4B2.9000105@nagafix.co.uk> , <545DA95E.3050209@nagafix.co.uk> Message-ID: Hi Antoine, > > Before I file a bug report I want to try it again here because I think > I got a better handle what is wrong. > I still think a ticket is a better place for this. Ok, I'll move it there then. > > So in my application, when a child window opens, I realized that it largly reacts to mouse input but > not to keyboard input. > > As mentioned, this does not happen from the beginning but starts > somewhen "randomly". > > Reconnecting with "xpra attach" does not help, only restarting the > whole server helps. > xpra upgrade? (Not) Funny, just tried it, now it does not react at all to any keyboard input. (No error output on either side). > [...] > What toolkit is this application written in? The application is Cadence. Good question, I assume it is plain X11. ldd spits out: libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003417600000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003414600000) librt.so.1 => /lib64/librt.so.1 (0x0000003415200000) libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003415a00000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003416600000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b55038e9000) libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b5503b63000) libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003418e00000) libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003416a00000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003423800000) libm.so.6 => /lib64/libm.so.6 (0x0000003414a00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000341f800000) libc.so.6 => /lib64/libc.so.6 (0x0000003413e00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003414200000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x0000003418200000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b5503de8000) /lib64/ld-linux-x86-64.so.2 (0x0000003413a00000) libSM.so.6 => /usr/lib64/libSM.so.6 (0x000000341be00000) libICE.so.6 => /usr/lib64/libICE.so.6 (0x000000341a600000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003416e00000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003414e00000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x0000003415600000) > Can you post sample code? Which sample code? Source code? That's gonna be difficult because Cadence is closed source, proprietary and protected. > [...] > > Is there anything I could do w/o upgrading from CentOS 5? > No. Nothing worth the effort. Oh man, I could cry. I just looked, the "hack" (where I installed xpra and parts of python as user in my home directory) which worked so nicely is "xpra v0.11.2" but it uses "Python 2.7.5+". I think it's nearly impossible to get this machine upgraded but I may try it at least. If so, what would be the python and/or CentOS version with which everything should work? CentOS 6? Thanks Lukas From antoine at nagafix.co.uk Sat Nov 8 11:00:14 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 08 Nov 2014 18:00:14 +0700 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: References: , <545CE4B2.9000105@nagafix.co.uk> , <545DA95E.3050209@nagafix.co.uk> Message-ID: <545DF7BE.10501@nagafix.co.uk> >> [...] >> What toolkit is this application written in? > The application is Cadence. > Good question, I assume it is plain X11. Looks like it. > ldd spits out: > > libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003417600000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003414600000) > librt.so.1 => /lib64/librt.so.1 (0x0000003415200000) > libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003415a00000) > libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003416600000) > libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002b55038e9000) > libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002b5503b63000) > libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003418e00000) > libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003416a00000) > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003423800000) > libm.so.6 => /lib64/libm.so.6 (0x0000003414a00000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000341f800000) > libc.so.6 => /lib64/libc.so.6 (0x0000003413e00000) > libdl.so.2 => /lib64/libdl.so.2 (0x0000003414200000) > libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x0000003418200000) > libXau.so.6 => /usr/lib64/libXau.so.6 (0x00002b5503de8000) > /lib64/ld-linux-x86-64.so.2 (0x0000003413a00000) > libSM.so.6 => /usr/lib64/libSM.so.6 (0x000000341be00000) > libICE.so.6 => /usr/lib64/libICE.so.6 (0x000000341a600000) > libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003416e00000) > libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003414e00000) > libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x0000003415600000) > >> Can you post sample code? > Which sample code? > Source code? That's gonna be difficult because Cadence is closed source, proprietary and protected. Then the time I can dedicate to this thing is going to be very limited. Debugging third party applications is hard, closed source ones even more so, and if I can't even run it myself... near impossible. Also, from my experience, closed source apps also tend to be more broken. (less likely to use toolkits, more likely to reinvent the wheel.. and get things wrong) >> [...] >>> Is there anything I could do w/o upgrading from CentOS 5? >> No. Nothing worth the effort. > Oh man, I could cry. > > I just looked, the "hack" (where I installed xpra and parts of python as user in my home directory) which worked so nicely is "xpra v0.11.2" but it uses "Python 2.7.5+". I don't understand this bit. > I think it's nearly impossible to get this machine upgraded but I may try it at least. If so, what would be the python and/or CentOS version with which everything should work? CentOS 6? Sure, CentOS 6 or 7 both work well enough. CentOS 6 is a bit dated already. CentOS 7 is a bit annoying as a client OS because it lacks a system tray in the default gnome desktop, much better as a server OS (up to date python and libs). Cheers Antoine From antoine at nagafix.co.uk Sat Nov 8 11:09:42 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 08 Nov 2014 18:09:42 +0700 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: <545DF7BE.10501@nagafix.co.uk> References: , <545CE4B2.9000105@nagafix.co.uk> , <545DA95E.3050209@nagafix.co.uk> <545DF7BE.10501@nagafix.co.uk> Message-ID: <545DF9F6.7010304@nagafix.co.uk> >> I think it's nearly impossible to get this machine upgraded but I may try it at least. If so, what would be the python and/or CentOS version with which everything should work? CentOS 6? > Sure, CentOS 6 or 7 both work well enough. > CentOS 6 is a bit dated already. > CentOS 7 is a bit annoying as a client OS because it lacks a system tray > in the default gnome desktop, much better as a server OS (up to date > python and libs). Just one more thing: there is no guarantee at all that upgrading your host OS will improve the behaviour of the application (especially the focus issues you describe). It sounds like upgrading is going to be a hassle for you, so you may be better off trying it out in a virtual machine before spending too much time down this path. That said, moving away from CentOS 5 sooner rather than later is still worth doing. Antoine From antoine at nagafix.co.uk Sun Nov 9 14:39:46 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 09 Nov 2014 21:39:46 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.14.10 (many fixes) Message-ID: <545F7CB2.50909@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This minor update fixes many issues, updating is recommended. In particular there are some transparency fixes, one of which could cause the client to crash with some specific combinations of PyOpenGL and drivers. The Java SDK6 and earlier - fix is a funny one, you have to use: XPRA_NET_WM_NAME=Sawfish xpra start... To ensure that Java does not make a complete mess with its window inset calculations. The yum repositories have also been updated to ffmpeg 2.4.3 Release notes: * fix crash with zero copy OpenGL pixel upload (now disabled) * fix cursor forwarding with MS Windows clients * fix for the tray menu to allow a mix of left and right clicks * workaround for Java SDK6 and earlier miscalculating window insets * fix transparency detection and encoding selection * fix spurious warning on shadow connection close * fix window class detection * fix CUDA automatic device selection * better client reporting of remote errors Binary builds (OSX and MS Windows) and the RPM repositories have also been updated with: * built with Cython 0.21.1 * libwebp 0.4.2 * Python Pillow 2.6.1 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 iEYEARECAAYFAlRffLIACgkQGK2zHPGK1rsK+ACfa34sSZQUC31mEtea9cBqV3pg I5MAnR1LIkDSn3EA27goDbLUpJd/DckK =Ae1h -----END PGP SIGNATURE----- From lukashaase at gmx.at Wed Nov 12 05:25:32 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Wed, 12 Nov 2014 06:25:32 +0100 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: <545DF9F6.7010304@nagafix.co.uk> References: , <545CE4B2.9000105@nagafix.co.uk> , <545DA95E.3050209@nagafix.co.uk> <545DF7BE.10501@nagafix.co.uk>, <545DF9F6.7010304@nagafix.co.uk> Message-ID: > >> I think it's nearly impossible to get this machine upgraded but I may try it at least. If so, what would be the python and/or CentOS version with which everything should work? CentOS 6? > > Sure, CentOS 6 or 7 both work well enough. > > CentOS 6 is a bit dated already. > > CentOS 7 is a bit annoying as a client OS because it lacks a system tray > > in the default gnome desktop, much better as a server OS (up to date > > python and libs). > Just one more thing: there is no guarantee at all that upgrading your > host OS will improve the behaviour of the application (especially the > focus issues you describe). > It sounds like upgrading is going to be a hassle for you, so you may be > better off trying it out in a virtual machine before spending too much > time down this path. > That said, moving away from CentOS 5 sooner rather than later is still > worth doing. Hi Antoine, I indeed got the change for a CentOS 6 upgrade (at least). I hope so much that the situation will become better :) (if not, as I said, it have something to do with xpra or at least a new xpra because the old version works perfectly with a newer python ob Ubuntu). Right now, I am struggling with a simple thing: # yum install xpra [...] Package xpra-0.14.11-1.el6_6.x86_64.rpm is not signed I followed http://winswitch.org/downloads/rpm-repository.html?dist_select=CentOS very closely. Can it be that the package is indeed not signed? Lukas From antoine at nagafix.co.uk Wed Nov 12 07:08:52 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 12 Nov 2014 14:08:52 +0700 Subject: [winswitch] xpra unuseable on CentOS 5 In-Reply-To: References: , <545CE4B2.9000105@nagafix.co.uk> , <545DA95E.3050209@nagafix.co.uk> <545DF7BE.10501@nagafix.co.uk>, <545DF9F6.7010304@nagafix.co.uk> Message-ID: <54630784.90805@nagafix.co.uk> On 12/11/14 12:25, Lukas Haase wrote: >>>> I think it's nearly impossible to get this machine upgraded but I may try it at least. If so, what would be the python and/or CentOS version with which everything should work? CentOS 6? >>> Sure, CentOS 6 or 7 both work well enough. >>> CentOS 6 is a bit dated already. >>> CentOS 7 is a bit annoying as a client OS because it lacks a system tray >>> in the default gnome desktop, much better as a server OS (up to date >>> python and libs). >> Just one more thing: there is no guarantee at all that upgrading your >> host OS will improve the behaviour of the application (especially the >> focus issues you describe). >> It sounds like upgrading is going to be a hassle for you, so you may be >> better off trying it out in a virtual machine before spending too much >> time down this path. >> That said, moving away from CentOS 5 sooner rather than later is still >> worth doing. > Hi Antoine, > > I indeed got the change for a CentOS 6 upgrade (at least). > I hope so much that the situation will become better :) > (if not, as I said, it have something to do with xpra or at least a new xpra because the old version works perfectly with a newer python ob Ubuntu). > > Right now, I am struggling with a simple thing: > > # yum install xpra > [...] > Package xpra-0.14.11-1.el6_6.x86_64.rpm is not signed > > I followed http://winswitch.org/downloads/rpm-repository.html?dist_select=CentOS very closely. > Can it be that the package is indeed not signed? Indeed, that was the problem. (out of hundreds of RPMs, only this one and the Fedora 20 amd64 source RPM were missing the signature!) If a simple "yum update" doesn't pick it up automagically, try the yum clean dance: yum clean all && yum update Cheers Antoine From lukashaase at gmx.at Fri Nov 14 21:20:43 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Fri, 14 Nov 2014 22:20:43 +0100 Subject: [winswitch] BUG: Mouse pointer stops working in multi-/single display setup Message-ID: Hi, I observered the following bug in the latest xpra v0.14.11 which can be reproduced in exactly the same manner: 1.) Create a session on a remote Linux server via SSH and xpra 2.) Connect with a Windows client with 2 displays (in my case: Laptop in docking station + external monitor). I do it via SSH + X forwarding and then using "xpra attach" with Cygwin SSH server. 3.) Start an application (I used "firefox" for my tests). 4.) Detatch, undock laptop, reattach session (alternatively (?): Re-attach from system with single display). Everything works as expected. Detatch again 5.) Dock laptop again (alternatively (?): Go back to the system with 2 displays): Re-attach. Now comes the problem: Mouse input only works on one display (the internal laptop display)! However, keyboard input works everywhere and I can drag and move the windows on both screens. The "Window Manager" Icons ("x" Icon in Windows etc) work as expected. However, then I drag the firefox window to the external display and I click onto it, I see that the actual click takes place and the left-most side of the display. Moving the window back to the internal laptop display makes everything work again. Re-attaching does not help. Restarting the X server at the client helped one single time but otherwise did not help. Using "xpra upgrade" on the server seems to help. system configuration: Server: CentOS 6 with official repository (xpra v0.14.11) Client: Windows 7, Cygwin SSH server, connection over SSH + Forwarding. Thinkpad on docking station; mobile: just internal display; docked: internal + external display Thanks Lukas PS: I tried to write this in a bug report directly but I cannot register ("Cannot find implementation(s) of the IAccountRegistrationInspector interface named UsernamePermCheck. Please check that the Component is enabled or update the option [account-manager] register_check in trac.ini."). From antoine at nagafix.co.uk Sat Nov 15 05:41:13 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 15 Nov 2014 12:41:13 +0700 Subject: [winswitch] BUG: Mouse pointer stops working in multi-/single display setup In-Reply-To: References: Message-ID: <5466E779.6050304@nagafix.co.uk> On 15/11/14 04:20, Lukas Haase wrote: > Hi, > > I observered the following bug in the latest xpra v0.14.11 which can be reproduced in exactly the same manner: (..) I believe you're hitting this bug which is high on my list: http://xpra.org/trac/ticket/349 Feel free to subscribe to this ticket to help and be notified of fixes. (*) > Re-attaching does not help. > Restarting the X server at the client helped one single time but otherwise did not help. Below, you're saying that your client is Windows 7. How can you restart the X server since there isn't one on MS Windows? Unless you're talking about the Cygwin X11 server - but I don't see how you would get an xpra build to use X11 on win32: xpra on MS Windows uses "native" GTK-win32. > Using "xpra upgrade" on the server seems to help. > > system configuration: > > Server: CentOS 6 with official repository (xpra v0.14.11) > Client: Windows 7, Cygwin SSH server, connection over SSH + Forwarding. I assume you mean Cygwin SSH client here? Can you paste the command line that you use for connecting? (I can't remember the last time I tried to use xpra with Cygwin's ssh instead of plink - good to know it still works) > Thinkpad on docking station; mobile: just internal display; docked: internal + external display > > > Thanks > Lukas > > > PS: I tried to write this in a bug report directly but I cannot register ("Cannot find implementation(s) of the IAccountRegistrationInspector interface named UsernamePermCheck. Please check that the Component is enabled or update the option [account-manager] register_check in trac.ini."). Sorry about that - fixed. Cheers Antoine PS: for those unlucky Trac administrators hitting landing on this message because of the obscure 1.0.2 Trac upgrade issue, here's the fix (which I could not find documented anywhere): you must ensure this is in your [components] section since the "UsernamePermCheck" is now required by default: acct_mgr.register.usernamepermcheck = enabled From lukashaase at gmx.at Tue Nov 18 19:11:02 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Tue, 18 Nov 2014 20:11:02 +0100 Subject: [winswitch] BUG: Mouse pointer stops working in multi-/single display setup In-Reply-To: <5466E779.6050304@nagafix.co.uk> References: , <5466E779.6050304@nagafix.co.uk> Message-ID: Hi Antoine, > On 15/11/14 04:20, Lukas Haase wrote: > > Hi, > > > > I observered the following bug in the latest xpra v0.14.11 which can be reproduced in exactly the same manner: > (..) > I believe you're hitting this bug which is high on my list: > http://xpra.org/trac/ticket/349 > Feel free to subscribe to this ticket to help and be notified of fixes. (*) Indeed, this sounds very similar. I subscribed. Looking forward to a solution :) > > Re-attaching does not help. > > Restarting the X server at the client helped one single time but otherwise did not help. > Below, you're saying that your client is Windows 7. > How can you restart the X server since there isn't one on MS Windows? > Unless you're talking about the Cygwin X11 server - but I don't see how > you would get an xpra build to use X11 on win32: xpra on MS Windows uses > "native" GTK-win32. Yes, I am talking about the Cygwin X11 Server. I.e., I just exit the server and restart the exe. I don't use xpra natively on Windows. Here is what I do: 1.) On the server, in a screen session "xpra start", followed by "DISPLAY=:123 myapp" 2.) Using PuTTY/plink.exe, I connect to the same server and call "xpra attach" I hope there is nothing wrong about it because I like the way it works: Just as ordinary X forwarding but better ;-) I tried winswitch and some point but did not get it working and I found no good docu on it, so I sticked with this. But I didn't look to deep into it. > > Using "xpra upgrade" on the server seems to help. > > > > system configuration: > > > > Server: CentOS 6 with official repository (xpra v0.14.11) > > Client: Windows 7, Cygwin SSH server, connection over SSH + Forwarding. > I assume you mean Cygwin SSH client here? I am actually using Putty/plink.exe with X forwarding. > Can you paste the command line that you use for connecting? (I can't > remember the last time I tried to use xpra with Cygwin's ssh instead of > plink - good to know it still works) I just use (this is in my connect.cmd): plink.exe -X -load "my-remote-server" "~/xpra_client.sh" where my-remote-server is just a stored PuTTY session. xpra_client.sh on the server just contains: xpra attach :1984 --no-keyboard-sync --encoding=rgb Regards, Lukas From antoine at nagafix.co.uk Tue Nov 18 21:09:21 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 18 Nov 2014 15:09:21 -0600 Subject: [winswitch] BUG: Mouse pointer stops working in multi-/single display setup In-Reply-To: References: , <5466E779.6050304@nagafix.co.uk> Message-ID: <546BB581.3040201@nagafix.co.uk> (snip) >>> Server: CentOS 6 with official repository (xpra v0.14.11) >>> Client: Windows 7, Cygwin SSH server, connection over SSH + Forwarding. >> I assume you mean Cygwin SSH client here? > I am actually using Putty/plink.exe with X forwarding. Oh dear. >> Can you paste the command line that you use for connecting? (I can't >> remember the last time I tried to use xpra with Cygwin's ssh instead of >> plink - good to know it still works) > I just use (this is in my connect.cmd): > > plink.exe -X -load "my-remote-server" "~/xpra_client.sh" > > where my-remote-server is just a stored PuTTY session. > > xpra_client.sh on the server just contains: > > xpra attach :1984 --no-keyboard-sync --encoding=rgb Why bother with an X11 server on Windows when you can just use the native client instead? That's bizarre. You're getting the "screen for X11" part of xpra, but you're missing out on a number of important features. Antoine From lukashaase at gmx.at Wed Nov 19 07:30:53 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Wed, 19 Nov 2014 08:30:53 +0100 Subject: [winswitch] Windiws client usage (was: Re: BUG: Mouse pointer stops working in multi-/single display setup) In-Reply-To: <546BB581.3040201@nagafix.co.uk> References: , <5466E779.6050304@nagafix.co.uk> , <546BB581.3040201@nagafix.co.uk> Message-ID: Hi Antoine, > [...] > (snip) > >>> Server: CentOS 6 with official repository (xpra v0.14.11) > >>> Client: Windows 7, Cygwin SSH server, connection over SSH + Forwarding. > >> I assume you mean Cygwin SSH client here? > > I am actually using Putty/plink.exe with X forwarding. > Oh dear. > >> Can you paste the command line that you use for connecting? (I can't > >> remember the last time I tried to use xpra with Cygwin's ssh instead of > >> plink - good to know it still works) > > I just use (this is in my connect.cmd): > > > > plink.exe -X -load "my-remote-server" "~/xpra_client.sh" > > > > where my-remote-server is just a stored PuTTY session. > > > > xpra_client.sh on the server just contains: > > > > xpra attach :1984 --no-keyboard-sync --encoding=rgb > Why bother with an X11 server on Windows when you can just use the > native client instead? That's bizarre. Well, the reason was three-fold: 1.) In the beginning I used X fowarding extensively and had the cygwin X-server installed anways. All that I needed was persistance. Not needing to install any application on client is what I regarded as great advantage. 2.) I started using xpra on a server machine where I had no root access ... and installed xpra with some python modules into the home directory so the setup was pretty weird. I could not get the (winswitch) client working with it. It did not have much documentation or debug output so I just gave up (too quickly!) ... and just used X forwarding. 3.) I used GSSAPI authentication first and needed to pass certain options to plink. I didn't see how this works with winswitch/xpra. (Is it possible? Particularly, supplying a session name or SSH public key would be interesting) But I took the opportunity now to give it one more try: Yay, it works now, great! And I am happy to not have a DOS box with plink running any more. :-) :-) Client looks great! The docu is unfortunately still missing ;-) (or I don't find it). I found that I can save my settings in a *.xpra file. Nice! * But even when I select "Raw RGB + zlib..." the client starts off with H.264. I need to change to RGB manually. Is this a bug? * When I select "Disconnect", the app terminates but the tray icon stays there until I hover over it. Usually this is a sign that something crashes and Shell_NotifyIcon is not called properly. Is this a bug? * When I double click the *.xpra file, the launcher opens. Is it possible to connect automatically? Similarly, is the xpra file format documented some where? The command line arguments? > You're getting the "screen for X11" part of xpra, but you're missing out > on a number of important features. Out of curiosity: Which features/advantages does the native client have against the "xpra attach + X forwarding + cygwin X11 server" solution? BTW, just a suggestion (I am sure it is not easily possible): I just started to create different virtual desktops per application - so I can access them on needed basis. It would be great if one tray icon would handle all current connections and you could supply a name for it (instead of one tray icon/X server per connection and title "username at server:3454". Regards Lukas From totaam at gmail.com Thu Nov 20 19:50:33 2014 From: totaam at gmail.com (Antoine Martin) Date: Thu, 20 Nov 2014 11:50:33 -0800 Subject: [winswitch] Windiws client usage (was: Re: BUG: Mouse pointer stops working in multi-/single display setup) In-Reply-To: References: <5466E779.6050304@nagafix.co.uk> <546BB581.3040201@nagafix.co.uk> Message-ID: > I used GSSAPI authentication first and needed to pass certain options to plink. I didn't see how this works with winswitch/xpra. (Is it possible? Particularly, supplying a session name or SSH public key would be interesting) I am not at all sure how well this works with plink and command line arguments, but this is what the "--ssh=" flag is for. > I found that I can save my settings in a *.xpra file. Nice! Another little known feature, probably because of the lack of documentation is xpra URL launch support: xpra://[mode:]host:port/?param1=value1¶m2=value2 ie: xpra attach "xpra://tcp:localhost:10000/?encoding=png&mmap=false" > But even when I select "Raw RGB + zlib..." the client starts off with H.264. I need to change to RGB manually. Is this a bug? How do you select it? Setting "--encoding=rgb" should always work. That would be a bug. > When I select "Disconnect", the app terminates but the tray icon stays there until I hover over it. Usually this is a sign that something crashes and Shell_NotifyIcon is not called properly. Is this a bug? Sounds like it :( > When I double click the *.xpra file, the launcher opens. Is it possible to connect automatically? Yes, just add: autoconnect=True > Similarly, is the xpra file format documented some where? The file can contain the exact same option as the xpra.conf file which are the same as the command line arguments. > The command line arguments? Yes, try: "xpra --help" (or "xpra_cmd.exe --help" on win32). There is also "man xpra", and on win32 and osx version 0.15 will include the manual page in html format. > Out of curiosity: Which features/advantages does the native client have against the "xpra attach + X forwarding + cygwin X11 server" solution? I don't use X-forwarding with cygwin, so I can't be sure which features will be missing. But for sure: sound forwarding, the tray applet?, video compression (not necessarily useful if you have bandwidth to spare), etc - maybe look at: http://xpra.org/trac/wiki/Enhancements > BTW, just a suggestion (I am sure it is not easily possible): I just started to create different virtual desktops per application - so I can access them on needed basis. It would be great if one tray icon would handle all current connections and you could supply a name for it (instead of one tray icon/X server per connection and title "username at server:3454". It would be possible, but very very difficult to implement! Cheers Antoine On Wed, Nov 19, 2014 at 1:30 AM, Lukas Haase wrote: > Hi Antoine, > > > [...] > > (snip) > > >>> Server: CentOS 6 with official repository (xpra v0.14.11) > > >>> Client: Windows 7, Cygwin SSH server, connection over SSH + > Forwarding. > > >> I assume you mean Cygwin SSH client here? > > > I am actually using Putty/plink.exe with X forwarding. > > Oh dear. > > >> Can you paste the command line that you use for connecting? (I can't > > >> remember the last time I tried to use xpra with Cygwin's ssh instead > of > > >> plink - good to know it still works) > > > I just use (this is in my connect.cmd): > > > > > > plink.exe -X -load "my-remote-server" "~/xpra_client.sh" > > > > > > where my-remote-server is just a stored PuTTY session. > > > > > > xpra_client.sh on the server just contains: > > > > > > xpra attach :1984 --no-keyboard-sync --encoding=rgb > > Why bother with an X11 server on Windows when you can just use the > > native client instead? That's bizarre. > > Well, the reason was three-fold: > > 1.) In the beginning I used X fowarding extensively and had the cygwin > X-server installed anways. All that I needed was persistance. Not needing > to install any application on client is what I regarded as great advantage. > > 2.) I started using xpra on a server machine where I had no root access > ... and installed xpra with some python modules into the home directory so > the setup was pretty weird. I could not get the (winswitch) client working > with it. It did not have much documentation or debug output so I just gave > up (too quickly!) ... and just used X forwarding. > > 3.) I used GSSAPI authentication first and needed to pass certain options > to plink. I didn't see how this works with winswitch/xpra. (Is it possible? > Particularly, supplying a session name or SSH public key would be > interesting) > > But I took the opportunity now to give it one more try: Yay, it works now, > great! > And I am happy to not have a DOS box with plink running any more. :-) :-) > Client looks great! > The docu is unfortunately still missing ;-) (or I don't find it). > > I found that I can save my settings in a *.xpra file. Nice! > > * But even when I select "Raw RGB + zlib..." the client starts off with > H.264. I need to change to RGB manually. Is this a bug? > > * When I select "Disconnect", the app terminates but the tray icon stays > there until I hover over it. Usually this is a sign that something crashes > and Shell_NotifyIcon is not called properly. Is this a bug? > > * When I double click the *.xpra file, the launcher opens. Is it possible > to connect automatically? Similarly, is the xpra file format documented > some where? The command line arguments? > > > You're getting the "screen for X11" part of xpra, but you're missing out > > on a number of important features. > > Out of curiosity: Which features/advantages does the native client have > against the "xpra attach + X forwarding + cygwin X11 server" solution? > > BTW, just a suggestion (I am sure it is not easily possible): I just > started to create different virtual desktops per application - so I can > access them on needed basis. It would be great if one tray icon would > handle all current connections and you could supply a name for it (instead > of one tray icon/X server per connection and title "username at server:3454". > > Regards > Lukas > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Fri Nov 21 01:41:33 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 20 Nov 2014 17:41:33 -0800 Subject: [winswitch] [ANNOUNCE] xpra 0.14.12 (minor fixes) Message-ID: <546E984D.80108@nagafix.co.uk> Hi, This minor update fixes a few minor issues. There is no urgency to update if you were not affected. The OpenGL crashes have been finally figured out: they only occurred when using the beta versions (as found in the Fedora 20 repositories) instead of the more up to date version we package in our repositories. The code will now detect those broken versions (if you really insist on using them) and degrade well in those cases. We have also re-enabled zero copy opengl uploads. Some RPM dependencies have been added to ensure that you will get the best performance our of the box when using those packages (adding lz4 and pillow) Release notes: * fix PyOpenGL related crashes when "accelerate" module is missing * fix error with automatic display selection and use-display switch * fix csc modules error with missing but very rarely used function * re-enable zero copy OpenGL pixel uploads when safe to do so * add Python lz4 and PIL (or pillow) as dependencies for RPMs * more accurate cursor shape transforms on MS Windows 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 antoine at nagafix.co.uk Fri Nov 21 03:04:14 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 20 Nov 2014 19:04:14 -0800 Subject: [winswitch] NVENC developer key? In-Reply-To: <539E78A8.5080101@nagafix.co.uk> References: <5334EEAB.7090000@nagafix.co.uk> <5394744B.4090802@nagafix.co.uk> <539E78A8.5080101@nagafix.co.uk> Message-ID: <546EABAE.8070101@nagafix.co.uk> Good news everyone, It seems that the beta drivers 346.16 do not require *any* license keys at all to run (at least on the "GTX 750Ti"s I have tested on). So, anyone with a sufficiently recent Nvidia card can now enjoy hardware accelerated encoding, giving you very low latency + high framerate. The not so good news: I have found a serious bug in xpra with NVENC, and so you should really avoid using this module with Xpra 0.14 unless you *never* resize any of your windows... It is also quite difficult to deploy in 0.14 as you need to full CUDA SDK at runtime. I strongly recommend using the upcoming 0.15 release instead which has much improved NVENC support, including SDKv4 support. Cheers Antoine On 15/06/14 21:55, Antoine Martin wrote: >> Quick update on this: NVidia's contempt for Linux users continues unabated. >> The latest Linux drivers still require a license key to function with >> consumer cards, not only that but they have also changed those keys >> during the stable updates to their drivers: the latest 331 and 334 >> drivers now require different keys than they did before. >> With the 337 branch it is even worse: the newer keys are accepted, but >> the API has changed and so the codec needs to be rebuilt against the >> newer API headers, which have not been released yet.. So this one is a >> complete no go at present. >> It also means that the nvenc codec in xpra is actually tied to specific >> versions of the drivers, which is another system maintenance headache. > Slight correction: > * it is the 340 branch that breaks the API and looks like it will need a > new SDK > * the 337 branch does run, but breaks the YUV444 mode, so we now disable > support for it when this driver version is detected. > I have summarized this nvidia driver mess here: > http://xpra.org/trac/ticket/595#comment:1 > > Antoine >> >> Start of rant: >> "Proprietary Tyrants" >> http://www.gnu.org/philosophy/proprietary-tyrants.html >> " A/tyrant/device is one that refuses to allow users to install a >> different operating system or a modified operating system. These devices >> have measures to block execution of anything other than the ?approved? >> system versions. We also refer to this practice as/tivoization/." >> >> "Proprietary Sabotage" >> http://www.gnu.org/philosophy/proprietary-sabotage.html >> >> "Every nonfree program has a lord, a master--and if you use the program, >> he is your master." - RMS >> End of rant. >> >> Cheers >> Antoine From offonoffoffonoff at gmail.com Fri Nov 21 03:45:28 2014 From: offonoffoffonoff at gmail.com (...) Date: Thu, 20 Nov 2014 21:45:28 -0600 Subject: [winswitch] NVENC developer key? In-Reply-To: <546EABAE.8070101@nagafix.co.uk> References: <5334EEAB.7090000@nagafix.co.uk> <5394744B.4090802@nagafix.co.uk> <539E78A8.5080101@nagafix.co.uk> <546EABAE.8070101@nagafix.co.uk> Message-ID: Sweet! But you think/know that this won't work on a gtx 670 because it's too old? On Nov 20, 2014 9:04 PM, "Antoine Martin" wrote: > Good news everyone, > > It seems that the beta drivers 346.16 do not require *any* license keys > at all to run (at least on the "GTX 750Ti"s I have tested on). > So, anyone with a sufficiently recent Nvidia card can now enjoy hardware > accelerated encoding, giving you very low latency + high framerate. > The not so good news: I have found a serious bug in xpra with NVENC, and > so you should really avoid using this module with Xpra 0.14 unless you > *never* resize any of your windows... It is also quite difficult to > deploy in 0.14 as you need to full CUDA SDK at runtime. > I strongly recommend using the upcoming 0.15 release instead which has > much improved NVENC support, including SDKv4 support. > > Cheers > Antoine > > > > On 15/06/14 21:55, Antoine Martin wrote: > >> Quick update on this: NVidia's contempt for Linux users continues > unabated. > >> The latest Linux drivers still require a license key to function with > >> consumer cards, not only that but they have also changed those keys > >> during the stable updates to their drivers: the latest 331 and 334 > >> drivers now require different keys than they did before. > >> With the 337 branch it is even worse: the newer keys are accepted, but > >> the API has changed and so the codec needs to be rebuilt against the > >> newer API headers, which have not been released yet.. So this one is a > >> complete no go at present. > >> It also means that the nvenc codec in xpra is actually tied to specific > >> versions of the drivers, which is another system maintenance headache. > > Slight correction: > > * it is the 340 branch that breaks the API and looks like it will need a > > new SDK > > * the 337 branch does run, but breaks the YUV444 mode, so we now disable > > support for it when this driver version is detected. > > I have summarized this nvidia driver mess here: > > http://xpra.org/trac/ticket/595#comment:1 > > > > Antoine > >> > >> Start of rant: > >> "Proprietary Tyrants" > >> http://www.gnu.org/philosophy/proprietary-tyrants.html > >> " A/tyrant/device is one that refuses to allow users to install a > >> different operating system or a modified operating system. These devices > >> have measures to block execution of anything other than the ?approved? > >> system versions. We also refer to this practice as/tivoization/." > >> > >> "Proprietary Sabotage" > >> http://www.gnu.org/philosophy/proprietary-sabotage.html > >> > >> "Every nonfree program has a lord, a master--and if you use the program, > >> he is your master." - RMS > >> End of rant. > >> > >> 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 Fri Nov 21 05:11:26 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 20 Nov 2014 21:11:26 -0800 Subject: [winswitch] NVENC developer key? In-Reply-To: References: <5334EEAB.7090000@nagafix.co.uk> <5394744B.4090802@nagafix.co.uk> <539E78A8.5080101@nagafix.co.uk> <546EABAE.8070101@nagafix.co.uk> Message-ID: <546EC97E.7010809@nagafix.co.uk> On 20/11/14 19:45, ... wrote: > Sweet! But you think/know that this won't work on a gtx 670 because it's > too old? I believe it should work with a GTX 670. One sure way to find out is to try the beta repository, which has fresh 0.15 packages (RPMs for Fedora and CentOS have just been pushed, DEBs for Ubuntu and Debian will be pushed tomorrow). All you need to install, apart from xpra 0.15.0, is "python-pycuda" (which is also in the RPM repositories and is available from Debian "contrib"). If you do, please share the results. Running "xpra/codecs/loader.py -v" should show "nvenc3" and/or "nvenc4" as available codecs. Cheers Antoine > On Nov 20, 2014 9:04 PM, "Antoine Martin" wrote: > >> Good news everyone, >> >> It seems that the beta drivers 346.16 do not require *any* license keys >> at all to run (at least on the "GTX 750Ti"s I have tested on). >> So, anyone with a sufficiently recent Nvidia card can now enjoy hardware >> accelerated encoding, giving you very low latency + high framerate. >> The not so good news: I have found a serious bug in xpra with NVENC, and >> so you should really avoid using this module with Xpra 0.14 unless you >> *never* resize any of your windows... It is also quite difficult to >> deploy in 0.14 as you need to full CUDA SDK at runtime. >> I strongly recommend using the upcoming 0.15 release instead which has >> much improved NVENC support, including SDKv4 support. >> >> Cheers >> Antoine >> >> >> >> On 15/06/14 21:55, Antoine Martin wrote: >>>> Quick update on this: NVidia's contempt for Linux users continues >> unabated. >>>> The latest Linux drivers still require a license key to function with >>>> consumer cards, not only that but they have also changed those keys >>>> during the stable updates to their drivers: the latest 331 and 334 >>>> drivers now require different keys than they did before. >>>> With the 337 branch it is even worse: the newer keys are accepted, but >>>> the API has changed and so the codec needs to be rebuilt against the >>>> newer API headers, which have not been released yet.. So this one is a >>>> complete no go at present. >>>> It also means that the nvenc codec in xpra is actually tied to specific >>>> versions of the drivers, which is another system maintenance headache. >>> Slight correction: >>> * it is the 340 branch that breaks the API and looks like it will need a >>> new SDK >>> * the 337 branch does run, but breaks the YUV444 mode, so we now disable >>> support for it when this driver version is detected. >>> I have summarized this nvidia driver mess here: >>> http://xpra.org/trac/ticket/595#comment:1 >>> >>> Antoine >>>> Start of rant: >>>> "Proprietary Tyrants" >>>> http://www.gnu.org/philosophy/proprietary-tyrants.html >>>> " A/tyrant/device is one that refuses to allow users to install a >>>> different operating system or a modified operating system. These devices >>>> have measures to block execution of anything other than the ?approved? >>>> system versions. We also refer to this practice as/tivoization/." >>>> >>>> "Proprietary Sabotage" >>>> http://www.gnu.org/philosophy/proprietary-sabotage.html >>>> >>>> "Every nonfree program has a lord, a master--and if you use the program, >>>> he is your master." - RMS >>>> End of rant. >>>> >>>> Cheers >>>> Antoine >> >> _______________________________________________ >> 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 offonoffoffonoff at gmail.com Fri Nov 21 08:02:28 2014 From: offonoffoffonoff at gmail.com (...) Date: Fri, 21 Nov 2014 02:02:28 -0600 Subject: [winswitch] NVENC developer key? In-Reply-To: <546EC97E.7010809@nagafix.co.uk> References: <5334EEAB.7090000@nagafix.co.uk> <5394744B.4090802@nagafix.co.uk> <539E78A8.5080101@nagafix.co.uk> <546EABAE.8070101@nagafix.co.uk> <546EC97E.7010809@nagafix.co.uk> Message-ID: Will do. Maybe this weekend or over thangiving. Out of curiosity, why is cuda needed? Isn't NVENC unrelated to cuda? On Nov 20, 2014 11:11 PM, "Antoine Martin" wrote: > > On 20/11/14 19:45, ... wrote: > > Sweet! But you think/know that this won't work on a gtx 670 because it's > > too old? > I believe it should work with a GTX 670. > > One sure way to find out is to try the beta repository, which has fresh > 0.15 packages (RPMs for Fedora and CentOS have just been pushed, DEBs > for Ubuntu and Debian will be pushed tomorrow). > All you need to install, apart from xpra 0.15.0, is "python-pycuda" > (which is also in the RPM repositories and is available from Debian > "contrib"). > If you do, please share the results. Running "xpra/codecs/loader.py -v" > should show "nvenc3" and/or "nvenc4" as available codecs. > > Cheers > Antoine From antoine at nagafix.co.uk Fri Nov 21 16:32:07 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 21 Nov 2014 08:32:07 -0800 Subject: [winswitch] NVENC developer key? In-Reply-To: References: <5334EEAB.7090000@nagafix.co.uk> <5394744B.4090802@nagafix.co.uk> <539E78A8.5080101@nagafix.co.uk> <546EABAE.8070101@nagafix.co.uk> <546EC97E.7010809@nagafix.co.uk> Message-ID: <546F6907.10207@nagafix.co.uk> On 21/11/14 00:02, ... wrote: > > Will do. Maybe this weekend or over thangiving. Out of curiosity, > why is cuda needed? Isn't NVENC unrelated to > It is used to talk to the encoding device: NVENC uses DirectX on MS Windows and CUDA on Linux. In our case, we also use a CUDA kernel to convert the pixel data in BGRX format to the encoder's input format (NV12). Antoine > On Nov 20, 2014 11:11 PM, "Antoine Martin" > wrote: > > > > On 20/11/14 19:45, ... wrote: > > > Sweet! But you think/know that this won't work on a gtx 670 > because it's > > > too old? > > I believe it should work with a GTX 670. > > > > One sure way to find out is to try the beta repository, which has fresh > > 0.15 packages (RPMs for Fedora and CentOS have just been pushed, DEBs > > for Ubuntu and Debian will be pushed tomorrow). > > All you need to install, apart from xpra 0.15.0, is "python-pycuda" > > (which is also in the RPM repositories and is available from Debian > > "contrib"). > > If you do, please share the results. Running "xpra/codecs/loader.py -v" > > should show "nvenc3" and/or "nvenc4" as available codecs. > > > > Cheers > > Antoine > From lukashaase at gmx.at Wed Nov 26 10:40:04 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Wed, 26 Nov 2014 11:40:04 +0100 Subject: [winswitch] Windiws client usage (was: Re: BUG: Mouse pointer stops working in multi-/single display setup) In-Reply-To: References: <5466E779.6050304@nagafix.co.uk> <546BB581.3040201@nagafix.co.uk> , Message-ID: Hi Antoine, >> [...] >>?I used GSSAPI authentication first and needed to pass certain options to plink. I didn't see how this works with >> winswitch/xpra. (Is it possible? Particularly, supplying a session name or SSH public key would be interesting) > I am not at all sure how well this works with plink and command line arguments, but this is what the "--ssh=" flag is for. > [...] I played around with this; indeed, the *.xpra file accepts a ssh= line. However, it seems to me that arguments are parsed improperly. When I use ssh_port=22 mode=ssh ssh="plink.exe -noagent -i o:\pkey.ppk" I get: Error running ssh program '[plink.exe -noagent -i o:\pkey.ppk', '-l', 'lukas', '-ssh'.... [Error 2] The system cannot find the file specified It seems that in this case, the complete command is interpreted as executeable which can of course indeed not be found. When I use (without quotes) ssh_port=22 mode=ssh ssh=plink.exe -noagent -i o:\pkey.ppk then the appended arguments seem to be dropped; in any case they are ignored. Independently from that, I see that xpra itself supplies "-agent" to plinks argument list. This might not be always wanted, for example in my case. Therefore I would suggest to add a "ssh_args" option if it can be easily implemented. If this is not set, do whatever is done now (with "ssh" executeable). If this is set, these arguments are passed to "ssh", along with "-l username" and the command to be executed but otherwise no "default" arguments such as "-agent". This method would also allow to pass "-load mysession" and hence GSSAPI authentication would work :-) Regards, Lukas From lukashaase at gmx.at Wed Nov 26 10:53:29 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Wed, 26 Nov 2014 11:53:29 +0100 Subject: [winswitch] Windiws client usage (was: Re: BUG: Mouse pointer stops working in multi-/single display setup) In-Reply-To: References: <5466E779.6050304@nagafix.co.uk> <546BB581.3040201@nagafix.co.uk> , , Message-ID: Sorry, I need to add something ... > Hi Antoine, > > >> [...] > >>?I used GSSAPI authentication first and needed to pass certain options to plink. I didn't see how this works with > >> winswitch/xpra. (Is it possible? Particularly, supplying a session name or SSH public key would be interesting) > > I am not at all sure how well this works with plink and command line arguments, but this is what the "--ssh=" flag is for. > > [...] > > I played around with this; indeed, the *.xpra file accepts a ssh= line. > > However, it seems to me that arguments are parsed improperly. > > When I use > > ssh_port=22 > mode=ssh > ssh="plink.exe -noagent -i o:\pkey.ppk" > > I get: > > Error running ssh program '[plink.exe -noagent -i o:\pkey.ppk', '-l', 'lukas', '-ssh'.... > [Error 2] The system cannot find the file specified > > It seems that in this case, the complete command is interpreted as executeable which can of course indeed not be found. > > When I use (without quotes) > > ssh_port=22 > mode=ssh > ssh=plink.exe -noagent -i o:\pkey.ppk > > then the appended arguments seem to be dropped; in any case they are ignored. > > > Independently from that, I see that xpra itself supplies "-agent" to plinks argument list. This might not be always wanted, for example in my case. > Therefore I would suggest to add a "ssh_args" option if it can be easily implemented. > If this is not set, do whatever is done now (with "ssh" executeable). > If this is set, these arguments are passed to "ssh", along with "-l username" and the command to be executed but otherwise no "default" arguments such as "-agent". > > This method would also allow to pass "-load mysession" and hence GSSAPI authentication would work :-) Actually it seems that the command is parsed correctly but exactly what is done above is the problem - I pass "-noagent -i file" and xpra additionally passes "-agent". Therefore the agent is queried although I explicitely supply "noagent". The reason is that this might indeed not be always wanted. In my case, I use a "special" agent which is most of the time locked and I get a password dialog on a key request. In case of xpra, it just hangs until I enter the master password. I use this agent for conventional SSH login systems. However, when SSH is used for automated things (scripts or xpra in this case) the agent should not be queried but an explicit SSH key is supplied. The proposal with "ssh_arg" would fix scenarios like these. Regards, Lukas From antoine at nagafix.co.uk Wed Nov 26 18:56:42 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 Nov 2014 10:56:42 -0800 Subject: [winswitch] Windiws client usage In-Reply-To: References: <5466E779.6050304@nagafix.co.uk> <546BB581.3040201@nagafix.co.uk> , Message-ID: <5476226A.2080404@nagafix.co.uk> On 26/11/14 02:40, Lukas Haase wrote: > Hi Antoine, > >>> [...] >>> I used GSSAPI authentication first and needed to pass certain options to plink. I didn't see how this works with >>> winswitch/xpra. (Is it possible? Particularly, supplying a session name or SSH public key would be interesting) >> I am not at all sure how well this works with plink and command line arguments, but this is what the "--ssh=" flag is for. >> [...] > I played around with this; indeed, the *.xpra file accepts a ssh= line. > > However, it seems to me that arguments are parsed improperly. > > When I use > > ssh_port=22 > mode=ssh > ssh="plink.exe -noagent -i o:\pkey.ppk" > > I get: > > Error running ssh program '[plink.exe -noagent -i o:\pkey.ppk', '-l', 'lukas', '-ssh'.... > [Error 2] The system cannot find the file specified > > It seems that in this case, the complete command is interpreted as executeable which can of course indeed not be found. Ouch. I've just tried it on Linux and couldn't reproduce the problem. I'll try it on MS Windows next week. > When I use (without quotes) > > ssh_port=22 > mode=ssh > ssh=plink.exe -noagent -i o:\pkey.ppk > > then the appended arguments seem to be dropped; in any case they are ignored. Does sound like a real bug. I guess not many people use the ssh switch on win32, or just in ways that don't cause this issue. > Independently from that, I see that xpra itself supplies "-agent" to plinks argument list. This might not be always wanted, for example in my case. > Therefore I would suggest to add a "ssh_args" option if it can be easily implemented. > If this is not set, do whatever is done now (with "ssh" executeable). > If this is set, these arguments are passed to "ssh", along with "-l username" and the command to be executed but otherwise no "default" arguments such as "-agent". I think we can do something slightly more elegant: http://xpra.org/trac/ticket/747#ticket Feel free to subscribe and/or add comments to this ticket. > This method would also allow to pass "-load mysession" and hence GSSAPI authentication would work :-) Should work once this ticket is implemented. Cheers Antoine > > > Regards, > Lukas > > From lukashaase at gmx.at Wed Nov 26 21:19:14 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Wed, 26 Nov 2014 22:19:14 +0100 Subject: [winswitch] Windiws client usage In-Reply-To: <5476226A.2080404@nagafix.co.uk> References: <5466E779.6050304@nagafix.co.uk> <546BB581.3040201@nagafix.co.uk> , , <5476226A.2080404@nagafix.co.uk> Message-ID: > [...] > > Independently from that, I see that xpra itself supplies "-agent" to plinks argument list. This might not be always wanted, for example in my case. > > Therefore I would suggest to add a "ssh_args" option if it can be easily implemented. > > If this is not set, do whatever is done now (with "ssh" executeable). > > If this is set, these arguments are passed to "ssh", along with "-l username" and the command to be executed but otherwise no "default" arguments such as "-agent". > I think we can do something slightly more elegant: > http://xpra.org/trac/ticket/747#ticket > Feel free to subscribe and/or add comments to this ticket. > > This method would also allow to pass "-load mysession" and hence GSSAPI authentication would work :-) > Should work once this ticket is implemented. That's a really great proposal! Thanks! Subscribed Lukas From usulyre at gmail.com Thu Nov 27 04:25:24 2014 From: usulyre at gmail.com (Reggie Wong) Date: Wed, 26 Nov 2014 20:25:24 -0800 Subject: [winswitch] s xpra/winswitch like a remote desktop program? Message-ID: Hi, I've just found xpra/winswitch, i wanted to know if i can use it like a remote desktop program, where i have a windows pc and access it from an android device, is this possible? How well is the android apk developed? From offonoffoffonoff at gmail.com Thu Nov 27 06:14:08 2014 From: offonoffoffonoff at gmail.com (...) Date: Thu, 27 Nov 2014 00:14:08 -0600 Subject: [winswitch] s xpra/winswitch like a remote desktop program? In-Reply-To: References: Message-ID: My information may be old. Xpra is not for whole desktops. It is for the windows generated by programs. You can call up a program remotely, not the whole dektop. There is no windows server. You can view linux programs on windows but not the other way. There is no android client AFAIK, though it was a potential goole summer of code project so maybe something happened. You're probably looking for a VNC like turbo VNC. There's open source VNC out there, but I don't know their android support. Elliot From antoine at nagafix.co.uk Thu Nov 27 06:19:30 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 Nov 2014 22:19:30 -0800 Subject: [winswitch] s xpra/winswitch like a remote desktop program? In-Reply-To: References: Message-ID: <5476C272.7050305@nagafix.co.uk> Err, On 26/11/14 22:14, ... wrote: > My information may be old. > > Xpra is not for whole desktops. It is for the windows generated by > programs. You can call up a program remotely, not the whole dektop. Not correct: you can use Xephy or Xnest to do whole desktops. There is also shadow mode which does whole desktops. > There is no windows server. You can view linux programs on windows but not > the other way. Shadow server runs on windows too. > There is no android client AFAIK, though it was a potential goole summer of > code project so maybe something happened. There is a PoC android client, which used to work - not been tested in a long time though. Antoine > You're probably looking for a VNC like turbo VNC. There's open source VNC > out there, but I don't know their android support. > > Elliot > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From blade.eric at gmail.com Fri Nov 28 01:41:02 2014 From: blade.eric at gmail.com (Eric Blade) Date: Thu, 27 Nov 2014 20:41:02 -0500 Subject: [winswitch] s xpra/winswitch like a remote desktop program? In-Reply-To: <5476C272.7050305@nagafix.co.uk> References: <5476C272.7050305@nagafix.co.uk> Message-ID: I know that it was possible quite some time ago to load the Android apk and actually view a window on a remote machine, but I couldn't figure out how to get it to interact, or switch windows or anything. On Thu, Nov 27, 2014 at 1:19 AM, Antoine Martin wrote: > Err, > > On 26/11/14 22:14, ... wrote: > > My information may be old. > > > > Xpra is not for whole desktops. It is for the windows generated by > > programs. You can call up a program remotely, not the whole dektop. > Not correct: you can use Xephy or Xnest to do whole desktops. > There is also shadow mode which does whole desktops. > > There is no windows server. You can view linux programs on windows but > not > > the other way. > Shadow server runs on windows too. > > There is no android client AFAIK, though it was a potential goole summer > of > > code project so maybe something happened. > There is a PoC android client, which used to work - not been tested in a > long time though. > > Antoine > > You're probably looking for a VNC like turbo VNC. There's open source > VNC > > out there, but I don't know their android support. > > > > Elliot > > _______________________________________________ > > 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 > -- Eric Blade - 707-99-BLADE http://www.ericbla.de/ When they broke open molecules, they found they were only stuffed with atoms. But when they broke open atoms, they found them stuffed with explosions. "I hate how the assembly directions for my new desk are more difficult to understand than the programming languages I use while at the desk."- Phil Miller (1:05:26 AM) thrrgilag: the quality of code should be measured in 'wtf' units From lukashaase at gmx.at Sun Nov 30 06:20:44 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Sun, 30 Nov 2014 07:20:44 +0100 Subject: [winswitch] "Simultanuous" start/upgrade Message-ID: Hi, Unfortunately xpra is not so stable for me :-( - in two ways: 1.) Sometimes something on the client goes wrong and manually doing "xpra upgrade" helps 2.) Often xpra on the server crashes but leaving the X-server intact s "xpra upgrade" is possible. My plan is to create a script that I run within screen and does the following: 1.) Starting xpra with a certain child. If the session already exists, upgrade 2.) Only if the child exits, the script should exit 3.) Otherwise (e.g., xpra crashes), xpra upgrade should run in a loop. Would xpra provide "xpra upgrade-or-start :1111" this would be cheesy :-) Other than that I am asking myself what is the best way to achieve it otherwise. My current idea is: xpra start :1111 --no-daemon --session-name=MATLAB --no-mdns --start-child="/opt/matlab/bin/matlab -desktop" --exit-with-children if [ $? -eq 0 ] then echo "xpra exited with status 0. Exiting ..." exit 0 fi while true do echo xpra died, doing upgrade ... xpra upgrade :1111 --no-daemon --session-name=MATLAB --no-mdns --start-child="/opt/matlab/bin/matlab -desktop" --exit-with-children if [ $? -eq 0 ] then echo "xpra exited with status 0. Exiting ..." exit 0 fi echo "xpra exited with nonzero status, re-running the loop ..." sleep 3 done Can I be sure that xpra returns 0 only if the child exited and nonzero otherwise (=crash, unexpected exit, ...)? Is it better/more stable to query a session with something like "xpra list | grep :1111" and the do either start or upgrade? How do I best implement the behavior that the script upgrades if it is ran twice and continues the loop but starts if it not? Thanks for creative suggestions Lukas From antoine at nagafix.co.uk Sun Nov 30 07:30:37 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 29 Nov 2014 23:30:37 -0800 Subject: [winswitch] "Simultanuous" start/upgrade In-Reply-To: References: Message-ID: <547AC79D.9000602@nagafix.co.uk> On 29/11/14 22:20, Lukas Haase wrote: > Hi, > > Unfortunately xpra is not so stable for me :-( - in two ways: > 1.) Sometimes something on the client goes wrong and manually doing "xpra upgrade" helps > 2.) Often xpra on the server crashes but leaving the X-server intact s "xpra upgrade" is possible. If you report those, then we can fix them. Since we're not aware of crashes, I suspect it may well be platform or configuration specific problem you're hitting. There is only one known issue in 0.14.x that can cause crashes, and disabling sound and/or clipboard avoids it. Client-side issues are usually opengl, sound or clipboard related - which can be worked around. > My plan is to create a script that I run within screen and does the following: > 1.) Starting xpra with a certain child. If the session already exists, upgrade > 2.) Only if the child exits, the script should exit > 3.) Otherwise (e.g., xpra crashes), xpra upgrade should run in a loop. > > Would xpra provide "xpra upgrade-or-start :1111" this would be cheesy :-) We don't normally do band aids, but this feature could be useful on its own. > Other than that I am asking myself what is the best way to achieve it otherwise. My current idea is: > > xpra start :1111 --no-daemon --session-name=MATLAB --no-mdns --start-child="/opt/matlab/bin/matlab -desktop" --exit-with-children > if [ $? -eq 0 ] > then > echo "xpra exited with status 0. Exiting ..." > exit 0 > fi > > > while true > do > echo xpra died, doing upgrade ... > > xpra upgrade :1111 --no-daemon --session-name=MATLAB --no-mdns --start-child="/opt/matlab/bin/matlab -desktop" --exit-with-children > if [ $? -eq 0 ] > then > echo "xpra exited with status 0. Exiting ..." > exit 0 > fi > > echo "xpra exited with nonzero status, re-running the loop ..." > sleep 3 > done Implementing upgrade-or-start is probably easier than that, and more importantly, reliable. > Can I be sure that xpra returns 0 only if the child exited and nonzero otherwise (=crash, unexpected exit, ...)? Yes. There is a ticket for that. > Is it better/more stable to query a session with something like "xpra list | grep :1111" and the do either start or upgrade? > How do I best implement the behavior that the script upgrades if it is ran twice and continues the loop but starts if it not? If you really want to script it, you can just use: xpra version :1111 And check the exit code. Cheers Antoine > > > Thanks for creative suggestions > > Lukas > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From lukashaase at gmx.at Sun Nov 30 18:40:54 2014 From: lukashaase at gmx.at (Lukas Haase) Date: Sun, 30 Nov 2014 19:40:54 +0100 Subject: [winswitch] "Simultanuous" start/upgrade In-Reply-To: <547AC79D.9000602@nagafix.co.uk> References: , <547AC79D.9000602@nagafix.co.uk> Message-ID: Hi Antoine, > On 29/11/14 22:20, Lukas Haase wrote: > > Hi, > > > > Unfortunately xpra is not so stable for me :-( - in two ways: > > 1.) Sometimes something on the client goes wrong and manually doing "xpra upgrade" helps > > 2.) Often xpra on the server crashes but leaving the X-server intact s "xpra upgrade" is possible. > If you report those, then we can fix them. Unfortunately I have no hope that this would be successful. I use proprietary, regulated, licensed software. This is an error which typically occurs: 2014-11-29 22:31:13,349 sent updated screen size to 1 clients: 3120x1050 (max 8192x4096) /usr/lib64/python2.6/site-packages/xpra/server/picture_encode.py:352: DeprecationWarning: tostring() is deprecated. Please call tobytes() instead. data = img.tostring("raw", target_format) Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/gobject_util.py", line 30, in do_get_property return getattr(self, getter)(pspec.name) File "/usr/lib64/python2.6/site-packages/xpra/x11/gtk_x11/composite.py", line 213, in do_get_property_contents_handle trap.swallow_synced(set_pixmap) File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 143, in swallow_synced self.call_synced(fun, *args, **kwargs) File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 126, in call_synced return self._call(True, fun, args, kwargs) File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 118, in _call raise e AttributeError: 'gtk.gdk.Window' object has no attribute 'get_name' Gdk-ERROR **: The program 'Xpra' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 126938 error_code 9 request_code 14 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) aborting... Abort (core dumped) I understand that these errors might be caused by "the application should not behave like this" and therefore xpra crashes. On the other hand, it works over plain X and VNC. Furthermore, neither the application, nor the X server crashes (only xpra) meaning that it's related to xpra (even if it might behave correctly in a strict sense). But I understand that xpra developers can't do anything about proprietary software. Interestingly there is a fool-proof way to reproducibly come to an error like this: If xpra is started with "--no-mdns" (which has nothing to do with the application running inside!) and one particular application is started, xpra crashes immideately with the message above (but xpra upgrade is possible afterwards). Without "--no-mdns" it works. This is at least a strong indication that xpra has to do with it. Other than that, these errors happen sporadically (3-5x/day), often after making a right-click somewhere (apparently where or when it should not be clicked) Let me know if you think differently and which information I could provide (for example, the suggested --sync option neither works for the application started, nor for xpra) > > My plan is to create a script that I run within screen and does the following: > > 1.) Starting xpra with a certain child. If the session already exists, upgrade > > 2.) Only if the child exits, the script should exit > > 3.) Otherwise (e.g., xpra crashes), xpra upgrade should run in a loop. > > > > Would xpra provide "xpra upgrade-or-start :1111" this would be cheesy :-) > We don't normally do band aids, but this feature could be useful on its own. > [...] > Implementing upgrade-or-start is probably easier than that, and more > importantly, reliable. :-) Does it mean I can file a feature request for it? > [...] > > Is it better/more stable to query a session with something like "xpra list | grep :1111" and the do either start or upgrade? > > How do I best implement the behavior that the script upgrades if it is ran twice and continues the loop but starts if it not? > If you really want to script it, you can just use: > xpra version :1111 > And check the exit code. But how do I distinguish between "crashed/upgradeable" and "not running at all"? xpra successfully running: $ xpra version :1111; echo $? 0.14.12 0 xpra not running at all: $ xpra version :1111 ; echo $? xpra initialization error: connection failed: [Errno 2] No such file or directory 1 xpra crashed but not Xserver/aplication (using the "--no-mdns" method described above): $ xpra version :1111 ; echo $? xpra initialization error: connection failed: [Errno 111] Connection refused 1 It seems that it would be distinguishable if xpra would return the Errno code. Or I could grep the stderr output which is not very elegant. Thank you Lukas From antoine at nagafix.co.uk Sun Nov 30 19:50:27 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 30 Nov 2014 11:50:27 -0800 Subject: [winswitch] "Simultanuous" start/upgrade In-Reply-To: References: , <547AC79D.9000602@nagafix.co.uk> Message-ID: <547B7503.1070101@nagafix.co.uk> On 30/11/14 10:40, Lukas Haase wrote: > Hi Antoine, > >> On 29/11/14 22:20, Lukas Haase wrote: >>> Hi, >>> >>> Unfortunately xpra is not so stable for me :-( - in two ways: >>> 1.) Sometimes something on the client goes wrong and manually doing "xpra upgrade" helps >>> 2.) Often xpra on the server crashes but leaving the X-server intact s "xpra upgrade" is possible. >> If you report those, then we can fix them. > Unfortunately I have no hope that this would be successful. > I use proprietary, regulated, licensed software. > > This is an error which typically occurs: > > 2014-11-29 22:31:13,349 sent updated screen size to 1 clients: 3120x1050 (max 8192x4096) > /usr/lib64/python2.6/site-packages/xpra/server/picture_encode.py:352: DeprecationWarning: tostring() is deprecated. Please call tobytes() instead. > data = img.tostring("raw", target_format) > Traceback (most recent call last): > File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/gobject_util.py", line 30, in do_get_property > return getattr(self, getter)(pspec.name) > File "/usr/lib64/python2.6/site-packages/xpra/x11/gtk_x11/composite.py", line 213, in do_get_property_contents_handle > trap.swallow_synced(set_pixmap) > File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 143, in swallow_synced > self.call_synced(fun, *args, **kwargs) > File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 126, in call_synced > return self._call(True, fun, args, kwargs) > File "/usr/lib64/python2.6/site-packages/xpra/gtk_common/error.py", line 118, in _call > raise e > AttributeError: 'gtk.gdk.Window' object has no attribute 'get_name' This look like a real xpra bug. If you file a ticket, we should be able to fix it. Try triggering the error with: XPRA_SYNCHRONIZE=1 xpra ... and / or: xpra -d error ... It will print a lot of debug, which should include more details about the caller. We do have a call to trap.swallow_synced, so it should have flushed the error on the spot instead of allowing it to go through to gdk where it causes the crash. > Gdk-ERROR **: The program 'Xpra' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadDrawable (invalid Pixmap or Window parameter)'. > (Details: serial 126938 error_code 9 request_code 14 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > aborting... > Abort (core dumped) That's just the standard gdk x11 error message when it receives an error it does not expect. > I understand that these errors might be caused by "the application should not behave like this" and therefore xpra crashes. > On the other hand, it works over plain X and VNC. Furthermore, neither the application, nor the X server crashes (only xpra) meaning that it's related to xpra (even if it might behave correctly in a strict sense). Plain-X and VNC are not window managers... so they just do not have any code to run at all. Apples and oranges really. > But I understand that xpra developers can't do anything about proprietary software. Generally not, but this looks like a pure xpra bug. > Interestingly there is a fool-proof way to reproducibly come to an error like this: If xpra is started with "--no-mdns" (which has nothing to do with the application running inside!) and one particular application is started, xpra crashes immideately with the message above (but xpra upgrade is possible afterwards). Without "--no-mdns" it works. This is at least a strong indication that xpra has to do with it. That's interesting, the mdns code interacts with dbus and the main loop. Since it is reproducible, I am fairly confident we can fix this reasonably quickly. > Other than that, these errors happen sporadically (3-5x/day), often after making a right-click somewhere (apparently where or when it should not be clicked) > > Let me know if you think differently and which information I could provide (for example, the suggested --sync option neither works for the application started, nor for xpra) That's a gdk message we can't get rid of, it assumes command line arguments that don't exist.. Antoine > >>> My plan is to create a script that I run within screen and does the following: >>> 1.) Starting xpra with a certain child. If the session already exists, upgrade >>> 2.) Only if the child exits, the script should exit >>> 3.) Otherwise (e.g., xpra crashes), xpra upgrade should run in a loop. >>> >>> Would xpra provide "xpra upgrade-or-start :1111" this would be cheesy :-) >> We don't normally do band aids, but this feature could be useful on its own. >> [...] >> Implementing upgrade-or-start is probably easier than that, and more >> importantly, reliable. > :-) Does it mean I can file a feature request for it? > >> [...] >>> Is it better/more stable to query a session with something like "xpra list | grep :1111" and the do either start or upgrade? >>> How do I best implement the behavior that the script upgrades if it is ran twice and continues the loop but starts if it not? >> If you really want to script it, you can just use: >> xpra version :1111 >> And check the exit code. > But how do I distinguish between "crashed/upgradeable" and "not running at all"? > > xpra successfully running: > $ xpra version :1111; echo $? > 0.14.12 > 0 > > xpra not running at all: > $ xpra version :1111 ; echo $? > xpra initialization error: connection failed: [Errno 2] No such file or directory > 1 > > xpra crashed but not Xserver/aplication (using the "--no-mdns" method described above): > $ xpra version :1111 ; echo $? > xpra initialization error: connection failed: [Errno 111] Connection refused > 1 > > It seems that it would be distinguishable if xpra would return the Errno code. > Or I could grep the stderr output which is not very elegant. > > > > Thank you > Lukas > From antoine at nagafix.co.uk Sun Nov 30 20:53:03 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 30 Nov 2014 12:53:03 -0800 Subject: [winswitch] "Simultanuous" start/upgrade In-Reply-To: References: , <547AC79D.9000602@nagafix.co.uk> Message-ID: <547B83AF.50100@nagafix.co.uk> Replying to the second half. On 30/11/14 10:40, Lukas Haase wrote: >>> My plan is to create a script that I run within screen and does the following: >>> 1.) Starting xpra with a certain child. If the session already exists, upgrade >>> 2.) Only if the child exits, the script should exit >>> 3.) Otherwise (e.g., xpra crashes), xpra upgrade should run in a loop. >>> >>> Would xpra provide "xpra upgrade-or-start :1111" this would be cheesy :-) >> We don't normally do band aids, but this feature could be useful on its own. >> [...] >> Implementing upgrade-or-start is probably easier than that, and more >> importantly, reliable. > :-) Does it mean I can file a feature request for it? Sure. >> [...] >>> Is it better/more stable to query a session with something like "xpra list | grep :1111" and the do either start or upgrade? >>> How do I best implement the behavior that the script upgrades if it is ran twice and continues the loop but starts if it not? >> If you really want to script it, you can just use: >> xpra version :1111 >> And check the exit code. > But how do I distinguish between "crashed/upgradeable" and "not running at all"? > > xpra successfully running: > $ xpra version :1111; echo $? > 0.14.12 > 0 > > xpra not running at all: > $ xpra version :1111 ; echo $? > xpra initialization error: connection failed: [Errno 2] No such file or directory > 1 > > xpra crashed but not Xserver/aplication (using the "--no-mdns" method described above): > $ xpra version :1111 ; echo $? > xpra initialization error: connection failed: [Errno 111] Connection refused > 1 > > It seems that it would be distinguishable if xpra would return the Errno code. > Or I could grep the stderr output which is not very elegant. Not elegant, but that's all we have right now. Feel free to file a request for that one too. Antoine