ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
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.
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?
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.
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?
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.
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".
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?
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,
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.