Thanks to the folks at nVidia who are diligently working on improving the problems in their drivers!!

Anyway, I’ve followed everything I could find on Lemma’s techbase pages and in the nVidia forums, but nothing has worked. Until now!

I’m running the latest beta from nVidia (177.78). I also discovered that for me, contrary to what everyone else seems to be saying, if I use InitialPixmapPlacement=2, performance is MUCH worse than if I use InitialPixmapPlacement=1. Using the benchmarking tools from the techbase page, I found that on the Penrose Tiling test, using Opera, the Canvas test would take up to 30 seconds for me if I did “nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1″ before running it. However, if I did “nvidia-settings -a InitialPixmapPlacement=1 -a GlyphCache=1″ instead, then the Canvas test only took around 2.5 seconds. WOW! So I added “nvidia-settings -a InitialPixmapPlacement=1 -a GlyphCache=1″ to my X startup script and was very pleased to discover that KDE 4.2 now is VERY usable on my little laptop!!! Again, HUZZAH!!!

For completeness, then, here is the Screen section  from my xorg.conf:

Section “Screen”
Identifier “Screen0″
Device “Device0″
Monitor “Monitor0″
DefaultDepth 24
Option “RenderAccel” “True”
#Option “RandRRotation” “True”
Option “UseEdidFreqs” “False”
#Option “UseInt10Module” “True”
Option “TwinView” “1″
#Option “TwinViewOrientation” “Clone”
Option “TwinViewXineramaInfoOrder” “DFP-0″
#Option “UseCompositeWrapper” “True”
Option “AddARGBGLXVisuals” “True”
Option “DisableGLXRootClipping” “True”
Option “DamageEvents” “True”
Option “TripleBuffer” “True”
Option “UseEvents” “True”
#Option “DynamicTwinView” “True”
Option “FlatPanelProperties” “DFP: Scaling = Centered; CRT: Scaling = Centered, Dithering = Enabled”
Option “OnDemandVBlankInterrupts” “True”
Option “PixmapCacheSize” “2000000″
Option “AllowSHMPixmaps” “False”
Option “BackingStore” “True”
#Option “NvAGP” “3″
#Option “ConnectedMonitor” “DFP”
Option “metamodes” “CRT: 1680×1050 +0+0, DFP: 1680×1050 +0+0″

SubSection “Display”
Depth 24
EndSubSection
EndSection

To be honest, I am not 100% sure which of the recently-changed variables in my setup have resulted in this improving so drastically–whether the new nVidia driver beta (177.78), the xorg.conf changes, or the InitialPixmapPlacement=1 change–but the end result is that I’m now able to use KDE 4.2 (trunk) quite happily and I’m thoroughly stoked about it.

Hope this helps some other poor soul out there. Oh–also, does it sound far-fetched that IPP=1 would work better for me than IPP=2??

This is a screenshot from within the Xephyr session, showing the 1600×1200 Xephyr display. The cool thing is that using ksnapshot from within the Xephyr session will actually capture the entire display, not just what fits on your host display. This is important for me because my laptop LCD display is only 1680×1050, so I can’t actually fit the entire Xephyr display inside my real physical display. Nice to know, definitely, since this means that I can create a monstrous Xephyr display that doesn’t fit inside my actual host display and still get full-display snapshots out of it. So what you see here is a KDE3 session spanning all 4 Xinerama heads. Kicker correctly only spans head 1. VMware Workstation is on head 2, in full-screen mode, but only full-screened on the second head. It can span more than 1 head as I’ll show further down.

To achieve this, I downloaded seli’s fakexinerama library, compiled it in ~/build/ like this:

gcc -O2 -Wall Xinerama.c -fPIC -o libXinerama.so.1.0 -shared
ln -s libXinerama.so.1.0 libXinerama.so.1
ln -s libXinerama.so.1 libXinerama.so

I then copied the real /usr/lib/libXinerama.so.1.0.0 to /usr/lib/libXinerama.so.1.0.0.real (make sure you backup your library!) and set up an alias in my ~/.profile so that I can easily switch on and off this fake xinerama library. When I start up my real host session, I don’t want to be using fakexinerama, but when I launch my Xephyr session for multimon development, I do need it to be there.

xin () {
if [ "$1" = "real" ]
then
sudo cp /usr/lib/libXinerama.so.1.0.0.real /usr/lib/libXinerama.so.1.0.0
elif [ "$1" = "fake" ]
then
sudo cp ~/builds/libXinerama.so.1.0 /usr/lib/libXinerama.so.1.0.0
else
echo “real or fake?”
fi
}

Here’s the contents of my ~/.fakexinerama config file:

#Configuration file ~/.fakexinerama
#
# The format of the file is rather strict. Lines beginning with # are comments. First line is one
# number, specifying number of screens. This line must be followed by this number of lines, each
# containing four numbers: X Y W H, i.e. screen’s X and Y origin, width and height.
4
0 0 800 600
800 0 800 600
0 600 800 600
800 600 800 600

