VNC - Extend Display - Multiple Displays (Local and Remote) - vnc

I have a project at work where we initially thought a remote HMI display would suffice for our application. The remote HMI display would connect to the industrial PC using VNC. The PC is running Windows 7 Professional.
We have since realized that we need both a local display and the remote HMI display. Each display would be running a separate application, hence the need to 'extend' the screen over multiple displays. Each operator would be interacting with one application (of course they would have to take turns).
VNC does not appear to support extending the display (for instance I know RealVNC does not).
Can anybody recommend a solution to this problem? I am attaching a diagram to help visualize my problem.
The remote HMI is no more that 50 ft away from the industrial PC.

Related

How to use my local mouse to control remote desktop

I want to develop a program on both Windows and Linux that can use the mouse that's being physically plugged into my machine to control the mouse event in the remote desktop which is a Windows OS.
I am a beginner so I would like to know how will this work, what do I need to learn before I get started.
For now, I am imagining that I need to firstly build a connection between my local device and a server and stay connected during the whole session using some kind of protocol. Then I need to connect my mouse to the remote mouse somehow through the driver? (Correct me if I am wrong).
This question is aimed to get some general idea of what components should this program have and what I have to learn before get started.
Thanks!

Forwarding display in batch context

I have Linux compute server A on which I would like to execute an application, say HV (I use this HV application to render a CAE model and capture the image). Eventhough I run this HV in batch mode, from putty terminal, it requires X windows. That is I need to run Xming and forward the display from server A, else it exits with error "No valid fonts - exiting". (In this case I am connecting to server A from my windows laptop using putty)
Instead of using Xming, the workaround I use is Xvfb. This works great in 90% of the cases. In the remaining 10% cases, few of the objects are not rendered in the captured image file.
Is there any alternate to Xvfb. There are few mention on net about Xdummy, but not much details. Or, it there any way to pass the relevant font, without forwarding the display?
My actual use case is, I have web application running on another Linux server, let us call it Server B. When I trigger the event from the client browser, the Server B connects to Linux Server A via ssh and executes the HV application. Even in this scenario, I tried ssh -X instead of just ssh for the connection between B and A. Still the application is exiting error "No valid fonts - exiting" if I don't use Xvfb.
We had the similar issue with xvfb not working consistent and contacted the vendor, their suggestion was to upgrade graphics drivers to the latest version. It did the trick. Xvfb created consistent size images.
Thanks,
anony

X11 networking on linux

I know you can connect to a remote X11 server to use them like a local X11 system.
My question is: Can you connect multiple computers to work together and display (through their videos outputs) an unique instance of X11 desktop?
Or, another phrasing: Can you process and display an image using several X11 servers?
Take a look at Distributed Multihead X Project
X11 is a protocol. If you use it over the network, the GUI application that you run remotely, actually connects to your local X11 server. So yes, you can have multiple clients running applications on the server that display on different X11 servers. As for processing images using X11 server - what do you actually mean by that? The only thing comes to mind is multiple monitors. If so, then yes - you can use a dedicated X11 server per monitor.
If I understood your question correctly, you want to have multiple computers collaborate on displaying a single X11 display. This is not directly possible.
However, you can have multiple video cards in a single computer and use the Xinerama extension to have the multiple cards show a single logical X server. This can allow you to use a single machine to drive several monitors with ease. (With video cards that support multiple outputs, you ought to be able to get up to four or six monitors without too much hassle. Dozens might be very difficult.)
I can't think of any mechanism that would allow a single keyboard and mouse to reliably work across multiple monitors driven by multiple computers. But if your problem is significantly restricted (if it really is just viewing an image via several X servers), then you could write a client application that renders only a portion of the image and run multiple clients that each display only a portion of the image -- that when taken together, looks like the image is seamlessly displayed by several systems simultaneously. This is definitely a bit awkward though, as the coordination of the system will require some thought.
If you want to drag windows from one screen to another, or display a part of a window here and another part of it there, then no, this is not possible with existing out-of-the-box software. You can try to modify a "virtual" X server such as Xephyr such that it uses multiple backend X servers for portions of its framebuffer. This is not exactly trivial but should be much easier than writing your own multi-box X server from scratch.
If you want to clone one desktop to many displays connected to different computers, you can try running VNC or RDP clients on all displays but one.

Excel programming module running slow on Terminal Server 2008

