On Fri, Oct 15, 2010 at 12:38 AM, Michael Schnell <mschn...@lumino.de> 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). --------------------------------------------------------------------- To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org For additional commands, e-mail: nanogui-h...@linuxhacker.org
