From thom.jentoft at gmail.com Thu Sep 4 09:31:09 2014 From: thom.jentoft at gmail.com (Thom Jentoft) Date: Thu, 4 Sep 2014 12:31:09 +0400 Subject: [winswitch] A simple script to get started with xpra on Ubuntu Message-ID: Ok, I was trying to check if I indeed need some kind of script to run xpra, because AFAICT the last time I tried it, it just worked "out of the box", when I installed it with apt-get. Not this time. I have 64-bit server Ubuntu 14.04 LTS on the server (hosted by interserver.net) and 64-bit Ubuntu 14.04.1 LTS on the desktop On the server I'm installing xpra: su - apt-get update apt-get install sudo xpra -y exit (server is a "minimal" installation, and indeed, it doesn't have sudo installed) Then run it: xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:10000 On the client I run: $ xpra attach tcp:123.45.68.89:10000 xpra client version 0.12.3 2014-08-06 15:33:50,709 PyOpenGL warning: missing accelerate module 2014-08-06 15:33:50,709 PyOpenGL warning: missing array format handlers: numpy, numeric, vbo, vbooffset 2014-08-06 15:33:50,709 OpenGL Version: 2.1 Mesa 10.1.3 2014-08-06 15:33:51,103 detected keyboard: rules=evdev, model=pc105, layout=us 2014-08-06 15:33:51,104 desktop size is 1920x1080 with 1 screen(s): 2014-08-06 15:33:51,104 ':0.0' (508x285 mm) workarea: 1871x1056 at 49x24 2014-08-06 15:33:51,104 HDMI2 (598x336 mm) 2014-08-06 15:33:51,507 server: Linux Ubuntu 14.04 trusty, Xpra version 0.12.3 (r6075) 2014-08-06 15:33:51,519 Attached to tcp:209.159.150.151:10000 (press Control-C to detach) And nothing else ever gets displayed (no graphics window, no nothing) How do I make it work? From antoine at nagafix.co.uk Thu Sep 4 09:41:14 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 04 Sep 2014 15:41:14 +0700 Subject: [winswitch] A simple script to get started with xpra on Ubuntu In-Reply-To: References: Message-ID: <540825AA.5000408@nagafix.co.uk> > xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:10000 > > On the client I run: > > $ xpra attach tcp:123.45.68.89:10000 (...) There is a slightly simpler way if you don't mind using ssh: http://xpra.org/trac/wiki/Usage xpra start ssh:username at HOST:DISPLAY --start-child=xterm > xpra client version 0.12.3 This version is no longer supported. (though in theory, it should still work) > 2014-08-06 15:33:51,519 Attached to tcp:XXXXXXXXXX:10000 (press > Control-C to detach) (..) > And nothing else ever gets displayed (no graphics window, no nothing) Is 'xterm' even installed on the server? Is the xpra tray menu available? (if so, look at Session Info) > How do I make it work? If it's connected and not showing you any errors, it probably is working already. Cheers Antoine From antoine at nagafix.co.uk Thu Sep 4 10:18:39 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 04 Sep 2014 16:18:39 +0700 Subject: [winswitch] A simple script to get started with xpra on Ubuntu In-Reply-To: References: <540825AA.5000408@nagafix.co.uk> Message-ID: <54082E6F.7020908@nagafix.co.uk> Please always CC the mailing list. On 04/09/14 15:53, Thom Jentoft wrote: > I'll try ssh and check that xterm is installed. > > This version is no longer supported. (though in theory, it should > still work) > > But this is what ships with Ubuntu 14.04 LTS - Long Term Support, > which should in theory be good for nearly 5 years! And both client and > server are the same version, too. > What would you recommend me to do wrt. the version? Your 'Long Term Support' vendor is shipping an unsupported version with many known bugs. xpra.org has up to date packages for most distros, and unlike those vendors, we will fix bugs that are reported to us. Cheers Antoine From ntlong0210 at gmail.com Sat Sep 6 03:04:19 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Sat, 6 Sep 2014 09:04:19 +0700 Subject: [winswitch] Can't use ibus-unikey to type Vietnamese In-Reply-To: <53EB2A29.6060107@nagafix.co.uk> References: <53E98DBC.2000807@nagafix.co.uk> <53EB2A29.6060107@nagafix.co.uk> Message-ID: Hi, I'd used xpra 0.14-1 and its ok. It's fixed BadCursor error. Thanks On Wed, Aug 13, 2014 at 4:04 PM, Antoine Martin wrote: > On 13/08/14 10:32, Long Nguyen Thanh wrote: > > Hi, > Xpra server set following environment variables: > DISABLE_IMSETTINGS=true > GTK_IM_MODULE=xim > QT_IM_MODULE=xim > IMSETTINGS_MODULE=none > XMODIFIERS="" > > How to make xpra server stop doing that ? > > Please see: > http://xpra.org/trac/ticket/634#comment:1 > And follow up there if you want. > > Running the latest beta from: > http://xpra.org/beta/ > > With this option if the environment is already configured: > --input-method=keep > or with this option to set it up (as best I could guess): > --input-method=IBus > Should do what you want. > > Antoine > > > > Thanks :) > > > On Wed, Aug 13, 2014 at 8:34 AM, Long Nguyen Thanh > wrote: > >> Hi, >> @Antoine: How I can remove those code ( set environment variables) ? I >> can't find them in /etc/xpra/* or ~/.xpra/* >> >> >> On Tue, Aug 12, 2014 at 11:18 AM, Long Nguyen Thanh > > wrote: >> >>> Hi Antoine, >>> I've exported these environment variables in xterm again and it works. >>> GTK_IM_MODULE=ibus >>> QT_IM_MODULE=ibus >>> XMODIFIERS="@im=ibus" >>> >>> Thanks for your help :) >>> >>> >>> On Tue, Aug 12, 2014 at 10:45 AM, Antoine Martin >>> wrote: >>> >>>> On 12/08/14 10:18, Long Nguyen Thanh wrote: >>>> > Hi, >>>> > (Sorry if my English is not good) >>>> > I used xpra from a client and connect to my server with commands >>>> bellow: >>>> > Server: xpra start :100 --start-child=xterm --bind-tcp=0.0.0.0:10000 >>>> > Client: xpra attach tcp:192.168.0.99:10000 >>>> > >>>> > And xterm appear, then I run some commands in xterm : >>>> > 1. ibus-daemon -d (before this, I configured ibus ) >>>> > 2. run some applications: firefox, google-chrome ... and test >>>> ibus-unikey. >>>> > But I can't see a difference between enable/disable ibus. >>>> This is probably because the xpra server will set the following >>>> environment variables to try to disable all input methods: >>>> DISABLE_IMSETTINGS=true >>>> GTK_IM_MODULE=xim >>>> QT_IM_MODULE=xim >>>> IMSETTINGS_MODULE=none >>>> XMODIFIERS="" >>>> >>>> You may want to remove this code, or change those values back to what >>>> they should be (whatever that is) before starting your application. Does >>>> that help? >>>> That was done because input methods were found to interfere with >>>> keyboard input more often than not (doesn't it need dbus?), at least for >>>> western keyboard layouts that I normally use. >>>> I'll have to admit that I am a bit confused by the number of ways there >>>> are to configure those input methods in X11 / GTK / QT /.., and since I >>>> don't use or need them I prefer to have it completely disabled. >>>> Since this is probably not the right thing to do in all cases, we can >>>> improve this and at least add an option to let the user choose. >>>> I'll need a bit help in doing that though. >>>> >>>> If that does not help you, can you tell us how you configured ibus? >>>> How it is meant to work in your use case? >>>> >>>> Cheers >>>> Antoine >>>> >>>> >>>> > I tried with x2go, and it works. But I like xpra more than x2go. >>>> > >>>> > OS Client : MS Windows 7, xpra 0.14.0 >>>> > OS Server: Ubuntu 12.04, xpra 0.13.8 >>>> > >>>> > *xpra.conf at Client* >>>> > >>>> > # >>>> >> # This is the default configuration file for Xpra >>>> >> # >>>> >> # You can provide default values for most command line >>>> >> # options here. >>>> >> # Each user can also define its own options in the file >>>> >> # ~/xpra/xpra.conf which will take precedence over this file. >>>> >> # Most options can also be overriden on the xpra command line. >>>> >> # See "xpra -h" or the man page for details. >>>> >> # >>>> >> # Syntax: >>>> >> # - Options which can be turned on or off will accept >>>> >> # the following values: 1, 0, true, false, yes, no >>>> >> # - Options which can accept multiple values >>>> >> # may just be specified multiple times. >>>> >> # - You may break a long line into multiple lines >>>> >> # by ending each line with a backslash '\'. >>>> >> >>>> >> >>>> >> >>>> ################################################################################ >>>> >> # General Options >>>> >> # Enable clipboard forwarding: >>>> >> clipboard = yes >>>> >> # Enable forwarding of notifications: >>>> >> notifications = yes >>>> >> # Enable forwarding of system tray icons: >>>> >> system-tray = yes >>>> >> # Forward sound output to clients: >>>> >> speaker = yes >>>> >> # Debugging: >>>> >> #debug = >>>> >> #debug = keyboard,clipboard,tray >>>> >> # Send ping packets more regularly (every second): >>>> >> pings = no >>>> >> >>>> >> >>>> >> >>>> ################################################################################ >>>> >> # Picture Encoding >>>> >> # Encodings allowed: >>>> >> # (not all encodings may be available in your environment): >>>> >> #encodings = h264, vp8, png, png/P, png/L, webp, rgb, jpeg, h265, vp9 >>>> >> #encodings = all >>>> >> #encodings = rgb >>>> >> encodings = all >>>> >> # Default encoding >>>> >> # (not all encodings may be available in your environment): >>>> >> #encoding = h264 >>>> >> #encoding = vp8 >>>> >> #encoding = png >>>> >> #encoding = jpeg >>>> >> #encoding = rgb >>>> >> #encoding = webp >>>> >> # Used by the server to encode video: >>>> >> # video-encoders = x264, vpx, nvenc >>>> >> # video-encoders = none >>>> >> # video-encoders = all >>>> >> video-encoders = all >>>> >> # Used by both the client and server for colourspace conversion: >>>> >> # csc-modules = swscale, cython, opencl >>>> >> # csc-modules = none >>>> >> # csc-modules = all >>>> >> video-encoders = all >>>> >> # Used the client for decoding: >>>> >> # video-decoders = avcodec2, vpx >>>> >> # video-decoders = avcodec, vpx >>>> >> # video-decoders = none >>>> >> # video-decoders = all >>>> >> video-decoders = all >>>> >> # Use fixed quality >>>> >> # (value is a percentage or "auto"): >>>> >> #quality = 80 >>>> >> quality = auto >>>> >> # For auto quality only: >>>> >> #min-quality = 50 >>>> >> min-quality = 30 >>>> >> # Use fixed speed >>>> >> # (value is a percentage or "auto"): >>>> >> #speed = 90 >>>> >> speed = auto >>>> >> # For auto speed only: >>>> >> #min-speed = 20 >>>> >> min-speed = 0 >>>> >> # Idle delay in seconds before doing an automatic lossless refresh: >>>> >> auto-refresh-delay = 0.15 >>>> >> # Default DPI: >>>> >> dpi = 96 >>>> >> >>>> >> >>>> >> >>>> ################################################################################ >>>> >> # Sound Encoding >>>> >> # Codec(s) to use for forwarding speaker sound: >>>> >> #speaker-codec = mp3 >>>> >> #speaker-codec = flac >>>> >> #speaker-codec = wav >>>> >> #speaker-codec = wavpack >>>> >> #speaker-codec = speex >>>> >> #speaker-codec = opus >>>> >> # Forward sound input to server: >>>> >> # microphone = yes >>>> >> # Codec(s) to use for forwarding microphone sound: >>>> >> #microphone-codec = mp3 >>>> >> #microphone-codec = flac >>>> >> #microphone-codec = wav >>>> >> #microphone-codec = wavpack >>>> >> #microphone-codec = speex >>>> >> #microphone-codec = opus >>>> >> >>>> >> >>>> >> >>>> ################################################################################ >>>> >> # Network Connection >>>> >> # Enable shared memory transfers: >>>> >> mmap = yes >>>> >> # Use server group ownership for mmap file: >>>> >> mmap-group = no >>>> >> # Share session with other users: >>>> >> sharing = no >>>> >> # Compressors: >>>> >> #compressors = all >>>> >> #compressors = none >>>> >> #compressors = zlib >>>> >> compressors = lz4, zlib, lzo >>>> >> # Default compression (0 to 9): >>>> >> compression_level = 1 >>>> >> # Packet encoders (at least one is required): >>>> >> #packet-encoders = bencode >>>> >> #packet-encoders = all >>>> >> packet-encoders = rencode, bencode, yaml >>>> >> # Socket directory: >>>> >> #socket-dir = /tmp >>>> >> #socket-dir = ~/.xpra >>>> >> >>>> >> >>>> >> >>>> ################################################################################ >>>> >> # Client Options >>>> >> # OpenGL accelerated rendering: >>>> >> #opengl = yes >>>> >> #opengl = no >>>> >> opengl = auto >>>> >> # Client window title: >>>> >> title = @title@ on @client-machine@ >>>> >> # Icon used by the system tray: >>>> >> #tray-icon = /path/to/icon.png >>>> >> # Keyboard synchronization: >>>> >> keyboard-sync = yes >>>> >> # Client ssh command: >>>> >> #ssh = /usr/bin/ssh >>>> >> >>>> >> >>>> ######################################################################## >>>> >> # Server Options: >>>> >> # Commands to start by default >>>> >> # (may be specified more than once): >>>> >> # examples: >>>> >> #start-child = /usr/bin/xterm >>>> >> #start-child = /usr/bin/xeyes >>>> >> # Xsession can take care of initializing dbus, keyring-daemon, >>>> >> # gpg-agent or whatever else might be usually started together with X >>>> >> #start-child = /etc/X11/Xsession true >>>> >> # Video encoders loaded by the server >>>> >> # (all of them unless specified) >>>> >> # examples: >>>> >> #video-encoders=x264,vpx,nvenc >>>> >> #video-encoders=x264 >>>> >> # Colourspace conversion modules loaded by the server >>>> >> # (all of them unless specified) >>>> >> # examples: >>>> >> #csc-modules=swscale,cython,opencl >>>> >> #csc-modules=swscale >>>> >> # Where to send non xpra clients: >>>> >> # (can be used to share the port with a web server) >>>> >> #tcp-proxy = 127.0.0.1:80 >>>> >> # Log file: >>>> >> log-file = $DISPLAY.log >>>> >> # Publish sessions: >>>> >> mdns = yes >>>> >> # Start a pulseaudio server with each session: >>>> >> pulseaudio = yes >>>> >> # pulseaudio server start command: >>>> >> pulseaudio-command = pulseaudio --start --daemonize=false >>>> --system=false \ >>>> >> --exit-idle-time=-1 -n --load=module-suspend-on-idle >>>> \ >>>> >> --load=module-null-sink >>>> --load=module-native-protocol-unix >>>> >> \ >>>> >> --log-level=2 --log-target=stderr >>>> >> # Virtual display command: >>>> >> # - Old Xvfb option: >>>> >> # xvfb=Xvfb +extension Composite -screen 0 3840x2560x24+32 -nolisten >>>> tcp >>>> >> -noreset -auth $XAUTHORITY >>>> >> # - With Xorg 1.12 or newer and the dummy driver: >>>> >> # xvfb=/usr/bin/Xorg -dpi 96 -noreset -nolisten tcp +extension GLX >>>> >> +extension RANDR +extension RENDER -logfile >>>> >> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf >>>> >> # >>>> >> # Selecting virtual X server: >>>> >> xvfb= >>>> >> # Does the xvfb command support the "-displayfd" argument? >>>> >> displayfd = no >>>> > >>>> > *xpra.conf at Server* >>>> > >>>> > # Enable clipboard forwarding: >>>> >> clipboard = yes >>>> >> # Enable forwarding of notifications: >>>> >> notifications = yes >>>> >> # Enable forwarding of system tray icons: >>>> >> system-tray = yes >>>> >> # Start a pulseaudio server with each session: >>>> >> pulseaudio = yes >>>> >> # pulseaudio server start command: >>>> >> pulseaudio-command = pulseaudio --start --daemonize=false >>>> --system=false \ >>>> >> --exit-idle-time=-1 -n --load=module-suspend-on-idle >>>> \ >>>> >> --load=module-null-sink >>>> --load=module-native-protocol-unix >>>> >> \ >>>> >> --log-level=2 --log-target=stderr >>>> >> # Forward sound output to clients: >>>> >> speaker = yes >>>> >> # Enable shared memory transfers: >>>> >> mmap = yes >>>> >> # Use server group ownership for mmap file: >>>> >> mmap-group = no >>>> >> # Share session with other users: >>>> >> sharing = no >>>> >> # Default compression (0 to 9): >>>> >> compression_level = 1 >>>> >> # Socket directory: >>>> >> #socket-dir = /tmp >>>> >> #socket-dir = ~/.xpra >>>> >> # Where to send non xpra clients: >>>> >> #tcp-proxy = 127.0.0.1:80 >>>> >> # Log file: >>>> >> log-file = $DISPLAY.log >>>> >> # Publish sessions: >>>> >> mdns = yes >>>> >> # Debugging: >>>> >> #debug = >>>> >> #debug = keyboard,clipboard,tray >>>> >> # OpenGL accelerated rendering: >>>> >> #opengl = yes >>>> >> #opengl = no >>>> >> opengl = auto >>>> >> # Use fixed quality: >>>> >> quality = auto >>>> >> # For auto quality, do not go below this value: >>>> >> min-quality = 50 >>>> >> # Use fixed speed: >>>> >> #speed = 20 >>>> >> speed = auto >>>> >> # For auto speed, do not go below this value: >>>> >> #min-speed = 20 >>>> >> min-speed = 0 >>>> >> # Idle delay in seconds before doing an automatic lossless refresh: >>>> >> auto-refresh-delay = 0.25 >>>> >> # Default DPI: >>>> >> dpi = 96 >>>> >> # Client window title: >>>> >> title = @title@ on @client-machine@ >>>> >> # Icon used by the system tray: >>>> >> #tray-icon = /path/to/icon.png >>>> >> # Keyboard synchronization: >>>> >> keyboard-sync = yes >>>> >> # Send ping packets more regularly (every second): >>>> >> pings = no >>>> >> # Client ssh command: >>>> >> #ssh = /usr/bin/ssh >>>> >> # Virtual display command: >>>> >> # - Old Xvfb option: >>>> >> # xvfb=Xvfb +extension Composite -screen 0 3840x2560x24+32 -nolisten >>>> tcp >>>> >> -noreset -auth $XAUTHORITY >>>> >> # - With Xorg 1.12 or newer and the dummy driver: >>>> >> # xvfb=/usr/bin/Xorg -dpi 96 -noreset -nolisten tcp +extension GLX >>>> >> +extension RANDR +extension RENDER -logfile >>>> >> ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf >>>> >> # >>>> >> # Using Xvfb: >>>> >> xvfb=Xvfb +extension Composite -screen 0 3840x2560x24+32 -nolisten >>>> tcp >>>> >> -noreset -auth $XAUTHORITY >>>> > _______________________________________________ >>>> > shifter-users mailing list >>>> > shifter-users at lists.devloop.org.uk >>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>>> >>> >> > > From ntlong0210 at gmail.com Sat Sep 6 04:07:08 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Sat, 6 Sep 2014 10:07:08 +0700 Subject: [winswitch] xpra: high %cpu when start a background application Message-ID: Hi all, (sorry if my English is not good) I'm using server Ubuntu 12.04 with xpra 0.14-1, client Windows 7 Pro with xpra 0.14 Reproduce: A. 1.At server: xpra start :100 --start-child=myapp --bind-tcp=0.0.0.0:20000 myapp is an application without GUI. 2. At client : xpra attach tcp:IP:20000 3. At server : top -> %CPU xpra ~ 10% B. 1.At server: xpra start :100 --start-child=firefox--bind-tcp=0.0.0.0:20000 2. At client : xpra attach tcp:IP:2000 3. At firefox windows: Open some website ( youtube,...) and check : %CPU ~ 25% - *75%* So is it normal with those %CPU when use xpra? From antoine at nagafix.co.uk Sat Sep 6 05:40:26 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 06 Sep 2014 11:40:26 +0700 Subject: [winswitch] xpra: high %cpu when start a background application In-Reply-To: References: Message-ID: <540A903A.5020103@nagafix.co.uk> On 06/09/14 10:07, Long Nguyen Thanh wrote: > Hi all, > (sorry if my English is not good) > I'm using server Ubuntu 12.04 with xpra 0.14-1, client Windows 7 Pro with > xpra 0.14 (those version numbers are incomplete, and if you really are using 0.14.0 then you should upgrade it) > Reproduce: > A. > 1.At server: xpra start :100 --start-child=myapp --bind-tcp=0.0.0.0:20000 > myapp is an application without GUI. > 2. At client : xpra attach tcp:IP:20000 > 3. At server : top -> %CPU xpra ~ 10% Does removing your app make any difference? (just connecting xpra) My guess is that sound forwarding is using your CPU for compression (mp3 or other). Yes, even when no sound is being played: http://xpra.org/trac/wiki/Sound#StatusandConfiguration > B. > 1.At server: xpra start :100 --start-child=firefox--bind-tcp=0.0.0.0:20000 > 2. At client : xpra attach tcp:IP:2000 > 3. At firefox windows: Open some website ( youtube,...) and check : > %CPU ~ 25% - *75%* Firefox will repaint the screen regularly, so yes, a high CPU usage with such an application is to be expected. (animated gifs, flash adverts, widgets, etc) > So is it normal with those %CPU when use xpra? As per above, turn off sound if you don't use it. Any screen updates will also consume bandwidth and CPU, minimizing the application when you're not using it will prevent that. I have added those questions to the FAQ: http://xpra.org/trac/wiki/FAQ#Issues-knownproblems Cheers Antoine From ntlong0210 at gmail.com Sat Sep 6 08:01:45 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Sat, 6 Sep 2014 14:01:45 +0700 Subject: [winswitch] xpra: high %cpu when start a background application In-Reply-To: <540A903A.5020103@nagafix.co.uk> References: <540A903A.5020103@nagafix.co.uk> Message-ID: Hi, On Sat, Sep 6, 2014 at 11:40 AM, Antoine Martin wrote: > On 06/09/14 10:07, Long Nguyen Thanh wrote: > > Hi all, > > (sorry if my English is not good) > > I'm using server Ubuntu 12.04 with xpra 0.14-1, client Windows 7 Pro with > > xpra 0.14 > (those version numbers are incomplete, and if you really are using > 0.14.0 then you should upgrade it) > I'd just upgrade to xpra 0.14.4-1 at both server and client. > > Reproduce: > > A. > > 1.At server: xpra start :100 --start-child=myapp --bind-tcp= > 0.0.0.0:20000 > > myapp is an application without GUI. > > 2. At client : xpra attach tcp:IP:20000 > > 3. At server : top -> %CPU xpra ~ 10% > Does removing your app make any difference? (just connecting xpra) > My guess is that sound forwarding is using your CPU for compression (mp3 > or other). > Yes, even when no sound is being played: > http://xpra.org/trac/wiki/Sound#StatusandConfiguration > I remove my app, just use : xpra start :100 --bind-tcp=0.0.0.0:20000, attach and check %CPU. It still ~ 8 - 10%. My sound forwarding is : "MPEG 1 Audio, Layer 3 (MP3)" and %CPU of pulseaudio ~3% > > B. > > 1.At server: xpra start :100 --start-child=firefox--bind-tcp= > 0.0.0.0:20000 > > 2. At client : xpra attach tcp:IP:2000 > > 3. At firefox windows: Open some website ( youtube,...) and check : > > %CPU ~ 25% - *75%* > Firefox will repaint the screen regularly, so yes, a high CPU usage with > such an application is to be expected. > (animated gifs, flash adverts, widgets, etc) > > So is it normal with those %CPU when use xpra? > As per above, turn off sound if you don't use it. > Any screen updates will also consume bandwidth and CPU, minimizing the > application when you're not using it will prevent that. > I have added those questions to the FAQ: > http://xpra.org/trac/wiki/FAQ#Issues-knownproblems > > 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 Sat Sep 6 11:04:16 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 06 Sep 2014 17:04:16 +0700 Subject: [winswitch] xpra: high %cpu when start a background application In-Reply-To: References: <540A903A.5020103@nagafix.co.uk> Message-ID: <540ADC20.4060005@nagafix.co.uk> (snip) > > > 3. At server : top -> %CPU xpra ~ 10% > Does removing your app make any difference? (just connecting xpra) > My guess is that sound forwarding is using your CPU for > compression (mp3 > or other). > Yes, even when no sound is being played: > http://xpra.org/trac/wiki/Sound#StatusandConfiguration > > I remove my app, just use : xpra start :100 --bind-tcp=0.0.0.0:20000 > , attach and check %CPU. It still ~ 8 - 10%. > My sound forwarding is : "MPEG 1 Audio, Layer 3 (MP3)" and %CPU of > pulseaudio ~3% So... just disable sound to get your CPU usage close to zero. Have you tried it? Antoine From ntlong0210 at gmail.com Mon Sep 8 01:58:40 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Mon, 8 Sep 2014 07:58:40 +0700 Subject: [winswitch] xpra: high %cpu when start a background application In-Reply-To: <540ADC20.4060005@nagafix.co.uk> References: <540A903A.5020103@nagafix.co.uk> <540ADC20.4060005@nagafix.co.uk> Message-ID: Hi, On Sat, Sep 6, 2014 at 5:04 PM, Antoine Martin wrote: > (snip) > > > 3. At server : top -> %CPU xpra ~ 10% >> Does removing your app make any difference? (just connecting xpra) >> My guess is that sound forwarding is using your CPU for compression (mp3 >> or other). >> Yes, even when no sound is being played: >> http://xpra.org/trac/wiki/Sound#StatusandConfiguration >> > I remove my app, just use : xpra start :100 --bind-tcp=0.0.0.0:20000, > attach and check %CPU. It still ~ 8 - 10%. > My sound forwarding is : "MPEG 1 Audio, Layer 3 (MP3)" and %CPU of > pulseaudio ~3% > > So... just disable sound to get your CPU usage close to zero. > Have you tried it? > I tried it, and %CPU ~ 0%. Thanks for your help. :) > > Antoine > From ntlong0210 at gmail.com Tue Sep 9 09:39:03 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Tue, 9 Sep 2014 15:39:03 +0700 Subject: [winswitch] change sound server Message-ID: Hi all, Can I change sound server ( from pulseaudio to another sound server) and use it with xpra ? From antoine at nagafix.co.uk Tue Sep 9 09:56:49 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 09 Sep 2014 15:56:49 +0700 Subject: [winswitch] change sound server In-Reply-To: References: Message-ID: <540EC0D1.7020905@nagafix.co.uk> On 09/09/14 15:39, Long Nguyen Thanh wrote: > Hi all, > > Can I change sound server ( from pulseaudio to another sound server) and > use it with xpra ? On the server (for capturing sound from the applications), I am afraid not, not yet. I guess we should add an option to allow the user to select the sound server to use. (it doesn't look too difficult to do) Client side, the output will go to the default sound system found by GStreamer's "autoaudiosink". You can override it with: XPRA_SOUND_SINK=alsasink xpra attach .. Cheers Antoine From antoine at nagafix.co.uk Tue Sep 9 10:26:51 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 09 Sep 2014 16:26:51 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.14.5 (many minor fixes) Message-ID: <540EC7DB.2080206@nagafix.co.uk> Hi, This update fixes many minor issues, most of which have been present for a while, so there is no urgency to upgrade if you weren't affected by them. Release notes: * fix sharing access mode * fix proxy server error with missing compression algorithms * fix initial window position (honour only when requested) * fix error wrongly reported after client command has been forwarded * fix support for multiple keys pressed at the same time * fix remote ssh start child command with spaces and quotes * fix remote ssh start child from MS Windows and OSX clients * handle small screen update storms better * minor build tree cleanups and fixes * improved bug report data 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 ntlong0210 at gmail.com Tue Sep 9 10:42:44 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Tue, 9 Sep 2014 16:42:44 +0700 Subject: [winswitch] change sound server In-Reply-To: <540EC0D1.7020905@nagafix.co.uk> References: <540EC0D1.7020905@nagafix.co.uk> Message-ID: Hi, On Tue, Sep 9, 2014 at 3:56 PM, Antoine Martin wrote: > On 09/09/14 15:39, Long Nguyen Thanh wrote: > > Hi all, > > > > Can I change sound server ( from pulseaudio to another sound server) and > > use it with xpra ? > On the server (for capturing sound from the applications), I am afraid > not, not yet. > I guess we should add an option to allow the user to select the sound > server to use. > (it doesn't look too difficult to do) > I hope this option will be added soon. Thank you for your time :) > > Client side, the output will go to the default sound system found by > GStreamer's "autoaudiosink". > You can override it with: > XPRA_SOUND_SINK=alsasink xpra attach .. > > 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 Tue Sep 9 15:42:12 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 09 Sep 2014 21:42:12 +0700 Subject: [winswitch] change sound server In-Reply-To: References: <540EC0D1.7020905@nagafix.co.uk> Message-ID: <540F11C4.9040600@nagafix.co.uk> On 09/09/14 16:42, Long Nguyen Thanh wrote: > Hi, > > On Tue, Sep 9, 2014 at 3:56 PM, Antoine Martin > wrote: > > On 09/09/14 15:39, Long Nguyen Thanh wrote: > > Hi all, > > > > Can I change sound server ( from pulseaudio to another sound > server) and > > use it with xpra ? > On the server (for capturing sound from the applications), I am afraid > not, not yet. > I guess we should add an option to allow the user to select the sound > server to use. > (it doesn't look too difficult to do) > > I hope this option will be added soon. Thank you for your time :) This is much more likely to get done if you create a ticket in the bug tracker, this will ensure that 1) I don't forget about it 2) I can re-assign to you for testing to validate the changes (as I usually run pulseaudio here) Cheers Antoine From ntlong0210 at gmail.com Wed Sep 10 01:59:33 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Wed, 10 Sep 2014 07:59:33 +0700 Subject: [winswitch] change sound server In-Reply-To: <540F11C4.9040600@nagafix.co.uk> References: <540EC0D1.7020905@nagafix.co.uk> <540F11C4.9040600@nagafix.co.uk> Message-ID: Hi, I created a ticket in the bug tracker. http://xpra.org/trac/ticket/673#ticket On Tue, Sep 9, 2014 at 9:42 PM, Antoine Martin wrote: > On 09/09/14 16:42, Long Nguyen Thanh wrote: > > Hi, > > On Tue, Sep 9, 2014 at 3:56 PM, Antoine Martin > wrote: > >> On 09/09/14 15:39, Long Nguyen Thanh wrote: >> > Hi all, >> > >> > Can I change sound server ( from pulseaudio to another sound server) >> and >> > use it with xpra ? >> On the server (for capturing sound from the applications), I am afraid >> not, not yet. >> I guess we should add an option to allow the user to select the sound >> server to use. >> (it doesn't look too difficult to do) >> > I hope this option will be added soon. Thank you for your time :) > > This is much more likely to get done if you create a ticket in the bug > tracker, this will ensure that > 1) I don't forget about it > 2) I can re-assign to you for testing to validate the changes (as I > usually run pulseaudio here) > > Cheers > Antoine > From ntlong0210 at gmail.com Thu Sep 11 09:56:29 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Thu, 11 Sep 2014 15:56:29 +0700 Subject: [winswitch] Clipboard one-way Message-ID: Hi all, Now xpra supports enable clipboard with 2-way, or disable clipboard. Can we use xpra to enable clipboard one-way, either only from server to client or only from client to server ? From antoine at nagafix.co.uk Thu Sep 11 09:58:16 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 11 Sep 2014 15:58:16 +0700 Subject: [winswitch] Clipboard one-way In-Reply-To: References: Message-ID: <54116428.7050206@nagafix.co.uk> On 11/09/14 15:56, Long Nguyen Thanh wrote: > Hi all, > > Now xpra supports enable clipboard with 2-way, or disable clipboard. > Can we use xpra to enable clipboard one-way, either only from server to > client or only from client to server ? This is planned but has not been implemented yet, feel free to subscribe to the ticket: http://xpra.org/trac/ticket/276 Cheers Antoine From Permafacture at gmail.com Fri Sep 12 03:29:19 2014 From: Permafacture at gmail.com (Elliot Hallmark) Date: Thu, 11 Sep 2014 21:29:19 -0500 Subject: [winswitch] Xpra for thin clients In-Reply-To: References: Message-ID: I just want to check in and make sure I am thinking correctly. My aim is to serve hardware opengl accelerated applications to thin clients. I wanted to use nvenc from a gtx 660, but this requires a developer key. So, for a prototype before investing in a $2000 grid card ( k1 and k2 support nvenc through xpra without a dev key), I will use the x264 encoder. Clients will run a stripped down linux that only runs xpra client in full screen, ultimately with a python based application or session selector interface. Server will serve applications (potentially virtualized desktops) at the full screen resolution of the client. The server will render applications on the gtx 660 before encoding. I believe this requires some hacking to make each application in a common X session (ie :100.1, 100.2, etc) inorder to "share" the gpu. I can do the last bit with X, ie I had two monitors displaying seperate hardware accelerated programs (like minecraft) from a single gpu through creative use of xorg.conf, so I'm assuming it can happen with xpra too. Has anyone done this before? Any heads up would be appreciated. Thanks, Elliot From antoine at nagafix.co.uk Fri Sep 12 04:13:46 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 10:13:46 +0700 Subject: [winswitch] Xpra for thin clients In-Reply-To: References: Message-ID: <541264EA.60500@nagafix.co.uk> On 12/09/14 09:29, Elliot Hallmark wrote: > I just want to check in and make sure I am thinking correctly. My aim is > to serve hardware opengl accelerated applications to thin clients. > > I wanted to use nvenc from a gtx 660, but this requires a developer key. Those keys exist. I haven't tested them myself with GTX6XXs, only with GTX7XXs, but I believe others have. > So, for a prototype before investing in a $2000 grid card ( k1 and k2 > support nvenc through xpra without a dev key), I will use the x264 encoder. If you want to use a pro card to avoid the license key issue, there are cheaper options than the grid cards. The NVENC chips on those cards are not faster than in the consumer cards (if anything slower because of the lower clock and older architecture), the only benefit of the grid cards is that they have multiple chips per card. (4 in a K1, 2 in a K2) > Clients will run a stripped down linux that only runs xpra client in full > screen, ultimately with a python based application or session selector > interface. Server will serve applications (potentially virtualized > desktops) at the full screen resolution of the client. The server will > render applications on the gtx 660 before encoding. If I understand this correctly, you want to use xpra to serve a full desktop instead of individual windows? That would work but it would be less efficient than letting the clients manage the windows themselves. > I believe this > requires some hacking to make each application in a common X session (ie > :100.1, 100.2, etc) inorder to "share" the gpu. I'm not sure I understand this part. If you want multiple server sessions getting accelerated OpenGL rendering, you should look at VirtualGL. If you want to share the NVENC encoding chip for multiple server sessions, then it is just a permission issue on the video device. > I can do the last bit with X, ie I had two monitors displaying seperate > hardware accelerated programs (like minecraft) from a single gpu through > creative use of xorg.conf, so I'm assuming it can happen with xpra too. This sounds like a client-side setup. > Has anyone done this before? Any heads up would be appreciated. Hope this helps! Cheers Antoine > > Thanks, > Elliot > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From Permafacture at gmail.com Fri Sep 12 04:52:58 2014 From: Permafacture at gmail.com (Elliot Hallmark) Date: Thu, 11 Sep 2014 22:52:58 -0500 Subject: [winswitch] Xpra for thin clients In-Reply-To: <541264EA.60500@nagafix.co.uk> References: <541264EA.60500@nagafix.co.uk> Message-ID: Thanks. Those keys exist, but how would I get one? Nvidia website says I need to have a personal contact at nvidia already to be considered. Yes, I forgot about virtualgl. I had got a two head system working and forgot that not dealing with video connections on the card would free me up. I am fine with serving applications, though a virtual machine could be an application if that ends up being useful. I intend to make a python based menu on the clients for choosing applications, rather than give clients the whole desktop. On Sep 11, 2014 10:14 PM, "Antoine Martin" wrote: > On 12/09/14 09:29, Elliot Hallmark wrote: > > I just want to check in and make sure I am thinking correctly. My aim is > > to serve hardware opengl accelerated applications to thin clients. > > > > I wanted to use nvenc from a gtx 660, but this requires a developer key. > Those keys exist. I haven't tested them myself with GTX6XXs, only with > GTX7XXs, but I believe others have. > > So, for a prototype before investing in a $2000 grid card ( k1 and k2 > > support nvenc through xpra without a dev key), I will use the x264 > encoder. > If you want to use a pro card to avoid the license key issue, there are > cheaper options than the grid cards. > The NVENC chips on those cards are not faster than in the consumer cards > (if anything slower because of the lower clock and older architecture), > the only benefit of the grid cards is that they have multiple chips per > card. (4 in a K1, 2 in a K2) > > Clients will run a stripped down linux that only runs xpra client in full > > screen, ultimately with a python based application or session selector > > interface. Server will serve applications (potentially virtualized > > desktops) at the full screen resolution of the client. The server will > > render applications on the gtx 660 before encoding. > If I understand this correctly, you want to use xpra to serve a full > desktop instead of individual windows? > That would work but it would be less efficient than letting the clients > manage the windows themselves. > > I believe this > > requires some hacking to make each application in a common X session (ie > > :100.1, 100.2, etc) inorder to "share" the gpu. > I'm not sure I understand this part. > If you want multiple server sessions getting accelerated OpenGL > rendering, you should look at VirtualGL. > If you want to share the NVENC encoding chip for multiple server > sessions, then it is just a permission issue on the video device. > > I can do the last bit with X, ie I had two monitors displaying seperate > > hardware accelerated programs (like minecraft) from a single gpu through > > creative use of xorg.conf, so I'm assuming it can happen with xpra too. > This sounds like a client-side setup. > > Has anyone done this before? Any heads up would be appreciated. > Hope this helps! > > Cheers > Antoine > > > > Thanks, > > 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 > From Permafacture at gmail.com Fri Sep 12 04:56:24 2014 From: Permafacture at gmail.com (Elliot Hallmark) Date: Thu, 11 Sep 2014 22:56:24 -0500 Subject: [winswitch] Xpra for thin clients In-Reply-To: <541264EA.60500@nagafix.co.uk> References: <541264EA.60500@nagafix.co.uk> Message-ID: Also, what card would be cheaper than a k1 for avoiding the key requirement for nvenc? From antoine at nagafix.co.uk Fri Sep 12 04:59:30 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 10:59:30 +0700 Subject: [winswitch] Xpra for thin clients In-Reply-To: References: <541264EA.60500@nagafix.co.uk> Message-ID: <54126FA2.9070304@nagafix.co.uk> On 12/09/14 10:56, Elliot Hallmark wrote: > > Also, what card would be cheaper than a k1 for avoiding the key > requirement for nvenc? > https://developer.nvidia.com/nvidia-video-codec-sdk#gpulist The K4000 is much cheaper. (disclaimer: I have not tested it) From antoine at nagafix.co.uk Fri Sep 12 05:07:44 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 11:07:44 +0700 Subject: [winswitch] Xpra for thin clients In-Reply-To: References: <541264EA.60500@nagafix.co.uk> Message-ID: <54127190.9030202@nagafix.co.uk> On 12/09/14 10:52, Elliot Hallmark wrote: > > Thanks. Those keys exist, but how would I get one? Nvidia website > says I need to have a personal contact at nvidia already to be considered. > I'm sorry I can't comment on that any more than I already have in my previous rant: http://lists.devloop.org.uk/pipermail/shifter-users/2014-June/000888.html Only to say that the NVENC SDK version 4 is now out and that I will take a look at it soon to see what broke: http://xpra.org/trac/ticket/653 > > Yes, I forgot about virtualgl. I had got a two head system working > and forgot that not dealing with video connections on the card would > free me up. > > I am fine with serving applications, though a virtual machine could be > an application if that ends up being useful. I intend to make a > python based menu on the clients for choosing applications, rather > than give clients the whole desktop. > That's what winswitch does, and more. If you only care about xpra and access over ssh, you can easily write something more simple. Cheers Antoine > On Sep 11, 2014 10:14 PM, "Antoine Martin" > wrote: > > On 12/09/14 09:29, Elliot Hallmark wrote: > > I just want to check in and make sure I am thinking correctly. > My aim is > > to serve hardware opengl accelerated applications to thin clients. > > > > I wanted to use nvenc from a gtx 660, but this requires a > developer key. > Those keys exist. I haven't tested them myself with GTX6XXs, only with > GTX7XXs, but I believe others have. > > So, for a prototype before investing in a $2000 grid card ( k1 > and k2 > > support nvenc through xpra without a dev key), I will use the > x264 encoder. > If you want to use a pro card to avoid the license key issue, > there are > cheaper options than the grid cards. > The NVENC chips on those cards are not faster than in the consumer > cards > (if anything slower because of the lower clock and older > architecture), > the only benefit of the grid cards is that they have multiple > chips per > card. (4 in a K1, 2 in a K2) > > Clients will run a stripped down linux that only runs xpra > client in full > > screen, ultimately with a python based application or session > selector > > interface. Server will serve applications (potentially virtualized > > desktops) at the full screen resolution of the client. The > server will > > render applications on the gtx 660 before encoding. > If I understand this correctly, you want to use xpra to serve a full > desktop instead of individual windows? > That would work but it would be less efficient than letting the > clients > manage the windows themselves. > > I believe this > > requires some hacking to make each application in a common X > session (ie > > :100.1, 100.2, etc) inorder to "share" the gpu. > I'm not sure I understand this part. > If you want multiple server sessions getting accelerated OpenGL > rendering, you should look at VirtualGL. > If you want to share the NVENC encoding chip for multiple server > sessions, then it is just a permission issue on the video device. > > I can do the last bit with X, ie I had two monitors displaying > seperate > > hardware accelerated programs (like minecraft) from a single gpu > through > > creative use of xorg.conf, so I'm assuming it can happen with > xpra too. > This sounds like a client-side setup. > > Has anyone done this before? Any heads up would be appreciated. > Hope this helps! > > Cheers > Antoine > > > > Thanks, > > 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 > From Permafacture at gmail.com Fri Sep 12 05:21:06 2014 From: Permafacture at gmail.com (Elliot Hallmark) Date: Thu, 11 Sep 2014 23:21:06 -0500 Subject: [winswitch] Xpra for thin clients In-Reply-To: <54126FA2.9070304@nagafix.co.uk> References: <541264EA.60500@nagafix.co.uk> <54126FA2.9070304@nagafix.co.uk> Message-ID: > https://developer.nvidia.com/nvidia-video-codec-sdk#gpulist > The K4000 is much cheaper. (disclaimer: I have not tested it) Okay, that list doesnt distinguish between key requiring and not (it lists geforce cards), but I can research more. Thanks. From Permafacture at gmail.com Fri Sep 12 05:26:24 2014 From: Permafacture at gmail.com (Elliot Hallmark) Date: Thu, 11 Sep 2014 23:26:24 -0500 Subject: [winswitch] Xpra for thin clients In-Reply-To: <54127190.9030202@nagafix.co.uk> References: <541264EA.60500@nagafix.co.uk> <54127190.9030202@nagafix.co.uk> Message-ID: >> Thanks. Those keys exist, but how would I get one? Nvidia website says I need to have a personal contact at nvidia already to be considered. > > I'm sorry I can't comment on that any more than I already have in my previous rant: > http://lists.devloop.org.uk/pipermail/shifter-users/2014-June/000888.html > > Only to say that the NVENC SDK version 4 is now out and that I will take a look at it soon to see what broke: > http://xpra.org/trac/ticket/653 Okay, so if I do get a key, xpra may be able to use it? > That's what winswitch does, and more. > If you only care about xpra and access over ssh, you can easily write something more simple. Ha, I haven't even looked at winswitch. I will check it out. I want the clients to be as thin as possible, but I doubt xpra vs winswitch is much difference. Elliot > Cheers > Antoine > > >> On Sep 11, 2014 10:14 PM, "Antoine Martin" wrote: >>> >>> On 12/09/14 09:29, Elliot Hallmark wrote: >>> > I just want to check in and make sure I am thinking correctly. My aim is >>> > to serve hardware opengl accelerated applications to thin clients. >>> > >>> > I wanted to use nvenc from a gtx 660, but this requires a developer key. >>> Those keys exist. I haven't tested them myself with GTX6XXs, only with >>> GTX7XXs, but I believe others have. >>> > So, for a prototype before investing in a $2000 grid card ( k1 and k2 >>> > support nvenc through xpra without a dev key), I will use the x264 encoder. >>> If you want to use a pro card to avoid the license key issue, there are >>> cheaper options than the grid cards. >>> The NVENC chips on those cards are not faster than in the consumer cards >>> (if anything slower because of the lower clock and older architecture), >>> the only benefit of the grid cards is that they have multiple chips per >>> card. (4 in a K1, 2 in a K2) >>> > Clients will run a stripped down linux that only runs xpra client in full >>> > screen, ultimately with a python based application or session selector >>> > interface. Server will serve applications (potentially virtualized >>> > desktops) at the full screen resolution of the client. The server will >>> > render applications on the gtx 660 before encoding. >>> If I understand this correctly, you want to use xpra to serve a full >>> desktop instead of individual windows? >>> That would work but it would be less efficient than letting the clients >>> manage the windows themselves. >>> > I believe this >>> > requires some hacking to make each application in a common X session (ie >>> > :100.1, 100.2, etc) inorder to "share" the gpu. >>> I'm not sure I understand this part. >>> If you want multiple server sessions getting accelerated OpenGL >>> rendering, you should look at VirtualGL. >>> If you want to share the NVENC encoding chip for multiple server >>> sessions, then it is just a permission issue on the video device. >>> > I can do the last bit with X, ie I had two monitors displaying seperate >>> > hardware accelerated programs (like minecraft) from a single gpu through >>> > creative use of xorg.conf, so I'm assuming it can happen with xpra too. >>> This sounds like a client-side setup. >>> > Has anyone done this before? Any heads up would be appreciated. >>> Hope this helps! >>> >>> Cheers >>> Antoine >>> > >>> > Thanks, >>> > 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 > > From antoine at nagafix.co.uk Fri Sep 12 05:33:11 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 11:33:11 +0700 Subject: [winswitch] Xpra for thin clients In-Reply-To: References: <541264EA.60500@nagafix.co.uk> <54126FA2.9070304@nagafix.co.uk> Message-ID: <54127787.2040306@nagafix.co.uk> On 12/09/14 11:21, Elliot Hallmark wrote: > > > > https://developer.nvidia.com/nvidia-video-codec-sdk#gpulist > > The K4000 is much cheaper. (disclaimer: I have not tested it) > > Okay, that list doesnt distinguish between key requiring and not (it > lists geforce cards), but I can research more. Thanks. > I have been told that: * the "pro" cards, whose name starts with a K, do not require a license key * the consumer cards do (but only on Linux?) From antoine at nagafix.co.uk Fri Sep 12 05:37:21 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 11:37:21 +0700 Subject: [winswitch] Xpra for thin clients In-Reply-To: References: <541264EA.60500@nagafix.co.uk> <54127190.9030202@nagafix.co.uk> Message-ID: <54127881.9030807@nagafix.co.uk> On 12/09/14 11:26, Elliot Hallmark wrote: > > > >> Thanks. Those keys exist, but how would I get one? Nvidia website > says I need to have a personal contact at nvidia already to be considered. > > > > I'm sorry I can't comment on that any more than I already have in my > previous rant: > > > http://lists.devloop.org.uk/pipermail/shifter-users/2014-June/000888.html > > > > Only to say that the NVENC SDK version 4 is now out and that I will > take a look at it soon to see what broke: > > http://xpra.org/trac/ticket/653 > > Okay, so if I do get a key, xpra may be able to use it? > Yes, when the nvidia driver updates don't break it, I use it every day on a GTX760. Antoine > > > That's what winswitch does, and more. > > If you only care about xpra and access over ssh, you can easily > write something more simple. > > Ha, I haven't even looked at winswitch. I will check it out. I want > the clients to be as thin as possible, but I doubt xpra vs winswitch > is much difference. > > Elliot > > > Cheers > > Antoine > > > > > >> On Sep 11, 2014 10:14 PM, "Antoine Martin" > wrote: > >>> > >>> On 12/09/14 09:29, Elliot Hallmark wrote: > >>> > I just want to check in and make sure I am thinking correctly. > My aim is > >>> > to serve hardware opengl accelerated applications to thin clients. > >>> > > >>> > I wanted to use nvenc from a gtx 660, but this requires a > developer key. > >>> Those keys exist. I haven't tested them myself with GTX6XXs, only with > >>> GTX7XXs, but I believe others have. > >>> > So, for a prototype before investing in a $2000 grid card ( k1 > and k2 > >>> > support nvenc through xpra without a dev key), I will use the > x264 encoder. > >>> If you want to use a pro card to avoid the license key issue, > there are > >>> cheaper options than the grid cards. > >>> The NVENC chips on those cards are not faster than in the consumer > cards > >>> (if anything slower because of the lower clock and older > architecture), > >>> the only benefit of the grid cards is that they have multiple > chips per > >>> card. (4 in a K1, 2 in a K2) > >>> > Clients will run a stripped down linux that only runs xpra > client in full > >>> > screen, ultimately with a python based application or session > selector > >>> > interface. Server will serve applications (potentially virtualized > >>> > desktops) at the full screen resolution of the client. The > server will > >>> > render applications on the gtx 660 before encoding. > >>> If I understand this correctly, you want to use xpra to serve a full > >>> desktop instead of individual windows? > >>> That would work but it would be less efficient than letting the > clients > >>> manage the windows themselves. > >>> > I believe this > >>> > requires some hacking to make each application in a common X > session (ie > >>> > :100.1, 100.2, etc) inorder to "share" the gpu. > >>> I'm not sure I understand this part. > >>> If you want multiple server sessions getting accelerated OpenGL > >>> rendering, you should look at VirtualGL. > >>> If you want to share the NVENC encoding chip for multiple server > >>> sessions, then it is just a permission issue on the video device. > >>> > I can do the last bit with X, ie I had two monitors displaying > seperate > >>> > hardware accelerated programs (like minecraft) from a single gpu > through > >>> > creative use of xorg.conf, so I'm assuming it can happen with > xpra too. > >>> This sounds like a client-side setup. > >>> > Has anyone done this before? Any heads up would be appreciated. > >>> Hope this helps! > >>> > >>> Cheers > >>> Antoine > >>> > > >>> > Thanks, > >>> > 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 > > > > > From antoine at nagafix.co.uk Fri Sep 12 05:39:38 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 11:39:38 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.14.6 (minor fixes) Message-ID: <5412790A.1050107@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This minor update fixes some small bugs which are all fairly hard to trigger. There is no urgency to update. Release notes: * fix transparency support on legacy systems * fix window icons colours swapped in rgb mode * fix video region refresh error * fix OpenGL error in logging code * fix failures to daemonize * reduce cost of rectangle calculations * better window debugging information The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQSeQoACgkQGK2zHPGK1rtQmQCfcJzctIVka7Lr3g5EPFR/yB6G ulsAnix7s24oT9N2hs6AGWWJDeot0+Wb =rWhA -----END PGP SIGNATURE----- From dougdoole at gmail.com Fri Sep 12 14:02:18 2014 From: dougdoole at gmail.com (Douglas Doole) Date: Fri, 12 Sep 2014 09:02:18 -0400 Subject: [winswitch] xpra 0.14.6 traps on Ubuntu 12.04 Message-ID: Just upgraded my client to 0.14.6. When I attempt to connect to my server (already running 0.14.6 on Ubuntu 14.04) the client traps: $ xpra attach ssh:reorx:1 2014-09-12 08:58:36,750 buggy Ubuntu swscale version detected: (2, 1, 0) 2014-09-12 08:58:36,750 cowardly refusing to use it to avoid problems, set the environment variable: 2014-09-12 08:58:36,750 XPRA_FORCE_SWSCALE=1 2014-09-12 08:58:36,750 to use it anyway, at your own risk 2014-09-12 08:58:36,751 cannot import csc_swscale (swscale colorspace conversion): unsupported Ubuntu swscale version: (2, 1, 0) Segmentation fault (core dumped) 0.14.5 had no problems talking to the server. If I can get you any other details, just let me know. Thanks. -- -- Doug Doole aibohphobia - The irrational fear of palindromes From antoine at nagafix.co.uk Fri Sep 12 14:26:14 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 20:26:14 +0700 Subject: [winswitch] xpra 0.14.6 traps on Ubuntu 12.04 In-Reply-To: References: Message-ID: <5412F476.7060601@nagafix.co.uk> On 12/09/14 20:02, Douglas Doole wrote: > Just upgraded my client to 0.14.6. (Judging by the big warning message below, your client must be running Ubuntu 12.04?) > When I attempt to connect to my server > (already running 0.14.6 on Ubuntu 14.04) the client traps: > > $ xpra attach ssh:reorx:1 > 2014-09-12 08:58:36,750 buggy Ubuntu swscale version detected: (2, 1, 0) > 2014-09-12 08:58:36,750 cowardly refusing to use it to avoid problems, set > the environment variable: > 2014-09-12 08:58:36,750 XPRA_FORCE_SWSCALE=1 > 2014-09-12 08:58:36,750 to use it anyway, at your own risk > 2014-09-12 08:58:36,751 cannot import csc_swscale (swscale colorspace > conversion): unsupported Ubuntu swscale version: (2, 1, 0) > Segmentation fault (core dumped) > > 0.14.5 had no problems talking to the server. I can reproduce it, so I should be able to figure it out. In the meantime, I can offer this dirty workaround which should work for most Debian / Ubuntu distros: sudo rm -fr /usr/lib/python2.7/dist-packages/xpra/codecs/csc_swscale sudo rm -fr /usr/lib/pyshared/python2.7/xpra/codecs/csc_swscale It is a very odd one because there is nothing in the changes from 0.14.5 to 0.14.6 that are in any way related to "swscale", and even nothing that should be able to cause a segfault. They're all small python things, and I've just reviewed them all again. But there is one thing: these newer builds were made with the new Cython 0.21 (released 2 days ago) instead of Cython 0.20.2 which was used previously. It would be interesting to know which other builds are affected by this, if any. > If I can get you any other details, just let me know. Cheers Antoine From dougdoole at gmail.com Fri Sep 12 14:34:21 2014 From: dougdoole at gmail.com (Douglas Doole) Date: Fri, 12 Sep 2014 09:34:21 -0400 Subject: [winswitch] xpra 0.14.6 traps on Ubuntu 12.04 In-Reply-To: <5412F476.7060601@nagafix.co.uk> References: <5412F476.7060601@nagafix.co.uk> Message-ID: Thanks. Removing those two files did get me up and running again. And my client is Ubuntu 12.04. (I'd love to move to 14.04, but the powers that be haven't approved 14.04 for desktop use yet :-( ) On Fri, Sep 12, 2014 at 9:26 AM, Antoine Martin wrote: > On 12/09/14 20:02, Douglas Doole wrote: > > Just upgraded my client to 0.14.6. > (Judging by the big warning message below, your client must be running > Ubuntu 12.04?) > > When I attempt to connect to my server > > (already running 0.14.6 on Ubuntu 14.04) the client traps: > > > > $ xpra attach ssh:reorx:1 > > 2014-09-12 08:58:36,750 buggy Ubuntu swscale version detected: (2, 1, 0) > > 2014-09-12 08:58:36,750 cowardly refusing to use it to avoid problems, > set > > the environment variable: > > 2014-09-12 08:58:36,750 XPRA_FORCE_SWSCALE=1 > > 2014-09-12 08:58:36,750 to use it anyway, at your own risk > > 2014-09-12 08:58:36,751 cannot import csc_swscale (swscale colorspace > > conversion): unsupported Ubuntu swscale version: (2, 1, 0) > > Segmentation fault (core dumped) > > > > 0.14.5 had no problems talking to the server. > I can reproduce it, so I should be able to figure it out. > In the meantime, I can offer this dirty workaround which should work for > most Debian / Ubuntu distros: > sudo rm -fr /usr/lib/python2.7/dist-packages/xpra/codecs/csc_swscale > sudo rm -fr /usr/lib/pyshared/python2.7/xpra/codecs/csc_swscale > > It is a very odd one because there is nothing in the changes from 0.14.5 > to 0.14.6 that are in any way related to "swscale", and even nothing > that should be able to cause a segfault. > They're all small python things, and I've just reviewed them all again. > > But there is one thing: these newer builds were made with the new Cython > 0.21 (released 2 days ago) instead of Cython 0.20.2 which was used > previously. > It would be interesting to know which other builds are affected by this, > if any. > > If I can get you any other details, just let me know. > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > -- -- Doug Doole aibohphobia - The irrational fear of palindromes From antoine at nagafix.co.uk Fri Sep 12 15:24:40 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Sep 2014 21:24:40 +0700 Subject: [winswitch] xpra 0.14.6 traps on Ubuntu 12.04 In-Reply-To: <5412F476.7060601@nagafix.co.uk> References: <5412F476.7060601@nagafix.co.uk> Message-ID: <54130228.5070708@nagafix.co.uk> >> When I attempt to connect to my server >> (already running 0.14.6 on Ubuntu 14.04) the client traps: >> >> $ xpra attach ssh:reorx:1 >> 2014-09-12 08:58:36,750 buggy Ubuntu swscale version detected: (2, 1, 0) >> 2014-09-12 08:58:36,750 cowardly refusing to use it to avoid problems, set >> the environment variable: >> 2014-09-12 08:58:36,750 XPRA_FORCE_SWSCALE=1 >> 2014-09-12 08:58:36,750 to use it anyway, at your own risk >> 2014-09-12 08:58:36,751 cannot import csc_swscale (swscale colorspace >> conversion): unsupported Ubuntu swscale version: (2, 1, 0) >> Segmentation fault (core dumped) (..) > But there is one thing: these newer builds were made with the new Cython > 0.21 (released 2 days ago) instead of Cython 0.20.2 which was used > previously. This has been confirmed as a Cython 0.21 bug which I have reported upstream. The xpra fix is very simple: http://xpra.org/trac/changeset/7590/xpra And I've pushed updated Ubuntu 12.04 packages to the repository. Ubuntu 12.04 was the only platform affected. Cheers Antoine From antoine at nagafix.co.uk Fri Sep 19 06:14:28 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 19 Sep 2014 12:14:28 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.14.7 (minor fixes) Message-ID: <541BBBB4.4090407@nagafix.co.uk> Hi, This minor update fixes mostly small cosmetic bugs, only the compressor issue could have caused some older client / server combinations to fail to connect. The Gnome 3.12 issue was a very old one, which only affected this specific version of Gnome. There is no urgency to update if you were not affected by these bugs. Release notes: * fix compressor fallback case * fix python2.4 compatibility in bug report tool * fix client hangs caused by system tray in gnome 3.12 * fix OpenGL double error in failure case * fix system tray error message on client start * fix missing default configuration file * fix session-info window paint issue when switching tabs * fix default window icon * add new default resolutions for Xdummy 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 ntlong0210 at gmail.com Wed Sep 24 10:28:16 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Wed, 24 Sep 2014 16:28:16 +0700 Subject: [winswitch] [xpra] screen blur if maximize windows Message-ID: Hi, I have some problems with xpra, and still unresolved. 1. I ususally use xpra client with encoding H.264. Assume I use firefox to read news, and often scroll up, scroll down... At normal size ( not maximize ), screen is OK. At maximize size, screen become blur. I'd changed Xvfb screen -> 1024x768 but it not work. 2. Sometimes, xpra can't attach, and appear error 10061 connection refused 3.I always receive errors : Xlibs : RANDR missing, RENDR missing when start any application with xpra. But I can still use those apps. 4. How I can use OpenGL option ? Server: Ubuntu 12.04, xpra 0.14.7-1 Client : Windows 7 Ultimate, xpra 0.14.7-1 From antoine at nagafix.co.uk Wed Sep 24 10:40:26 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 24 Sep 2014 16:40:26 +0700 Subject: [winswitch] [xpra] screen blur if maximize windows In-Reply-To: References: Message-ID: <5422918A.1060605@nagafix.co.uk> On 24/09/14 16:28, Long Nguyen Thanh wrote: > Hi, > > I have some problems with xpra, and still unresolved. > > 1. I ususally use xpra client with encoding H.264. Assume I use firefox to > read news, and often scroll up, scroll down... > At normal size ( not maximize ), screen is OK. > At maximize size, screen become blur. The encoding heuristics may start downscaling your windows at high resolutions in order to keep up (usually about 1080p and up). If you raise the minimum quality and/or lower the speed, this is much less likely to happen. When this does happen, the auto-refresh should kick in eventually and clear the blurriness. > I'd changed Xvfb screen -> 1024x768 but it not work. Not sure what makes you think that this is a good idea. And why 1024x768? > 2. Sometimes, xpra can't attach, and appear error 10061 connection refused This looks like a mswindows error code. A quick google search leads me to believe that: " the problem is with an intermediate networking device" (firewall or other, wrong port, etc) > 3.I always receive errors : Xlibs : RANDR missing, RENDR missing when start > any application with xpra. But I can still use those apps. It is very difficult to say without the full commands used (including the one for xpra, Xvfb and the command used) and the full error message and where you found it. Some warnings come from the X11 server can be ignored, maybe this is one of those: https://www.xpra.org/trac/wiki/FAQ#WarningsandMessages > 4. How I can use OpenGL option ? OpenGL client rendering is enabled if your graphics card drivers support it. http://xpra.org/trac/wiki/ClientRendering/OpenGL For the server, see: https://www.xpra.org/trac/wiki/FAQ#OpenGLIssues > Server: Ubuntu 12.04, xpra 0.14.7-1 IIRC, Ubuntu 12.04 is problematic for many things, including Xdummy and OpenGL... > Client : Windows 7 Ultimate, xpra 0.14.7-1 Cheers Antoine From ntlong0210 at gmail.com Wed Sep 24 11:27:52 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Wed, 24 Sep 2014 17:27:52 +0700 Subject: [winswitch] [xpra] screen blur if maximize windows In-Reply-To: <5422918A.1060605@nagafix.co.uk> References: <5422918A.1060605@nagafix.co.uk> Message-ID: On Wed, Sep 24, 2014 at 4:40 PM, Antoine Martin wrote: > On 24/09/14 16:28, Long Nguyen Thanh wrote: > > Hi, > > > > I have some problems with xpra, and still unresolved. > > > > 1. I ususally use xpra client with encoding H.264. Assume I use firefox > to > > read news, and often scroll up, scroll down... > > At normal size ( not maximize ), screen is OK. > > At maximize size, screen become blur. > The encoding heuristics may start downscaling your windows at high > resolutions in order to keep up (usually about 1080p and up). > If you raise the minimum quality and/or lower the speed, this is much > less likely to happen. > When this does happen, the auto-refresh should kick in eventually and > clear the blurriness. > I'd set quality and speed option are auto. > > I'd changed Xvfb screen -> 1024x768 but it not work. > Not sure what makes you think that this is a good idea. > And why 1024x768? > My current screen resolution is 1024x768. I use it cos I want to set fullscreen video in Firefox with right size.( If use default xpra.conf, video is too large ( out of my screen) when fullscreen.) > > 2. Sometimes, xpra can't attach, and appear error 10061 connection > refused > This looks like a mswindows error code. A quick google search leads me > to believe that: > " the problem is with an intermediate networking device" > (firewall or other, wrong port, etc) > > 3.I always receive errors : Xlibs : RANDR missing, RENDR missing when > start > > any application with xpra. But I can still use those apps. > It is very difficult to say without the full commands used (including > the one for xpra, Xvfb and the command used) and the full error message > and where you found it. > Some warnings come from the X11 server can be ignored, maybe this is one > of those: > https://www.xpra.org/trac/wiki/FAQ#WarningsandMessages > Thank you, I found it. > > 4. How I can use OpenGL option ? > OpenGL client rendering is enabled if your graphics card drivers support > it. > http://xpra.org/trac/wiki/ClientRendering/OpenGL > For the server, see: > https://www.xpra.org/trac/wiki/FAQ#OpenGLIssues > > Server: Ubuntu 12.04, xpra 0.14.7-1 > IIRC, Ubuntu 12.04 is problematic for many things, including Xdummy and > OpenGL... > Ubuntu 14.04 is same ? I think I will upgrade my server to 14.04 if it is less problematic than. > > Client : Windows 7 Ultimate, xpra 0.14.7-1 > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Wed Sep 24 11:39:13 2014 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 24 Sep 2014 17:39:13 +0700 Subject: [winswitch] [xpra] screen blur if maximize windows In-Reply-To: References: <5422918A.1060605@nagafix.co.uk> Message-ID: <54229F51.5000308@nagafix.co.uk> > > 4. How I can use OpenGL option ? > OpenGL client rendering is enabled if your graphics card drivers > support it. > http://xpra.org/trac/wiki/ClientRendering/OpenGL > For the server, see: > https://www.xpra.org/trac/wiki/FAQ#OpenGLIssues > > Server: Ubuntu 12.04, xpra 0.14.7-1 > IIRC, Ubuntu 12.04 is problematic for many things, including > Xdummy and > OpenGL... > > Ubuntu 14.04 is same ? I think I will upgrade my server to 14.04 if it > is less problematic than. Ubuntu is generally a pain to support, no matter what version you choose. 14.04 is better than 12.04, but you will still be missing Xdummy (because of tty permission issues specific to Ubuntu) and therefore RANDR, etc. The global menu system is also problematic, as is the appindicator and their shambolic APIs. I would strongly advise you to use just about any other Linux distribution out there. (gnome3 also has issues, but it tends to degrade a lot better) Cheers Antoine From ntlong0210 at gmail.com Wed Sep 24 13:46:31 2014 From: ntlong0210 at gmail.com (Long Nguyen Thanh) Date: Wed, 24 Sep 2014 19:46:31 +0700 Subject: [winswitch] [xpra] screen blur if maximize windows In-Reply-To: <54229F51.5000308@nagafix.co.uk> References: <5422918A.1060605@nagafix.co.uk> <54229F51.5000308@nagafix.co.uk> Message-ID: On Wed, Sep 24, 2014 at 5:39 PM, Antoine Martin wrote: > > > 4. How I can use OpenGL option ? >> OpenGL client rendering is enabled if your graphics card drivers support >> it. >> http://xpra.org/trac/wiki/ClientRendering/OpenGL >> For the server, see: >> https://www.xpra.org/trac/wiki/FAQ#OpenGLIssues >> > Server: Ubuntu 12.04, xpra 0.14.7-1 >> IIRC, Ubuntu 12.04 is problematic for many things, including Xdummy and >> OpenGL... >> > Ubuntu 14.04 is same ? I think I will upgrade my server to 14.04 if it is > less problematic than. > > Ubuntu is generally a pain to support, no matter what version you choose. > 14.04 is better than 12.04, but you will still be missing Xdummy (because > of tty permission issues specific to Ubuntu) and therefore RANDR, etc. > The global menu system is also problematic, as is the appindicator and > their shambolic APIs. > I would strongly advise you to use just about any other Linux distribution > out there. > (gnome3 also has issues, but it tends to degrade a lot better) > Thanks for your advice. :) > > Cheers > Antoine > From lee at uberactive.com Tue Sep 30 19:21:51 2014 From: lee at uberactive.com (S. Lee Gooding) Date: Tue, 30 Sep 2014 14:21:51 -0400 Subject: [winswitch] How to specify newer version of Xpra on Windows? Message-ID: Hey everyone, I just recently discovered Window Switch. It is a fantastic tool! I noticed that the binary setup for windows is using an older version of Xpra. I would like to use a newer version if possible. How do I tell Window Switch to use my newer install of Xpra, rather than the bundled version? Thanks!