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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>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
>>><[email protected]> 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
>>><[email protected]> 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@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 <[email protected]> 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
>>> > [email protected]
>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > shifter-users mailing list
>>> > [email protected]
>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> [email protected]
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> shifter-users mailing list
>>> [email protected]
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>> _______________________________________________
>> shifter-users mailing list
>> [email protected]
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>
>>
>>
>> _______________________________________________
>> shifter-users mailing list
>> [email protected]
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> _______________________________________________
> shifter-users mailing list
> [email protected]
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>
>
>
> _______________________________________________
> shifter-users mailing list
> [email protected]
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
