Greg:
I assume you're asking whether the nano-X server and
an associated nano-X client application can run on seperate
computer systems, using the network to connect between them,
for display.
My board is an embedded board for research. (It is shown on my
website http://www.skutek.com/VME.htm.) The board will be doing
sophisticated signal processing where diagnostics will be paramount. Yet
it lacks any kind of graphics of its own. I was thinking of running the
histogramming package on the board, but how to watch the results? One
possible solution is that the graphics can be cast over the network to
another computer. That "another computer" will be a regular workstation
running either Windows or Linux. Thus, only my board will be running
nano-X. The receiving end will be a regualar workstation running whatever.
From the answers from Pete and Luca I gather that it will be possible to
somehow do this:
MY BOARD with Blackfin uCLinux DISPLAY,KEYBOARD,MOUSE
--------------------------------- |-------------------
histogramming and | LAN | workstation with |
data processing ---> nanoX | <-----> | screen, keyboard |
running under ucLinux | | Windows or Linux |
--------------------------------- --------------------
If this can be realised then nanoX would only be used on one end, while
the workstation end will be using regular Windows or Linux display.
I am trying to gather enough info to determine whether nanoX would be a
feasible solution as sketched above, or should I rather look into the
direction of embedding a web server on my board.
Concerning programming: I am actually more on the hardware side
(board design and FPGA programming) and doing software with only great
difficulty. I can promise digging into the code, but I cannot promise I
will emerge back alive from such a dive ;-)
Thank you,
Wojtek
On Thu, 14 Oct 2010, Greg Haerr wrote:
: Can Nano-X display on remote X-term, much like regular X would?
The current codebase uses UNIX sockets to connect clients
with the server. A named socket on the /tmp filesystem is used
for the connect() operation, and does not currently explicitly
support TCP rather than UNIX connections. It's not too much
work to add support for connecting to a remote socket rather
than local socket. I seem to remember somebody said they
wrote TCP connection support, but I don't have the patch.
If you're familiar with network programming using sockets,
I can help you should you want to add this support.
Regards,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org