This establishes a 2×2 4-head xinerama configuration. Next up is creating the Xephyr display. From within your regular host session:

Xephyr :2.0 -ac -br +xinerama -screen 1600×1200 &
xterm -display :2&

You should now have a single Xephyr screen that’s 1600×1200 pixels with an xterm running inside of it. Now switch focus to the new xterm window and turn on the fakexinerama library and start up a KDE3 session:

xin fake
startkde
# (and when you’re done with this little environment, make sure you return your system to sanity by running “xin real”)

That’s about it. Really cool stuff. One last little screenshot… This one shows VMware Workstation spanning multiple heads. This obviously works with real external monitors as well. The way it works is by clicking the little monitor button to the right of the “View” menu. This tells Workstation to cycle through the available display topologies. So, on first press, Workstation spread across all 4 heads (fullscreen multimonitor, largest topology). Second press took on this configuration that I screengrabbed (vertical span). Third press spread Workstation horizontally across the first 2 heads. And then 4th press returned Workstation to just fullscreen on head 2 (where I started it from).

One last thought on the subject… One of the things I’m hopefully going to be able to work on in the next couple of months is implementing the new EWMH _NET_WM_FULLSCREEN_MONITORS hint in various X window managers. Currently, Workstation does some internal gyrations to convince window managers to allow our undecorated fullscreen window to maximize over multiple monitors/heads. _NET_WM_FULLSCREEN_MONITORS was the hint that was recently added to the EWMH spec to correctly accomplish this, but as far as I know, it hasn’t been added to any window managers yet. I’m excited about getting the chance to get up to speed on some window manager internals again! It’s been a while since I’ve last had the chance to do that (bbkeys/blackbox days of yore!).

Anyway, hope this helps someone else set up a multi-head dev/test environment, should the need arise. =:)

First, Xinerama. I’m going to be doing multiple monitor stuff for work, which should be really interesting if I can keep my self-imposed stress level down. I have never had more than a single monitor to use on any given desktop or laptop until I started working at VMware, and as such I am currently less than clueful with how all of this stuff works in X. (As an aside, if anyone can refer me to some really good documentation or multi-head/multi-screen/multi-monitor/multi-display Linux/X resources, I’d greatly appreciate it!) So today I was looking into a bug report that had to do with a Twinview side-by-side display configuration, and I discovered that “xdpyinfo -ext XINERAMA” will tell you what the screen topology looks like currently. For example, my normal Twinview cloned 1680×1050 setup looks like this:

XINERAMA version 1.1 opcode: 158
head #0: 1680×1050 @ 0,0

… whereas if I change it to a side-by-side 1680×1050 configuration, I believe it will show this:

XINERAMA version 1.1 opcode: 158
head #0: 1680×1050 @ 0,0
head #1: 1680×1050 @ 1600,0

(I can’t be certain since apparently in all of my fiddling, I disabled Xinerama in my /etc/X11/xorg.conf file and currently, it shows me this: XINERAMA version 1.1 opcode: 158 head #0: 3360×1050 @ 0,0 *sigh*) This is coolness that I’m sure I’ll be needing to use frequently in the coming months.

Secondly, Modelines. Now, honestly, it’s been years since I’ve had to worry about manually putting Modelines into my XF86Config/xorg.conf files. X has gotten much better since those bad old days and things have pretty much Just Worked (TM). Although I still do fondly remember the days of working with some hard-core X hackers in trying to get my laptop display drivers working (like 10 years ago??) But somewhere between my Ubuntu 8.04 installation and my current OpenSUSE 11 installation, X no longer thinks that it should allow me to output a 1680×1050 resolution to my external monitor (a Dell 2007FPb). I disagree strongly. =;D Unfortunately, my Lenovo T61 laptop looks like crap unless it displays in its native resolution of 1680×1050, so in Ubuntu Hardy, I became accustomed to doing the cloned twinview 1680×1050 thing. Like I said, something broke this when I went to OpenSUSE 11. I’m guessing it’s a newer X version. But anyway, after a whole lotta Google action, I came across a post that suggested another dude use the “gtf” command to find a good X11 Modeline. Wow, cool!! Here’s what it does:

$ gtf 1680 1050 60

# 1680×1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline “1680x1050_60.00″   147.14   1680 1784 1968 2256    1050 1051 1054 1087   -HSync +Vsync

Awesome!!! I don’t know if this little tool didn’t exist back in the bad old days when X required you to enter this or if I just didn’t know about it, but this would have saved me lots of agony over the years had I known about it. =:) I copied/pasted that into my /etc/X11/xorg.conf inside the Monitor section for my Dell 2007FP, restarted X, and now nvidia-settings will kindly let me use 1680×1050 resolution again. YAY!