I replaced the card with an older Sapphire Radeon X1950 Pro AGP 256MB dual DVI card, and it did not exhibit the same problem.  However, now when I moved windows over to the right side of the right monitor, they also overlapped the left side of the left monitor.  The X server defaulted to a desktop to 2560×1600, while my side-by-side monitors need 3520×1200.  Another tweak to the xorg.conf, and now it works correctly.  Also, the radeon driver supplied with Fedora 11 has 3D acceleration support for the X1950, but not for the HD2600, so I’m better off with the older card for now.

The updated xorg.conf is below.

# Xorg dual-head configuration
# monitors: Samsung SyncMaster 213T and Dell 2405FPW
# card: Visiontek Radeon HD 2600 Pro 512MB AGP Dual-DVI (RV630) or
#    or Sapphire Radeon X1950 Pro 256MB AGP Dual-DVI (RV570)
# Eric Smith 
# $Id: xorg.conf,v 1.2 2009/09/19 06:05:56 eric Exp eric $

Section "ServerLayout"
	Identifier     "Default Layout"
	Screen      0  "Screen0" 0 0
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
# keyboard added by rhpxl
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105+inet"
	Option	    "XkbLayout" "us"
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "radeon"
	Option	    "monitor-DVI-0" "Dell"
	Option      "monitor-DVI-1" "Samsung"
EndSection

Section "Monitor"
	Identifier "Dell"
	# Dell 2405FPW
	# Without the PreferredMode option, the X server
	# decides to use 1600x1200.
	Option "Preferredmode" "1920x1200"
EndSection

Section "Monitor"
	Identifier "Samsung"
	# Samsung SyncMaster 213T
	# The PreferredMode option doesn't seem to be
	# necessary here, as the X server picks
	# 1600x1200 on its own.
	# Option "Preferredmode" "1600x1200"
	Option "LeftOf" "Dell"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	Monitor "Dell"
	DefaultDepth     24
	SubSection "Display"
		# Without the following Virtual specification, the server
		# will default to 2560x1600 when using the Radeon X1950 card,
		# causing overlap of windows at the far right with the far
		# left.
		Virtual    3520 1200
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

One of my monitors has a native resolution of 1600×1200, and the other 1920×1200.  The X server for no apparent reason defaults to 1600×1200 on both.  I tried adding a modeline for the larger monitor, but it didn’t do anything.  Finally I found the PreferredMode option in the xorg.conf man page, and that did the trick.  My xorg.conf is below.

# Xorg dual-head configuration
# monitors: Samsung SyncMaster 213T and Dell 2405FPW
# card: Visiontek Radeon HD 2600 Pro 512MB AGP (RV630)
# Eric Smith
# $Id: xorg.conf,v 1.1 2009/09/18 10:03:47 eric Exp eric $

Section "ServerLayout"
	Identifier     "Default Layout"
	Screen      0  "Screen0" 0 0
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
# keyboard added by rhpxl
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105+inet"
	Option	    "XkbLayout" "us"
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "radeon"
	Option	    "monitor-DVI-0" "Dell"
	Option      "monitor-DVI-1" "Samsung"
EndSection

Section "Monitor"
	Identifier "Dell"
	# Dell 2405FPW
	# Without the PreferredMode option, the X server
	# decides to use 1600x1200.
	Option "Preferredmode" "1920x1200"
EndSection

Section "Monitor"
	Identifier "Samsung"
	# Samsung SyncMaster 213T
	# The PreferredMode option doesn't seem to be
	# necessary here, as the X server picks
	# 1600x1200 on its own.
	# Option "Preferredmode" "1600x1200"
	Option "LeftOf" "Dell"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	Monitor "Dell"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

Original posting below the fold.

I upgraded one of my machines from Fedora 7 to Fedora 9, and am now having font problems.  It is using a tiny font for the system font.  Here’s an example, using a newly created user to show that it is not a problem with a config file in a user’s home directory:

Fedora 9 upgrade fonts

I tried a fresh install of Fedora 9 in a virtual machine, and its fonts look more like what was used in earlier Fedora releases:

Fedora 9 fresh install fonts

On the upgraded system, I also can’t start emacs:

