Programming to multiple video cards
 

Hi,

I've browsed the internet, but haven't found a satisfying answer. Hope this forum can help me in the right direction.

I'm exploring the possibilities of creating a program that manipulates (writes to) two different video cards.

I program in C and hope to avoid high level libraries like Xlib to keep the mem footprint as low and the performance as high as possible. Windowing is not important no desktop environment will be used. Be able to write two pixels (one to each screen) to would do.

How would I go about?

To give an idea of the solution I'm looking for:

One screen will show thumbnails of images on the hard drive. Clicking an thumbnail on display A will show the selection full screen on display B. On a laptop; preferably thumbnails on the laptop screen and the selected image on the external monitor.

Is this possible with just low-level libs or do I need X or some third-party software to make life easy?

Thanx in advance,

Max

are you crazy?

I would hardly call Xlib high level.

;-)

Hi -

Actually, we were able to use three video cards in one PC with no problem. We used the standard X Windows/KDE that comes standard with SuSE. X automatically detected all three cards. The standard desktop came up on the first card. We simply set "DISPLAY=unix:0.0", "DISPLAY=unix:0.1" and "DISPLAY=unix:0.2" (for example).

No-level (or even medium-level) programming required: just set the "DISPLAY" variable to one X screen or another. Simple as that!

But it only worked with NVidia graphic cards: it did *not* work with ATI cards and any ATI drivers we could find.

'Hope that helps .. PSM

Yes, you can do this without X using svgalib or even pure C or asm using mode 13h if you want.
Of course, you'll have to manually handle the mouse input as well..

All,

First, thanx for the replies,

So I understand svgalib wil do?

To be exact: I'm writing one program for a well defined environment (hardware is known) with a minimum linux install. No desktop environment, just (on boot) starting up my program. This program outputs (graphical) information to two displays independently.

I'm wondering how to send information from one program tot two outputs (monitors). How to achieve this with svga lib? Any directions?

Using asm (13h) how would i tell the machine to use the secondary display instead of the first?

Max

Good point, switching between two cards is probably the hardest part. Probably using the old video bios is not really an option since nobody had multiple cards back then. I would take a look at directfb as well.

Supporting multiple video cards is *not* necessarily a given.

For whatever it's worth, I've seen it done in:

a) DOS (using much complicated register-level I/O, and copying parts of the video BIOS to RAM and hooking it, so that one card can be called independently of another)

... and in ...

b) X Windows, with relatively minor configuration (*no* special device-level programming).

And I've only seen "b)" with NVidia cards: ATI/Radeon cards did *not* work (even on the same PC).

I don't know one way or the other about svgalib or directfb: all I can say is that I've never seen it work except with X windows.

'Hope that helps .. PSM

Architecturally, Xorg & Xfree86 load graphics hardware specific drivers, and use those to create the X abstraction. One should therefore be able to use the same video drivers, and write to them in the same way that X does. It seems that these video drivers expose one or more standard API/frameworks, which you could then employ to write device-independent code to push pixels around on the hardware. There are a lot of video drivers in the standard Linux source distributions: '/usr/src/linux-2.6.XX/drivers/video', and from these, one should/may be able to divine what the APIs look like. It seems that the APIs/frameworks/interfaces occupy various layers, such as OpenGL and the previously mentioned SVGALib & DirectFB. These kinds of frameworks should allow you to access the graphics hardware without using X.

This sounds all more complex than expected. I figured this must have been done before, and even standard functionality for graphical libs: Write some graphics to screen (driver) one, switch driver/screen and do some more drawing. I wonder how advanced video editing/live VJ software do their thing? Don't they need one monitor for editing/controlling and one that functions as output to see the result simultaneously?
If direct driver access is the option how would I go about? Any direction? Or would you all advise using X for such software?

Max

What you are asking for, points to the purpose of the X Window System. If you substitute in your request, 'window' for 'monitor', then X provides what you ask for. Still, you may also be able to load drivers for two distinct video controllers (CRT Controllers, in graphics-hardware-speak), and operate them as distinct entities. X can do this, running two separate servers, one for each CRT controller. In principle, then, you should be able to do the same. Other libraries that provide a lower level abstraction, such as those that I and other have already mentioned, can be leveraged to provide some insulation from the hardware.
Is your software already written, with just the GUI elements left to connect, or are you architecting from ground zero? Do you intend to write a full GUI, or are you planning to use an existing GUI toolkit of some sort. If the latter, this will probably have a significant impact on the sphere of possibilities.
--- rod.

Max_r -

What theNbomr said is *basically* correct. One clarification: all you need is "X Windows". One server - you just configure it for multiple video cards. Simple as that.

Another clarification: multiple video cards can be tricky. But if you're lucky enough to find the right combination of hardware, driver and OS, maybe it'll "just work". Otherwise - if you *don't* get the right combination and it *doesn't* just work - you're probably in for a tough time.

In my experience, the combination of X windows and NVidia card and Linux driver will pretty much "just work". In my experience, most Windows configurations with NVidia, ATI and other major vendors will also "just work".

IMHO .. PSM

The only thing with X as a solution is that it violates the requirement of small footprint and high performance. I think the performance can be good, if the hardware has driver support for special hardware-based 'acceleration', and if your application is coded to use this. I assume the gaming community drives this, and I'm not one of them.
Further to what paulsm4 states, X can be the grand unifying force of multi-head video operation. However, there are different styles of support for multi-head, and different levels of vendor and FOSS support for these. For example, one can arrange a multi-head system such that it makes two (or more, sometimes) monitors behave as a single X server. This can come from multiple video cards with independent monitors, or from a single video card with multiple monitors. Conversely, the distinct video hardware can be operated as distinct X servers. Not all combinations of these from all vendors will work, but lately, the spectrum of support has become much better. Configuring X for this isn't always as simple as you might hope.
To Max_r: Is your project to be an embedded system style of application, or how will the user be expected to launch and use the software?
--- rod.

Hi,

The software is to be built up from ground zero. Were still in the design phase.
The software will not be distributed, but installed on one machine (hardware configuration is still flexible).
We want to built it embedded style. One starts up the computer and all one sees is the application. No other requirements, we just like to use the operating system for firing up the application, some "basic" (video) calls (to multiple screens ;-))and eventually some tcp/ip. Mouse input will only need to work on the primary display (and should not even be visible on the second).
We'll try x, since that's what you all advise. No previous experience in programming x, which was one of the drawbacks of using it. Maybe some good references?
Thanx for your input,

Max

If this is a commercial product, I strongly encourage you to look at Qt.

You don't need to program to Xlib; arguably you don't *want* to program as low as Xlib.

Whatever you decide to do - whatever platform, whatever library, whatever configuration - prototype early, and prototype often.

IMHO .. PSM

It sounds like you want an X server to drive one monitor, and program the other at a more bare-metal level. Toolkits such as the aforementioned Qt, GTK, and a handful of others provide a GUI framework/API, that includes user input devices such as keyboards and pointers. These toolkits are built on X as the underlying common support platform (although there are variants which do not rely on X, such as the GTK Framebuffer package).
On the 'second' monitor, you may choose to program at the Xlib level, but since it seems you are merely rendering graphics, you might consider a more direct method, for performance reasons. The Linux Framebuffer API would seem like a logical candidate, since most popular hardware has accordant driver support, and it probably provides good performance in most cases. These are lighter-weight, and are done using kernel drivers, but do not include GUI support; just what you need, by the sound of it.
--- rod.