Question about X on the arm's.

[Gene Heskett]

On Monday 28 November 2016 21:43:54 Antoine Martin wrote:

> On 29/11/16 07:57, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 28 Nov 2016 17:03:17 -0500 Gene Heskett 
<gheskett at shentel.net> said:
> >> On Monday 28 November 2016 13:12:03 Alan Coopersmith wrote:
> >>> On 11/27/16 04:29 PM, Gene Heskett wrote:
> >>>> Okay Alan, I've had 3 or 4 folks over the last 36 hours claim
> >>>> that X is its own forwarding agent, why am I even using ssh?
> >>>> saying I'm not needing ssh at all.
> >>>
> >>> X can connect directly, but without the encryption & compression
> >>> that ssh adds when it acts as the forwarding agent.  ssh has been
> >>> the modern recommended solution for years - all major distros have
> >>> started X with "-nolisten tcp" for over a decade, and recent
> >>> versions of Xorg made that the default, such that you need to go
> >>> specify "-listen tcp" to enable the old direct TCP connection
> >>> method now if you want to avoid ssh.
> >>>
Unfortunately, I have told it to listen, but its apparently disabled 
internally.

I can launch it with this command line:

exec /usr/bin/X -listen tcp "@"
but when I look with htop, the option is shown as -nolisten tcp, so of 
course it doesn't work.  I'd like to take my walking stick and go 
calling on whoever made that choice because it saved 50k of object code.

That has now been pointed out as a bug on the droid forums. So we'll see 
how that goes over.

> >>>> So, where can I find the definitive tut on doing this because our
> >>>> attempts are failing?  What I was able to find on the xorg web
> >>>> pages last night was up to 3 major versions out of date.  I need
> >>>> a tut that deals with X11R7 and up.  Is there such a thing?  My
> >>>> google-fu is failing me.
> >>>
> >>> Our recommendation for X11R7 remote connections is "Use SSH X11
> >>> Forwarding."
> >>
> >> Which works but at very lethargic speeds. 3, 4 frames a second.  I
> >> need 20 or more. This odroid64, with at least 3 gpu's is said to be
> >> able to do a 4k display at 60 frames a second.
> >
> > that'd be simply display REFRESH. not actual rendering of content.
> > and forget REMOTE display over ssh over a bottleneck of a network
> > device. forget trying to get anything like high performance over a
> > network connection when it comes to display. don't even bother. it's
> > a waste of time.
>
> I beg to differ. An arm CPU certainly makes this more of a challenge,
> but it is not a lost cause... just don't use SSH forwarding, some
> tuning IS required.
>
> > if it displays at ALL - be
> > happy. to provide updated pixels at 60hz for a 4k display would
> > require a 16 GIGABIT network... with NO OTHER TRAFFIC on it at all.
> > and no network packet/protocol overhead. so let's make that 20
> > gigabit. that's assuming xputimage with 24bpp images (padded out to
> > 32bpp as that's how xputimage works). that does not account for
> > bottlenecks outside the network itself (the system at either end and
> > it's tpc/ip stack, kernel, memcpy's etc. etc.).
>
> I don't think the OP is trying to watch a 4K video over TCP, rather
> stating that his hardware is capable of pushing 4k at 60 pixels, which is
> why he was expecting better results.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>