The recovery mode likely is booting to either the vesa driver, or to the fbdev driver. In addition to ‘nomodeset’, it likely also has a parameter in its boot settings called ‘x11failsafe’ which is intended to force booting to a limited driver (probably the fbdev (basic frame buffer) graphic driver). The fbdev driver is typically compatible with all graphic devices, but as you pointed out its performance is slow.
I took a look at the factory xf86-video-savage-2.3.6-3.1.i586.rpm, and noted this in the change log:
oldcpu@corei7:~/temp> rpm -qp xf86-video-savage-2.3.6-3.1.i586.rpm --changelog
* Sun Sep 02 2012 zaitor@opensuse.org
- Update to version 2.3.6:
+ Make build with no xaa server.
- Changes since version 2.3.5:
+ i2c drop xf86Screens usage.
+ Port to new compat API
+ Refactor BIOS modes retrieval to call VBEGetVBEInfo only once.
Otherwise, calling it twice would trigger a VBE bug when using
xserver 1.12.
* Fri Jun 01 2012 sndirsch@suse.com
- remove hw supplements (bnc#764395)
* Wed May 23 2012 crrodriguez@opensuse.org
- Add proper "Supplements" so the driver is picked up by
the package manager when the user has the proper hardware.
and I then looked at the change log for the openSUSE-12.2 xf86-video-savage-2.3.4-4.1.2.i586.rpm
oldcpu@corei7:~/temp> rpm -qp xf86-video-savage-2.3.4-4.1.2.i586.rpm --changelog
* Fri Jun 01 2012 sndirsch@suse.com
- remove hw supplements (bnc#764395)
* Wed May 23 2012 crrodriguez@opensuse.org
- Add proper "Supplements" so the driver is picked up by
the package manager when the user has the proper hardware.
So factory has a Sun Sep 02 2012 update that openSUSE-12.2 does not have.
So if we assume that openSUSE-12.2 works with this hardware (and I do not know that as I do not have the hardware - someone with the hardware will need to confirm that) then that suggests that the 02-Sep-2012 update broke the driver.
I think a bug report is requried, but I also suspect that information on why the boot failed is needed for the bug report. There may be some information in the failed ‘Xorg.0.log’ file.
What you could do is boot normally. That will fail, but if it progresses far enough in the boot process, it will write the contents to a file called /var/log/Xorg.0.log.
So then reboot with the safe settings (which you called ‘recovery mode’ I assume). That will do 2 things (amongst many other things). It will rename the existing Xorg.0.log to Xorg.0.log.old. And it will create a new Xorg.0.log.
If there appears useful in the Xorg.0.log file, then attach the contents of the Xorg.0.log.old file to your bug report.
You could also copy the contents of the failed Xorg.0.log file to SUSE Paste , press create, and post here the web site URL, and some of our graphic gurus could take a look at it. But it may (or may not) yield sufficient information to help.