No fonts match `-adobe-courier-medium-r-*-*-12-120-75-75-*-*-*-*’

I went through the list of installed font RPMs (shown below), and don’t see anything missing compared to the fresh install in the virtual machine, so there must be a configuration problem somewhere.

Here is the output of “rpm -qa | grep -i font”:

baekmuk-ttf-fonts-common-2.2-6.fc8.noarch
cjkunifonts-uming-0.1.20060928-4.fc8.noarch
libXfont-devel-1.3.1-2.fc8.x86_64
libXfontcache-1.0.4-3.fc8.x86_64
baekmuk-ttf-fonts-gulim-2.2-6.fc8.noarch
libXfontcache-devel-1.0.4-3.fc8.x86_64
xorg-x11-fonts-Type1-7.2-3.fc8.noarch
libXfont-devel-1.3.1-2.fc8.i386
libXfontcache-1.0.4-3.fc8.i386
xorg-x11-fonts-misc-7.2-3.fc8.noarch
lohit-fonts-bengali-2.1.9-1.fc8.noarch
fontconfig-2.4.2-5.fc8.x86_64
lohit-fonts-tamil-2.1.9-1.fc8.noarch
mplayer-fonts-1.1-3.fc.noarch
fontconfig-devel-2.4.2-5.fc8.x86_64
paktype-fonts-2.0-2.fc8.noarch
jomolhari-fonts-0.003-4.fc8.noarch
xorg-x11-fonts-ISO8859-1-100dpi-7.2-3.fc8.noarch
lohit-fonts-gujarati-2.1.9-1.fc8.noarch
fontconfig-2.4.2-5.fc8.i386
bitmap-fonts-0.3-5.1.2.fc7.noarch
xorg-x11-font-utils-7.2-2.fc8.x86_64
lohit-fonts-punjabi-2.1.9-1.fc8.noarch
tetex-fonts-3.0-44.9.fc8.x86_64
libfontenc-1.0.4-4.fc8.x86_64
dejavu-lgc-fonts-2.19-1.noarch
sazanami-fonts-gothic-0.20040629-4.20061016.fc8.noarch
lklug-fonts-0.2.2-5.fc8.noarch
libXfontcache-devel-1.0.4-3.fc8.i386
xorg-x11-fonts-truetype-7.2-3.fc8.noarch
lohit-fonts-hindi-2.1.9-1.fc8.noarch
lohit-fonts-malayalam-2.1.9-1.fc8.noarch
kacst-fonts-1.6.2-2.fc8.noarch
xorg-x11-fonts-100dpi-7.2-3.fc8.noarch
fontconfig-debuginfo-2.4.2-5.fc8.x86_64
liberation-fonts-1.0-1.fc8.noarch
lohit-fonts-kannada-2.1.9-1.fc8.noarch
libfontenc-devel-1.0.4-4.fc8.x86_64
lohit-fonts-telugu-2.1.9-1.fc8.noarch
libXfont-1.3.1-2.fc8.i386
ghostscript-fonts-5.50-18.fc8.noarch
libXfont-1.3.1-2.fc8.x86_64
lohit-fonts-oriya-2.1.9-1.fc8.noarch
libfontenc-1.0.4-4.fc8.i386
mathml-fonts-1.0-21.fc6.noarch
urw-fonts-2.4-3.fc8.noarch

With Fedora Core 5, FreeNX is available from “extras”, so you can just say “yum install freenx” on your remote host. (I almost used the word “server”, but in terms of the X window system, the server is the machine running the display, which is the local machine.) The package installation handles most of the configuration, but there are still a few minor chores remaining. Some (but not quite all) of them are documented on Rick Stout’s “HOWTO setup Freenx on Fedora” page. I’ll get to the details later.

If you’re using a Fedora release earlier than FC5, Rick supplies RPMs, but they are based on the NX 1.5 core, and only work with the NX 1.5 client. Unfortunately it appears that NoMachine only distributes the 2.0 client now. One of the remote machines that I need to access via NX is running Fedora Core 3. I ended up rebuilding the FC5 Extras SRPMs under FC3, with a few minor changes to the spec file. I can make the spec, SRPMs, or i386 RPMs available if anyone needs them.

When you configure a connection using the local nxclient, you must put in the DSA key that was generated on the remote nxserver. Rick’s page shows how to do that. But you also have to “unlock” the nx user on the remote host, with “passwd -u -f nx”. And the SSH server on the remote host must be listening on the loopback address as well as a public IP address. Usually that is the case, but my remote host acts as a server for many virtual domains, so I had configured the SSH server to listen on only a single IP address. I had to change the configuration to make it also listen on 127.0.0.1.

When using FC3 on the remote host, you have to change the client configuration to use a custom session rather than a GNOME session, though you can run GNOME. Rick’s page explains that. But there is also a problem where starting Emacs as an X client gives an error ‘Undefined color: “black”‘. jugboy ran into this problem with a different X distribution, and wrote about how he solved it. Unfortunately his solution does not seem to work on FC3, because the rgb.txt file actually is in the place nxagent expects it.

Aside from that, it is working fine for me with the NoMachine NX client on FC5. But when I try to connect to either the FC3 or FC5 remote machines from Windows, it connects then reports “Authentication failed for user esmith”. The “Detail” button is grayed out, so it is completely non-obvious what is going wrong.

I very much appreciate that the fine folks at NoMachine released the server source code (and library source code) under the GPL. But it would be nice to have a GPL’d client program as well. Apparently 2X has just released one for Linux, so I’ll have to give it a try. I wanted to download the source, and their web site allows browsing their Subversion repository online (via Trac), but it is not clear how to connect from a Subversion client.

ATI and NVidia will not open-source their drivers for X.org, the open-source X server used on most Linux systems, nor will they publish documentation allowing third-party drivers to be written. NVidia seems outright hostile to open source, for reasons that are unclear. Both companies have claimed that they don’t want competitors to be able clone their chips, but neither an open source driver nor documentation would help that happen. Those graphics chips contain hundreds of millions of transistors, and knowing the register-level interface to the chip doesn’t make cloning easy. If it did, there would be many companies making Pentium 4 equivalent processors, because the x86 documentation is publicly available. But in actuality, only one company (AMD) has managed to make an x86 processor that can compete with Intel on performance, and they’ve taken many years and hundreds of millions of dollars to do it.

Via, S3′s parent company, has said that they will not release their X driver as open source, but according to a Linux Today article, the reason they give is that releasing source code would show their competitors the workarounds for flaws in their chips, which the competitors could use as marketing ammunition. They point out that all complex chips have flaws; Intel and AMD actually publish errata lists detailing the flaws in their processors, so it is not surprising that graphics chips should also have flaws.

However, IMNSHO it is silly to think that ATI or NVidia would do that, or that consumers would fall for it if they did. AMD and Intel don’t use each others’ errata lists for marketing deriding each others’ products. And if Intel said that you shouldn’t buy an AMD CPU because of some minor errata, wouldn’t you take that with a grain of salt, and question Intel about their own errata.

I think the real reason Via isn’t releasing the driver as open source is that keeping it closed is the path of least resistance. Until we (the open source community) convince them of the benefits to them of open source, it is easier for them to keep it closed, and make up silly reasons for doing so.

If they did release the drivers as open source, it would benefit them at least two major ways:

• They would capture a significant number of Linux and xBSD users that currently buy ATI and NVidia products because there is no open source alternative
• They would get third party developers contributing enhancements to the drivers back to them

As X and Linux users and developers, we should try to convince S3/Via that there is a lot of upside to open source for them, and very little downside.

I don’t know of any direct contacts at S3 or Via that we should contact, but it may make sense to send a polite email to their Sales and PR/Marketing departments. The email addresses are on their contacts page.

lcdtest was able to do that, but you had to type the five key sequence “wv0–” to get it. So I’ve added the command “a” to do it with a single key.

I also added command line options to list the available video resolutions, select a resolution, and get help. There’s a new option to display in a window, intended for debugging and example screenshots.

I now consider the program to be feature complete, so the new release is version 1.00.

Anyhow, once I got FC3 booting again, I tried switching from the Sapphire Radeon 9200 card to a Sapphire Radeon 9550SE card. That solved the problem. The software thinks that it’s a Radeon 9600 AS, using an RV350 AS chip, but it works great.

I was really hoping to stick with the 9200 because it has open-source 3D support, while the later cards don’t. But I’m not actually using 3D, so I guess it doesn’t matter.

I’m still surprised that this problem hasn’t been widely reported. I wonder if the bug only occurs on 64-bit processors (in 64-bit mode)? I’m running on an Athlon 64 3500+.

I thought it might be a bug fixed in later Fedora Core 3 errata, but xorg-x11-6.8.2-1.FC3.13 does the same thing.

There is no sign of any bugs filed about it in Red Hat Bugzilla.

I’ll probably try Fedora Core 4 test 2 tonight and see if it’s any better. If not, I bought a Sapphire Radeon 9550 card to try, though I’d rather stick to the 9200 since that was the last ATI chip to have open source 3D support. (Not that I use 3D at all.)

The Samsung LCD came with a six foot DVI cable, but the way I have the computer positioned I need a slightly longer cable, so yesterday I bought a “DVI Dual-link Digital + Analog” ten foot cable. Turns out that I can’t use it; the monitor’s DVI jack won’t accept the keying and pins for the analog part. Apparently I need a DVI Dual-link Digital cable without analog, so I bought one of those today. These DVI cables are a lot more complicated than they should be.

A friend gave me a Monster Cable DVI400 “High Bandwidth All Digital Video Interface with Gas-Injected Dielectric for Highest Quality HDTV Picture” 6-foot DVI cable a few weeks back. It has a $99 Fry’s tag. I don’t ever buy Monster Cable myself, as I think it’s just grossly overpriced snake oil. That’s especially true for DVI cables; the back of the packaging shows two images that they claim are with their DVI cable and some other DVI cable, with muted colors on the other one. I don’t believe that for a minute; in fact I think it’s probably completely fraudulent. Unlike analog signals, the digital signals are either going to work correctly, or they’re going to cause much worse problems than muting colors. Anyhow, the cable apparently isn’t useful with the Samsung LCD monitor since it’s only a single-link cable.

I thought I’d try to count bad pixels. A Google search turned up various LCD test pattern programs for Windows and MacOS, but none for Linux. So naturally I thought I’d whip up a quick hack to fill this void.

lcdtest uses SDL for full-screen display, and in principle should work on other operating systems as well, but I’ve only tested it on an Athlon 64 running Fedora Core 3 Linux.

My vision isn’t quite as good as it used to be. I can’t easily focus on things relatively close to my eyes any more. With the Nokia on my desk, the keyboard barely fits in front of it, and lately I’ve had to sit further and further back from it, which is a real nuisance. Otherwise I get eye strain very quickly. Because of this, I haven’t spent much time on my personal projects lately.

With the Samsung 213T, I can easily have the monitor face 18 inches back from where the Nokia face was previously, which is much more comfortable and avoids eye strain. Since it’s an LCD, it also isn’t subject to the moire patterns that CRTs display when pushed close to their limits. I used the Nokia at 1600×1200 resolution. It was capable of more, but at that resolution it was not possible to completely eliminate moire patterns from a dithered gray desktop.

My first LCD monitor was a 14″ Panasonic AL-D40 purchased as a grey-market import before LCD computer monitors became commercially available in the US. I bought it at the Sunnyvale T-Zone store (RIP). T-Zone is a Japanese chain, so the store carried quite a variety of items not normally available in the US. That’s where I got my Japanese Toshiba Libretto 50 laptop, six months before the US model was available.

Anyhow, on the Panasonic, there was only an analog VGA input, and the auto-setup feature didn’t do a very good job of getting the pixel timing and phase configured. I was able to do slightly better with the manual controls, but never got it perfect. So one of my requirements for a new LCD monitor was a digital (DVI) input.

My current video card is a Saphire card using a Radeon 7000 chip. I bought it because it was inexpensive (under $40), and because ATI had better open-source 3D support for X (Linux) than NVidia. However, it does not have a DVI output. I’m currently using it with the Samsung, and it works fine.

When I first booted Linux using the Samsung LCD, each time the video mode was changed (during the boot process, before the final X video mode), the monitor displayed a message stating that the video resolution wasn’t optimal. Pressing a button on the monitor makes the message go away. But I was surprised to find that even once X started, using 1600×1200 resolution, I still got the message.
The picture was quite good, though not perfect, and running the auto-setup improved it somewhat.

Eventually I figured out that they really were serious that the maximum supported vertical refresh rate is 60 Hz. For the Nokia CRT I was using 75 Hz; on the CRT anything less than about 65 Hz resulted in a flicker I could see out of the corners of my eyes. With an active matrix LCD, though, the refresh rate can be much lower without noticable flicker. I changed my /etc/X11/xorg.conf file monitor sectoin to say “VertRefresh 50.0 – 60.0″, restarted X, and that made the monitor happier. I’m somewhat surprised that X was not able to determine the monitor characteristics automatically with DDC.

Now that I’m using 60 Hz refresh, the auto-setup did an excellent job. It’s still not absolutely perfect; the dithered grey of scroll bars sometimes shimmers. I expect using the DVI digital interface will fix that.

The Samsung will pivot into either the landscape or portrait orientation, and comes with Windows software to support that. Since I don’t use Windows, I searched for information on how to do the same thing with X. As it turns out, this uses the X Resize and Rotate Extension (RandR). There’s a command line utility “xrandr” which is used to control it; without arguments it will list the resolutions, rotations, and reflections the X server claims it can support. The X.org server does support the RandR extension, but the Radeon driver will only allow it to change the display resolution, but not rotate or reflection, at least with the Radeon 7000 chip. Maybe with newer chips it is supported? I wasn’t able to find much information on it even with Google.

I shopped online for an ATI-based card with a chip no newer than the Radeon 9200SE, which is the last ATI chip for which open-source 3D acceleration is available. (C’mon, ATI, get with the program again, please!) I ended up ordering a refurbished OEM 32M Radeon 9200SE card with DVI output for $40.60.

Newegg offered to ship the package to me by Fedex Saver shipping for the princely sum of $1. Fedex picked up the package from Newegg in Santa Fe Springs, CA on Friday, took and took it to Los Angeles. Early Saturday morning it arrived in Oakland, then was sent to Portland, OR. I find this amusing because Oakland is only about 40 miles from the destination. But Fedex has it scheduled for delivery on Wednesday, so I’ll just be patient. For $1, I can’t complain.