Subject:
Re: [nanogui] Can Nano-X display on remote X-term
From:
Shawn Rutledge ####@####.####
Date:
15 Oct 2010 19:57:14 -0000
Message-Id: <AANLkTik+paykhVj2hE5ZPYMb=5gJO_b5CJZWP46tkgQQ@mail.gmail.com>
On Fri, Oct 15, 2010 at 12:38 AM, Michael Schnell ####@####.#### wrote:
> On 10/14/2010 10:18 PM, Wojtek Skulski wrote:
>>
>> My goal is the following: my new board is running ucLinux. It is a
>> VME board. It does not have its own display. But it has a gigabit
>> ethernet interface. I want to run an app which will popup a window on
>> a remote machine, either a regular Linux box or Windows. I do not
>> care, whether the remote machine is Linux or Windows. Can be either.
>>
>> I am probably confusing "server" with "client".
>
> You can run an X server on your PC This is the standard "Unix-type" way of
> doing a GUI. There are (free) X-Server programs for Windows, as well. The
> problem is that the PC is the server, so you need another network connection
> to the device (e.g. Telnet or SSH) to start the GUI program (this could be
> e.g. KDE) that will attach to the (remote) X-Server.
>
> "XMING" (e.g. for Windows) can automate this process so that the embedded
> device now seems to be the server to the PC-user.
>
> "NX" does this in a much more professional way (and additionally compresses
> and encrypts the X-traffic via SSH). So there only is a a single network
> connection
>
> With these solution you don't needs an X-server in the embedded device at
> all, but you do need a fully fledged Widget Set installation, unless you
> application uses the X-API directly instead of a standard Widget-based GUI
> API (such as GTK).
It doesn't seem like you have a shortage of processing power, and 128M
of RAM is not bad either. I wouldn't worry about the overhead of X.
To see an example of how small a system can be made which still runs
the full X server plus the apps, google the Agenda PDA: it got by with
as little as 8MB RAM. (It was quite slow to use, however, due to
having a 66MHz processor, and couldn't run too many apps at once due
to the memory. I bought one to play with, but it was not really
competitive with a Palm for everyday use.) There are lots of newer
examples: OpenMoko phones, Nokia N-series PDAs and N900 phone, Sharp
Zaurus series, Rigol oscilloscopes, etc. which really do have everyday
usefulness and can run more complex apps, even written in scripting
languages like python, and in OpenMoko's case even multiple widget
toolkits at the same time (but the OpenMoko FreeRunner has 128M RAM
and 400MHz processor).
So I think if I were you I'd install whatever widget set has a decent
API so that the developer(s) would enjoy working with it (I'm partial
to Qt, but Gtk is popular, and FLTK is more conservative if you are
really short on memory... that's what the Agenda used) on the VME
board and write your app(s) using that. Then to start the app for
testing/debugging purposes (from a Linux or MacOS client machine) is
as simple as
xhost +
ssh -X yourboard
/path/to/yourapp
and as it has been pointed out you can get an X server for Windows as
well (eXceed or perhaps a couple of free choices, if you can find
them). VNC and NX will also work just as well, except that in the
case of VNC there is a virtual framebuffer in memory on the VME board,
which is divided up into "tiles", and it simply sends an image to the
client machine every time the view within a "tile" changes. So it's
less complex for the client machine, but also not as nice in some ways
(tiles can be compressed using JPEG or a lossless algorithm; if it
uses jpeg, you are losing quality. If it's too slow due to network
speed or processing speed on either end, you can see individual tiles
getting updated. Better to reduce the graphical complexity, e.g.
don't use a desktop background image, so that there is less data to
send. Whereas with true X, fixed images (like backgrounds and icons)
become cached "resources" and don't need to be sent repeatedly, the
way tiles do every time an image is uncovered and therefore looks
different within that tile.)
Better yet, do all 3: VNC can be running, waiting for a connection,
and running a simple desktop environment (windowmaker, fvwm etc.)
where there is an icon to start your app; XDM can be running, waiting
for a plain X connection, and doesn't start the desktop environment
until somebody does connect; and nx can also run the same way,
accepting incoming connections. Then your customers will have lots of
options for client software. VNC also provides a java applet, so a
user with nothing more than a browser with Java support can connect to
your board, download and run the applet, and get a desktop session
inside the browser.
http://en.wikipedia.org/wiki/X_display_manager_(program_type)
I'd recommend testing all these options using distros that already
support them, on a couple of old PCs or something, just to get
familiar with how it all works and to prototype the connectivity
solutions and the desktop environment. Most distros will have
packages for xdm, nxserver and vncserver.
When you get around to developing your embedded system image, some
companies like to pay for support, so they like things like MontaVista
Linux, which is basically like an embedded cross-compiled RedHat: they
use the RPM package format. You have to pay a subscription to keep it
up-to-date. You can package your own app as an RPM too, which helps
to enable easy binary field updates. But you could also do the same
thing with any other distro that has an embedded branch, such as
Debian. Or, you can build a complete distro from scratch, highly
customized, using OpenEmbedded. This was the approach taken for
OpenMoko, and may be the best for keeping the size of the filesystem
down, although it's much more work to get going. It can generate
binary packages in opkg format (a bit like Debian packages but the
opkg manager is slimmed down for embedded work), so you can still
distribute binary field updates... but you are in control of every
package rather than depending on the distro maintainer. An older
system with the same goal as OpenEmbedded is buildroot (it was used by
GumStix, among others).
