Sunday, December 19, 2010

Multi-Monitor Support Forces More Use from Windows Partition

I've been struggling with multi-monitor support for a while now. I'm still not 100% satisfied, but I think I've got the best solution possible for my circumstances. I should probably share my system specs before I go any further..

CPU: Intel Core 2 Duo E8400 3 GHz
2 Nvidia GeForce 9800 512MB video cards
4 GB DDR2 RAM

This was what I wanted: SLI configuration, compiz effects, both monitors spanning 1 desktop (to drag windows from one monitor to the other), separate virtual workspaces for each monitor including different wallpaper.

The end result of much effort and several attempts is:

SLI simply does not work with a multi-monitor configuration at all. At least in any configuration I tried the 2nd monitor simply would not start in SLI. So if I wanted to use both cards, Twin View is not an option.

Separate X screen without Xinerama works but it was unusable for me as it caused some really strange things to happen. Nautilus windows just started popping up in the taskmanager and would not stop launching them until the system crashed. Until the crash, the two monitors worked however and compiz was enabled as well. With the separate X screens though, dragging windows from one screen to another was of course not possible.

I tried enabling Xinerama with the separate X screens, and this worked fine but for two things:

  1. No compiz effects. This was disappointing, but I could live with it.
  2. No KDE apps. Indeed, trying to start up any KDE application would cause the entire desktop environment to crash to the login screen. If I tried to log into the KDE desktop environment rather than Gnome, it would load and crash, again leaving me at the login screen. This I cannot live with as there are a few KDE programs that I just cannot live without.

That left with me with Twin View, which does work very well, except for 2 things:

  1. Separate virtual workspaces for each monitor are not possible. Xorg sees only 1 desktop , which means that each monitor must use the same wallpaper and switching virtual workspaces will cause both monitors to make the switch. It cannot be done independently.
  2. My second video card is now not being used. Now I would like to point out that SLI never worked very well anyway. Or I should say that it never worked very well when compiz was enabled. I actually switched to KDE briefly for this reason (I could have the plasma desktop effects enabled and SLI worked fine). I'm now really regretting going the multi-GPU route when I had this machine built. I wish I had just purchased one 1024MB card, but c'est la vie.

This current setup suits me fine for the most part. For graphically-intensive gaming however, I will have to rely on my Windows partition a little more than I do currently which is a real shame. I would like to point out that I believe blame can be laid squarely on Nvidia for lousy SLI support in Linux. In Windows I can have a multi-monitor setup with SLI enabled with no problems whatsoever. I know this has to be possible in Linux as well, but Nvidia just can't be bothered working it into the drivers. And they refuse to release the source code so that others may do the job for them.

I'll admit that compiz is not innocent here. But even with compiz disabled there is some discernible stuttering in the display when SLI is enabled.

This brings me to another point. when something quirky happens in Linux, it doesn't mean that Linux is quirky. It means that some software running is having some undesired results. To put this in perspective, lets look at some software that runs on Windows that has less than desired effects. Perhaps the most common that I see is umpteen-thousand toolbars that people for whatever reason install in Internet Explorer. It has the result of not only slowing down the browser, but with all the spyware that inevitably comes with it, the whole system slows to a crawl (and why the hell are you using IE anyway?)

I could bring up more examples obviously, but you get the point. In either of these cases, the OS is not to blame. It is either the software being run, or a configuration problem (well it's both in each case. The Windows example would include the configuration issue because if a guest account was used instead of the default administrator account, the spyware wouldn't be permitted to install).

But I digress. I didn't really mean to turn this into a Linux/Windows comparison. This was only meant to be a more personal post of my own experience.

If you have any experience with the issue I've described, please comment and if you have a solution I may have overlooked, please share it.

No comments:

Post a Comment