Matrox G450 Dual Head
Once upon a time Matrox graphics cards were marketed to people building everything from value consumer desktops to gaming rigs to high-end, PC-compatible workstations. Though even Matrox's fastest G-series has fallen far behind the competition in terms of raw 3-D performance, thus losing the gaming and consumer markets, they remain popular in the workstation market due to their reputation for stability, high-quality visual output and excellent Linux driver support. I will examine the Matrox G450 dual-head video card, with regard to both the usefulness of dual monitors and how well the G450 handles running two monitors. My test system is a 560MHz Pentium III supported by a 440BX chipset and 384MB of RAM running Linux Mandrake 8.0 (kernel 2.4.4 and XFree86 4.0.3). My video card is, of course, a Matrox G450 with one 360MHz RAMDAC, one 230MHz RAMDAC and 32MB of DDR RAM on board to drive two VGA outputs.
Having found X to be a common source of issues in the past, I wasn't looking forward to configuring this setup. Much to my surprise it was quite easy, with just one stumbling block--upon installing the card, Mandrake incorrectly recognizes the G450 as a G400. This isn't a big deal as they are very similar cards. After I had the card physically installed in the computer I went to Matrox's web site to download the latest drivers, choosing the Matrox-authored but closed-source binary version. The binary drivers are installed by simply dropping the two binaries into your /usr/X11/lib/modules/drivers directory. Updating your X configuration to reflect the new setup is similarly easy.
First, add one or two monitor entries (depending on whether your two displays are of different capabilities):
Section "Monitor" Identifier "monitor" VendorName "Unknown" ModelName "Unknown" HorizSync 31.5-57.0 VertRefresh 50-90 EndSection
Add two device entries for the G450, one for each port (see Listing 1). Then add two screen entries, again one for each port (see Listing 2).
Tell X how you want the displays to be logically oriented with respect to each other. Most people will probably want a horizontal layout. Also tell X that you want it to join the two displays together into one virtual display--I opted for two XGA screens so the resulting desktop will be 2048 x 768 pixels (see Listing 3).
Write the config to disk, restart X and you're done. Listing 4 is a complete copy of my X config, and Matrox's own documentation (ftp.matrox.com/pub/mga/archive/linux/2001/beta_1_2_0/readme.txt) explaining how to set this up is actually quite useful.
With Xinerama enabled the G450 handles the dual outputs quite well despite Xinerama's disabling DRI. The first visual artifact I noticed was a slow update if solid window dragging is enabled (via KDE in this instance) and a large window is dragged from one screen to the other. This really didn't bother me too much, but it has the potential to turn into more of an issue if one has a large window spanning both screens displaying animation of some sort. The other visual artifact stems not from the video card itself but from the monitors: because I used two similar 17" monitors and had them both running at the same resolution and refresh rate, there was a small amount of crosstalk resulting in a subtle grey band that slowly (approximately once per two seconds) but repeatedly progressed over each screen vertically (going up on one, down on the other). I found it to be vaguely annoying but really not much compared to the benefits of having two monitors (see next section).
I did try running dual displays without Xinerama, and this resulted in two separate desktops that shared little other than the mouse pointer. Logging into KDE resulted in two separate desktops; one came up with the usual compliment of toolbars and icons and the other with the toolbar but no icons other than the trash can. Windows could not be dragged from one screen to the other and due to this I found the configuration substantially less flexible and useful than Xinerama mode. Overall the G450 handled dual outputs just fine.
But is it really useful? In a word, yes. Being able to have not only two monitors going but to have them running off of the same login on the same machine is amazingly helpful. I found that I ended up switching between just three modes of use most of the time: lots of shell windows (six or eight) covering both screens, shell windows on one screen with web browser windows on the other and web browsers covering both screens.
The second configuration is how I use the machine most of the time, as it allows me to read documentation, etc., from the Web while I work at the command line or write. The first configuration came in a close second as it allows me to watch logs, IRC (I follow several channels on irc.openprojects.net from time to time) and read man pages, all while I work at a command line. The third I use mostly when I catch up on the news or when I'm researching a topic covered on many different web sites (comparison-reading). Other cool or useful suggestions I've heard of include: 3-D modeling, with blueprint view and toolbars on one screen and perspective/preview on the other; programming, with editors on one screen and debuggers on the other; running emulators, with the native environment on one screen and the emulated operating system on the other; network debugging, with command lines on one screen and tailed logs on the other; and watching a DVD on one screen while in IRC on the other (okay, so this is cool but really not useful).
There are truly a lot of things a dual monitor configuration is good for. There is only one major downside to any dual-monitor configuration; however, having two monitors on your desk consumes a lot of real estate. Unfortunately, there are really only two ways to work around this issue: get a bigger desk or get smaller displays (e.g., flat panels). Another (albeit minor) issue is that in a dual-monitor configuration certain default GUI behavior that makes a lot of sense on a single display doesn't make any sense at all. The most significant of these is that the once-convenient default placement of many dialog boxes and prompts in the center of the screen suddenly becomes very irritating due to the message being split between two displays. Despite these disadvantages, however, a dual-monitor configuration will undoubtedly be useful to many readers.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- The Secret Password Is...
- New Products
3 hours 30 min ago
- Keeping track of IP address
5 hours 21 min ago
- Roll your own dynamic dns
10 hours 34 min ago
- Please correct the URL for Salt Stack's web site
13 hours 46 min ago
- Android is Linux -- why no better inter-operation
16 hours 1 min ago
- Connecting Android device to desktop Linux via USB
16 hours 29 min ago
- Find new cell phone and tablet pc
17 hours 28 min ago
18 hours 56 min ago
- Automatically updating Guest Additions
20 hours 5 min ago
- I like your topic on android
20 hours 51 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?