I have a Windows application that exports to Excel using the Excel Object Module (programming module). It has worked fine on all Winodws versions except Windows Server 2008. It takes about 2 seconds to do anything in Excel, making the process take minutes or even hours to complete what normally takes a few seconds.
This happens when using Terminal Services or RemoteApp. I discovered that it only happens when you check the Printers checkbox under Local Resources when connecting via Remote Desktop. If you uncheck it the speed is normal.
However, I need my printers, so I can't just uncheck it.
Any ideas what is causing the slow down?
The MS Office apps do a lot of calculation in the background based on the default printer. When you connect from a remote Terminal Services session and import the Printers from your Local Resources, the Terminal Server really needs to have an appropriate driver for each printer you're connecting.
Thus, one solution to the speed issue would be to ensure that the server has the right drivers (and that they work as expected).

X11 / X - linux desktop software, I don't understand how this fits together

I recently started using Linux (where I work is a Microsoft shop, so I only code in C#, work with MS products etc).
I'm trying to understand at a high level how some basic things in Linux hang together.
I've been reading www.linfo.org
Anyway I've never quite got what X is.
From reading this article it seems to me that X is layer that sits on top of the operating system (one X server sitting on top of the OS??) and X client applications make requests to the X server.
I think KDE, Xfce and Gnome are display managers, are they X server clients then?
I'm quite confused where everything sits.
Any explanation would be really appreciated!
It's all very modular and flexible; however this leads to complexity.
The "X Server" drives the display device. It provides graphics services to clients, and those services are pretty simple - such as:
"Give me a window frame to draw in"
"Put this bitmap here"
"Draw a horizontal black line 100px wide"
"Render the text 'hello' at (100,100)"
"Tell me if any mouse clicks or key presses have been aimed at my window frame"
There is a library called Xlib, provided by X, that has a standard interface for all these simple services. Any program that wants to use the X server's display eventually uses this client library and is called an X Client. Xlib knows how to connect to an arbitrary X server - on the local machine, or via TCP/IP across the LAN, or across the world - to call these services.
The Window Manager, which is just another X client program, is in charge of the "look and feel" of the desktop - how you move and arrange windows, etc. Because the window manager draws all the window decorations, it can make the desktop look like WindowsXP, or a Mac, or NeXTSTEP.
Part of the philosophy of X was to define "mechanism and not policy" - meaning, they give you tools to do it, but don't tell you how to use those tools. One such tool is the window manager, which can be replaced at will.
Many modern X applications are written to use a desktop enviroment such as Gnome or KDE. This offers these programs a consistent set of buttons and controls to draw, and a consistent interface for some things not traditionally included in X, but often considered part of a desktop - such as how to respond to drag-and-drop or how to present a standard file chooser dialog box.
The desktop environment usually provides an object model or programmatic interface that takes care of making all the simple X client requests and lets the program handle more important things. Removing these low-level calls yields another important benefit - platform independence.
Many desktop environments include a window manager, so that the look and feel of window controls and buttons is consistent and works with the desktop metaphor provided by the environment. However, it can usually still be switched out.
The separation of the X Server (running the display) and the X Client (wanting to use the display) has a few implications:
The graphics system is separate from the GUI programs, and they are separated about as completely as a web browser and web server are.
So the GUI program might not be displaying on the local machine - just like a web browser doesn't have to point at a web server on the local machine.
A machine can run JUST the client, with the X server elsewhere.
The machine with the display doesn't have to run the client - it can run JUST the X server, and all the clients can run on a dedicated machine. This is the original thin client: big programs running on big central server - with graphical user interaction handled by dedicated hardware on the desk in front of the user.
You need to know what your X server's network address is so you can tell GUI programs where to display their GUI. (this is usually done by setting the DISPLAY environment variable)
You can display many programs, from many different machines, all on the same desktop at the same time. It is all handled seamlessly, including cut-and-paste.
X11 is a network protocol, currently at release 7 (hence X11R7). It encapsulates graphics and input information, and connects an X client (application or window manager) running on a local or remote machine to the X server currently driving the local screen and input devices.
Gnome, KDE, XFCE, and LXDE are desktop environments; they contain pieces that talk to/with the X server (metacity, kwin, etc.), but also consist of specifications that applications must follow and libraries that are available in order for an application to "belong" to the DE.
In addition, it's worth remembering that the X server is just another program that gets run under linux. There's nothing special about it, it just happens to know how to grab onto the graphics card and take over the monitor using video drivers.
You can (theoretically) run linux very happily without ever running an X server - although of course, you would be limited to the command line programs.
That's how linux organises itself - kernel at the base, then a set of programs that provide functionality to higher level programs, which themselves provide functionality to higher level programs, all building up into a complete stack of software oriented to whatever the job of the machine is (say, general desktop, software development, web server, etc).
Beyond the kernel and it's modules, nothing is 'special'.
Wikipedia has some info about it.

Resources