[winswitch] interesting development
Frédéric Henry-Couannier
fhenryco at yahoo.fr
Thu May 28 11:04:36 BST 2015
the server is very powerful and the link is just an ethernet cable .... so in principle the bottleneck can only be the client ( Amlogic ARM� Cortex�-A5(ARMv7) 1.5Ghz quad core CPUs ..
But even with no compression it's slow (?!), so i'm going to investigate with another machine as client ...
F H-C
Le Jeudi 28 mai 2015 11h45, Antoine Martin <antoine at nagafix.co.uk> a écrit :
On 28/05/15 13:32, Frédéric Henry-Couannier wrote:
> thanks for advices and helpful support
> I installed pip , lz4 and could choose rgb and lz4 for my window , result fluid in 420p youtube but becomes slow in 720p and beyond...i'm wondering what kind of other parameters could improve
Try "--compress=0"
Then I guess you need to figure out where the bottleneck is:
* are you CPU bound on the server? On the client?
* is your network maxed out?
etc..
> ... however openGL is not supported by my small client board (odroid , a little bit more powerful than last raspberry pi) ... Is it foreseen to implement OpenGL-ES in xpra ?
This is not planned, yet.
> this might allow better performances on such small board , very low prices clients...
>
>
> Le Jeudi 28 mai 2015 5h28, Antoine Martin <antoine at nagafix.co.uk> a écrit :
>
>
> On 28/05/15 01:58, Frédéric Henry-Couannier wrote:
>> Yes i had readen but for instance when i tried
>> xpra control :100 compression lz4
>> i got
>> server returned error code 5invalid argument for 'compression': must be one of: zlib
>> I'd like to be fast and in my distro i cant find any lz4 so i hope i just need to download it from lz4 0.7.0 : Python Package Index and install with $ pip install lz4$ easy_install lz4
>> | |
>> | | | | | | | |
>> | lz4 0.7.0 : Python Package IndexLZ4 Bindings for Python |
>> | |
>> | Afficher sur pypi.... | Aperçu par Yahoo |
>> | |
>> | |
>>
>> but then i see instructions and informations that seem to be more suited for developpers...so i'm not very reassured i'm not going to put the mess on my PC :-)
> Installing things is always best done through your distribution's
> package manager - whatever that is.
> Though in this particular case, it should be pretty safe to just pip or
> easy_install lz4.
> (the only downside is that unlike regular packages, you will not get
> updates automatically)
>
> Antoine
>
>
>>
>> Le Mercredi 27 mai 2015 19h29, Antoine Martin <antoine at nagafix.co.uk> a écrit :
>>
>>
>> On 28/05/15 00:22, Frédéric Henry-Couannier wrote:
>>> Well i'm not sur i understand what you mean by... the right settings...
>> Please see the wiki link, and ask questions once you've read it.
>>> May be my problem from the begining is that xpra and winswitch are not provided by my linux distro which is Mageia so i had to install following instructions on a web site and i'm not sure it's complete...
>> You're not saying which instructions, so that's impossible for me to say.
>>> for instance i dont have winswitch ...
>> It isn't required if all you want is xpra.
>>> The Mageia team told be that i should ask the xpra developpers to make a rpm for mageia ...
>> Not going to happen I am afraid. We can't support every distro out there.
>> Though we will gladly accept packaging contributions that enhance
>> support for those distros.
>>
>> Cheers
>> Antoine
>>
>>>
>>>
>>>
>>>
>>> Le Mercredi 27 mai 2015 10h55, Antoine Martin <antoine at nagafix.co.uk> a écrit :
>>>
>>>
>>> On 27/05/15 00:37, Frédéric Henry-Couannier wrote:
>>>
>>> thanks for answering,
>>> yes xterm forwarding works. and yes i get a window which content is black for Xnest.
>>> i will try Xephyr ... so far i confirm that xpra is indeed somewhat faster than x2go, but it's still slow for youtube video in HD full screen ... could it be because my client is not powerfull (odroid C1)?
>>> Assuming that you are using the right settings, see:
>>> http://xpra.org/trac/wiki/Encodings
>>> (usually means using lz4+rgb on a LAN, or h264 otherwise)
>>> Encoding is almost always CPU bound on the server side, rarely an issue client side.
>>> (having opengl rendering client side helps too)
>>> Handling fullscreen at resolutions higher than 1080p is a different problem, which we will try to deal with in future releases.
>>>
>>> Antoine
>>>
>>>
>>>
>>>
>>>
>>>
>>> Le Mardi 26 mai 2015 12h57, Antoine Martin <antoine at nagafix.co.uk> a écrit :
>>>
>>>
>>> On 26/05/15 15:53, Frédéric Henry-Couannier wrote:
>>> > hello ,
>>> > Now i have tested successfully xpra for application forwarding between a Linux server station and an odroid (client) . However i cant make it work for the full desktop forwarding.
>>> > I tried on the server:xpra start --start-child="Xnest :200 -ac -geometry 800x600+24" :100
>>> > DISPLAY=:200 fluxbox&and get message
>>> > Xlib: extension "RANDR" missing on display ":200"
>>> Some window managers may require randr, though I don't think fluxbox does.
>>> You might want to try with Xephyr instead of Xnest.
>>> > ?? what does it mean i have no idea
>>> > Then on the client xpra attach ssh:SERVERUSERNAME at SERVERHOST:100gives me a black screen
>>> By "a black screen", I assume that you mean you get a window whose
>>> contents are black?
>>> The fact that something shows up at all tells me that xpra is forwarding
>>> something, which should be the Xnest window.
>>> Have you tried another window manager instead of fluxbox?
>>> Have you tried also starting and xterm on that display? Does that show up?
>>>
>>> Antoine
>>> > best,
>>> > Fred
>>> >
>>> >
>>> > Le Mardi 7 avril 2015 23h54, basd <basd1 at fastbk.com> a écrit :
>>> >
>>> >
>>> > In my earlier post I mentioned problems connecting to server socket for desktops. However, with
>>> > implementation of xpra-0.14.21 I am able to run xpra sessions.
>>> >
>>> > Interestingly, I can spawn multiple child windows from an xpra remote application that function as
>>> > windows on the client -- but can be moved collectively to another client. This is a reasonable
>>> > substitute for desktop sessions.
>>> >
>>> > Back when I was using iceWM desktop for remote sessions, I wrote a bash script that provides a menu
>>> > for launching favorite programs. Using that script, I can launch an xterm session in xpra, run my
>>> > menu bash script and launch separate programs from it. For instance, I can run firefox, dolphin
>>> > file manager, libreoffice and even Yast2 (openSuSE's administrative control panel). So far, this
>>> > appears to give me the same functionality as running these programs in an iceWM desktop session,
>>> > with the additional advantage that the xpra child windows function as windows on the client desktop
>>> > itself. Both server and clients are running KDE 4.14 -- this is interesting, because winswitch.org
>>> > FAQs seem to indicate applications are problematic to run under KDE/Plasma.
>>> >
>>> > I had to mark ssh_tunnel=False in the server.conf file, since ssh tunnelling is not working for me.
>>> >
>>> > Other points:
>>> >
>>> > *I have concluded that my installs apparently cannot do ssh tunnelling. I never tried to implement
>>> > this because I use a VPN, so I have always used direct connections. Ssh is active on the server and
>>> > I can use sftp, ssh, etc. to the server.
>>> > *Sometimes when exiting xpra windows, a "ghost" xpra session is left in the winswitch menu list, as
>>> > "unknown". I can't access or kill this session.
>>> > *opSU 13.1 repositories have libwep4 series and current xpra requires libwep5, which is available in
>>> > opSU 13.2 repositories.
>>> >
>>> >
>>> > For reference:
>>> >
>>> > Server 1:
>>> > 6 core AMD x86_64
>>> > openSuSE 13.1
>>> > linux kernel 3.11.10-25-desktop
>>> > KDE platform 4.14.6
>>> > winswitch-0.12.20 in an rpm I built from sources under opSU 13.1
>>> > xpra-0.14.4 (also in an rpm I built from sources)
>>> >
>>> > remote desktops work / remote applications do not work
>>> >
>>> > Server 2:
>>> > 8 core AMD x86_64
>>> > openSuSE 13.2
>>> > linux kernel 3.19.3-1-gf10e7fc-desktop
>>> > KDE platform 4.14.6
>>> > winswitch-0.12.20 in an rpm I built from sources under opSU 13.2
>>> > xpra-0.14.21 (also in an rpm I built from sources under opSU 13.2)
>>> >
>>> > remote desktops do not work / remote applications do work, per above description.
>>> >
>>> > Barrington Daltrey
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > shifter-users mailing list
>>> > shifter-users at lists.devloop.org.uk
>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > shifter-users mailing list
>>> > shifter-users at lists.devloop.org.uk
>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> shifter-users at lists.devloop.org.uk
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> shifter-users at lists.devloop.org.uk
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users at lists.devloop.org.uk
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>
>>
>>
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users at lists.devloop.org.uk
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>
>
>
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
shifter-users at lists.devloop.org.uk
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
More information about the shifter-users
mailing list