Question about X on the arm's.

[Gene Heskett]

On Tuesday 29 November 2016 04:18:09 Antoine Martin wrote:

> >>>> If you exclude the 4k fullscreen video use case - which is a
> >>>> worst case scenario for remote display (there are tricks to deal
> >>>> with that too if you are willing to make sacrifices), then screen
> >>>> updates are actually much more manageable, even on a 1Gbps shared
> >>>> link.
> >>>
> >>> nope. not really. do the math. buy a few arm dev boards. :) find
> >>> out that you won't get 1gigabit. even 100mbit is pushing things.
> >>
> >> Even 100mbit is perfectly usable for remote access provided you use
> >> the right tools and make some sacrifices. FYI: 4K at 60 "fits" in H264
> >> ~60Mbps. But again, as I said above, just don't expect to handle
> >> fullscreen video on arm where *we* don't support hardware H264
> >> decoding. (though other tools might)
> >
> > but we're not talking video streams. we're talking x11.
>
> I believe the OP's requirement is to run an X11 application on one
> system and display it on the arm system, at a better framerate than is
> being offered currently by X11-over-ssh.

Slight correction, the application that is generating the image data, is 
running on the pi 3b, the system doing the viewing and control, is to 
run on the odroid-c2, which does have the gfx horsepower and memory to 
do it.

It also has 4 gpu's, which are so new that linux & X does not use them 
ANAICT. But I'd assume its the future for these arm based SBC's.

> Or at least, that's the angle I choose to see since that's exactly
> what xpra does ;)
>
> Seriously, we're not just a little bit proud of the fact that users
> have a relatively smooth experience with 4K monitors over 100Mbps
> connections considering that their display link will top 25Gbps.
> It took years of effort and we're finally releasing a v1.0 this week.
>
> > and with x11 to push
> > pixels across a network basically means xputimage and that means the
> > bandwidth requirements i have given (or sending the draw calls and
> > as discussed this is pretty much dead for various reasons).
>
> IME, users usually don't care much about what transport is used as
> long as the solution satisfies their requirements.

Precisely. Git-r-done at a usable/reasonable frame rate.

> >> And obviously, if you want lossless you probably aren't doing
> >> 20fps. At this point it is probably best to ask the OP exactly
> >> *what* he needs forwarded at 20fps.
> >>
> >>> the days where your clients upload some monochrome 1 bit bitmaps
> >>> and then just render with xfillarc/xcopyarea etc. etc. are kind of
> >>> over.
> >>
> >> Definitely over.
> >>
> >>> today data is 32bpp
> >>> with lots of new client-side generated data all the time and mopre
> >>> and more clients try and use opengl to get acceleration and speed
> >>> and that's really a local-only thing these days. yes i know of glx
> >>> indirect rendering. get that to work over a network to an arm
> >>> board which is egl/gles... :)
> >>
> >> Yes, that's exactly the use cases that we handle.
> >>
> >> Cheers
> >> Antoine
> >>
> >> http://xpra.org/
> >
> > xpra is its own display system effectively separate from x11.
>
> Sort of. Nitpick: Xpra is an X11 compositing window manager and we use
> a completely stock / unmodified / distro supplied X11 server, the
> clients are native however (X11, OpenGL, HTML5) and the wire protocol
> has nothing to do with X11 at all.
>
> Cheers
> Antoine
>
> > at least in terms
> > of display as x11 protocol supports no forms of compression (let
> > along lossy compression) of pixel data. xpra is a separate display
> > tech much like rdp, miracast, vnc etc. would be. :)
>
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


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>