I believe the 3.7.2-18 is broken for the nVidia FX5200 graphic hardware in the current Tumbleweed kernel/nouveau-driver.
When I boot to X window (LXDE desktop) with this driver, I obtain graphic corruption that makes the GUI not useable (although X does boot to a GUI with an unreadable kaleidoscope of colours). As noted there is a kaleidoscope of multiple colours with text difficult to discern and almost unreadable. I note booting with the ‘nomodeset’ boot code (to use the FBDEV graphic driver) still works and yields a proper LXDE GUI.
I tried the boot codes:
nouveau.nofbaccel=1
and
nouveau.noaccel=1
and neither makes any difference.
I have not (yet) tried the boot code “mem=2G” which some users note works for them when the nouveau driver is corrupted on older nVidia cards. My sandbox PC with the nVidia card only has 2G of RAM, so my initial view is that boot code is not relevant to the problem I have observed.
I also note that openSUSE-12.3 beta1 nouveau is ‘broken’ yielding the exact same corrupted GUI, ergo I believe this is an upstream problem with the kernel (or the nouveau driver or an associated library).
I just returned OFF of vacation and I’ve been sick, and I have not had the chance (strength) yet to raise a bug report on this.
I do note the nvidia FX5200 is very old graphic hardware and hence upstream support / fix for it may be difficult to obtain.
The Tumbleweed kernel version with the problem is the 3.7.2-18 default kernel (32-bit). Nouveau driver packages are:
libdrm_nouveau-2.4.33-2.3.2.i586
xorg-x11-driver-video-nouveau-0.0.16_20120321_ab7291d-3.5.1.i586
While an earlier 3.6.8-13-default kernel version worked with this hardware, I also note openSUSE-12.3 beta1 has a 3.6 kernel whose nouveau driver does not work. The Tumbleweed libdrm_nouveau-2.4.33-2.3.2.i586 and the xorg-x11-driver-video-nouveau-0.0.16_20120321_ab7291d-3.5.1.i586 worked with the older 3.6.8-13 kernel, so I am assuming the DRM library and nouveau rpm is not at fault (although that is a shaky skeptical assumption).
I don’t know enough about this technically to point the finger at the libdrm or the kernel. A search through /var/log/messages and /var/log/Xorg.0.log.old did not yield anything to me that pointed a finger to the problem.
Possibly next week, assuming I discover this has not already been reported, if I am better healthwise, I’ll write a bug report.