tomhudson's Journal: Quick fix for anyone using dual screens and Opensuse 12.1

In preparing to migrate from linux to freebsd after the failed in-place update from opensuse 11.4 to 12.1, and the subsequent fugly clean install, one thing I noticed was that /etc/X11/xorg.conf has been replaced with 10 different files under /etc/X11/xorg.conf.d/.

What this means is that all your utilities for configuring your dual monitors, such as nvidia-settings, don't have a clue as to how to save this new format. Sure, you can run it each time you log in, but that's a real PITA, requires root, and it might not be something you want if you share a computer with others.

Quick fix:

1. log in as root
2. mv /etc/X11/xorg.conf.d /etc/X11/WTF.xorg.conf.d
3. run nvidia-settings and have it save a conventional xorg.conf file as /etc/X11/xorg.conf

This should also work, mutatis mutandis, if you have a backup copy of xorg.conf for an ATI or other card.

When you have less than 1% market share, you either don't pull s*** like this, or you provide tools to bridge the difference. Video is not like a web server - the migration of the apache config file to a bunch of sub-directories, while it was messy, was safe to assume a certain level of user technical acumen - and if in the meantime the server didn't start, it's not as frustrating for the average desktop user as a dud graphics sub-system.

And that's really new to you?

[jawtheshark]

For the record. I did this and it only works if your keyboard is US, because the xorg.conf defaults to that with nvidia-settings and changing it is a major pain. Me? I just run nv-settings (or whatever it's called, I type "nv" on Ubuntu Unity) which launches some kind of application where you can define the monitor. If you run it as root it even offers you to save the xorg.conf file (which I never do because of the US keyboard problem). So, gksudo nvidia-settings (or whatever it's called) and you can d

Re:

[tomhudson]

The problem is the new format of the file. There is no xorg.conf file any more ...

And my answer now is "Use Vista, since it does work and will continue to do so, but also install FreeBSD and hope that it hasn't been affected by the crapification of the linux desktop world." :-)

If that doesn't work out, who knows ...

Re:

[jawtheshark]

Actually, that is quite incorrect. The absence of the xorg.conf file means that it should detect the hardware at each startup of X. If you have it, it will take priority. It has been like that somewhere since the beginning of Xorg. In the beginning obviously not, because it was a fork from XFree86.

I do have a xorg.conf file on this machine. It's Intel graphics, and I can get full resoltion in my session without xorg.conf by using the gnome-display-properties application. (And it saves it, without troub

Re:

[tomhudson]

gnome-display-properties is not really a solution. Uninstalling tracker (the cpu-sucking indexer) also removed gnome. The package manager now reports there's no gnome-display-properties. BTW - before removing tracker, I tried to just disable it, but kill -9 'ing it doesn't work (and I didn't feel like wasting time looking around), the gui tool had 2 tabs that didn't work, and clicking on the checkbox that *did* work didn't do anything that I could see, so rather than waste more time, I just uninstalled tra

Re:

[jawtheshark]

My experience tells me that gnome-display-properties only works with open source drivers (preferably Intel). Once you go proprietary, you must stick to nvidia-settings or catalyst.

I think that is an XOrg thing, not a SuSE thing

[damn_registrars]

While SuSE is far from perfect, I think what you're seeing is just them adopting the new XOrg config file standard a little earlier than some of the other distros. It wasn't that long ago that the xorg.conf file moved from a different location to where it is now (and before that it was XF86Config, which was written differently by two very different programs that claimed to do the same thing).

And of course, eventually XOrg will break all backwards compatibility with the other /etc/xorg.conf file and then

Re:

[tomhudson]

I think that the proper way to implement something like this, if you *really* wanted to use multiple files to store the configuration, would be to regenerate a new xorg.conf file any time you modified the individual configuration "source" files. That would result in fewer files to open+read+close during the boot process.

10 files here, 20 files there, soon enough you've made a serious dent in the number of files you need to open, and you get the benefits of having each "source" configuration file being fo