Question about X on the arm's.
antoine at nagafix.co.uk
Tue Nov 29 09:18:09 UTC 2016
>>>> 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.
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.
>> 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.
> 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.
> 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. :)
More information about the xorg