That suggests KMS works from LiveCD, but KMS fails from HD installation thus eliminating “intel” driver, and using “fbdev” with its UMS and catch-all resolution set by Xorg. At this point did you (attempt to):
a) Inspect and/or keep the Xorg.0.log (preferably without nomodeset)
b) Configure your LCD and its resolution in the appropriate file in /etc/X11/xorg.conf.d/ and reboot
Apologies if the answer is somewhere in a previous thread/post. 
for a), The log is here SUSE Paste.
for b) I did nothing to the LCD nor any configuration(s).
Kde 4.5.3 installed. Testing on both kernels (2.6.34.7-0.5 and 2.6.37-rc2-1.1). Change(s) to KDE limited to unlocking the screensaver and setting(s) for graphical effects (System Settings → Application Appearance → Style → Fine Tuning).
Uneventful install, and testing well. Kernels noted above, Xorg at (or near) the -Factory, as posted earlier in this thread, No updates have been applied to Xorg, or anything else.
Boot still requires my posted workaround, which is a small task.
This may seem obvious, perhaps trite, but KDE is much richer and faster outside of either “Failsafe” mode or nomodeset boot. As to the graphics performance, I do not have Glxgears installed, nor have I ever installed it. Can I have a link or notes to download and install it ?
Thanks for posting the log. I am wondering if there is a problem at startup with DPMS. See the pastebin line (#161):
26.054] (II) intel(0): No DPMS capabilities specified
After the chipset is successfully probed and Gamma setting info, there is no DPMS info available, but exactly at that point, my GM45 gives:
24681.757] (II) intel(0): DPMS capabilities: StandBy Suspend Off
Following that, at pastebin #246
26.158] (==) intel(0): DPMS enabled
The driver has enabled DPMS, as it does on mine, but in your case with no DPMS settings specified in Xorg’s log.
Perhaps X cannot handle DPMS without some information, hence the blank screen.
I recommend you try turning off DPMS. You can do this by configuring an option of the Monitor section to be placed in /etc/X11/xorg.conf.d/50-monitor.conf, as explained in the man page for xorg.conf:
Option “DPMS” “bool”
This option controls whether the server should enable the DPMS extension for power management for this screen. The default is to enable the extension.
If you need help with the statements, post back and I will try to help you with an example.
I recommend you try turning off DPMS. You can do this by configuring an option of the Monitor section to be placed in /etc/X11/xorg.conf.d/50-monitor.conf, as explained in the man page for xorg.conf:
[QUOTE]Option “DPMS” “bool”
This option controls whether the server should enable the DPMS extension for power management for this screen. The default is to enable the extension.
If you need help with the statements, post back and I will try to help you with an example. [/QUOTE]
I have no experience at modifying Xorg. The section in question is (currently)
Section "Monitor"
Identifier "Default Monitor"
## If your monitor doesn't support DDC you may override the
## defaults here
#HorizSync 28-85
#VertRefresh 50-100
## Add your mode lines here, use e.g the cvt tool
EndSection
As I understand your suggestion, should the section look like
Section "Monitor"
Identifier "Default Monitor"
## If your monitor doesn't support DDC you may override the
## defaults here
#HorizSync 28-85
#VertRefresh 50-100
## Add your mode lines here, use e.g the cvt tool
Option DPMS False
EndSection
? Perhaps, the statement should be “Option DPMS 0” ?
On a related note, the original reported failure also occurs when booting “Runlevel 3”. Is it correct that in such a boot start, X is not loaded ? If X is not loaded, how would this section apply ?
Sean, try this, and note the quotes around the option parameters:
Section "Monitor"
Identifier "Default Monitor"
## If your monitor doesn't support DDC you may override the
## defaults here
#HorizSync 28-85
#VertRefresh 50-100
## Add your mode lines here, use e.g the cvt tool
Option "DPMS" "false"
EndSection
This is a bit of a long shot, but it’s the only thing that looks wrong in X’s log, and the LiveCD may not do DPMS either. If I was in your position I would try it.
KMS does the display mode setup early in the boot cycle, switching on the display, and switching from text mode to graphical mode (I think “when” depends on the distro’s implementation), anyway earlier than X did with UMS. Then at runlevel 3, X hasn’t really started, loaded its “intel” driver and provided a graphical login screen. That needs runlevel 5. You need a better alternative UMS driver e.g. “intellegacy”, but @oldcpu has explained the problem with that and your newer h/w.
Updated as described. While the change had no impact on the black screen symptom, the ancillary effects are significant. The desktop, formerly fast and smooth, now flies, the desktop effects are quicker (no intermittent hesitations) and new windows create and change remarkably faster. (To be certain, I backed the change out, observed, and repeated the change. Results as quoted.)
You may be on to something. After boot, then the black screen, I closed the lid without the keyboard ctrl+alt+F2/F1 sequences, reopened and watched the boot complete (scrolling lines, etc, prior to the presentation of the login screen). This simple lid closure/reopening is the same procedure in recovery after suspension/hibernation. I will continue to test these techniques, and post back.
I am trying to find another thread (maybe in the “Hardware” forum) that talked about this same Arrandale/Intel GMA HD coupled with another GA (switchable graphics). My recollection relates to a technique for disabling one of the two GA’s at boot, to avoid attempting to power both.
Thanks for the feedback. Glad it did something on the positive side. Just remember DPMS is disabled. Check Xorg.0.log and see if those two DPMS messages have changed, or if you notice anything else different in the log.
I am trying to find another thread (maybe in the “Hardware” forum) that talked about this same Arrandale/Intel GMA HD coupled with another GA (switchable graphics). My recollection relates to a technique for disabling one of the two GA’s at boot, to avoid attempting to power both.
11.3 will not load after the first reboot during install post #44 ?
Xorg.0.log contains (ca line 174)
33.889] (II) intel(0): No DPMS capabilities specified
No “DPMS Enabled” message(s) are found. This begs the 64,000-dineiro question(s): What is the downside of DPMS disabled, and what must be done to enable and configure DPMS ? There has been much message traffic and bug entries concerning reduction of power consumption by the display(s). Since the PC in question is rarely on battery (at least until these issues are addressed), power consumption is a non-issue at this time.
There are a few messages on the screen after the workaround, always
Starting udevd @
Configuring devicess @-@
These are entered from memory, as I can not find them in the various logs. In every case, the reopening of the lid shows those messages, followed with several more, prior to the login screen presentation.
Note glxgears should be installed by default. Start from command line.
Thanks! Here are the results:
sean@linux-kznz:~> glxgears
*** NOTE: Don't use glxgears as a benchmark.
OpenGL implementations are not optimized for frame rates >> 60fps,
thus these numbers are meaningless when compared between vendors.
284 frames in 5.0 seconds = 56.645 FPS
293 frames in 5.0 seconds = 58.451 FPS
294 frames in 5.0 seconds = 58.719 FPS
292 frames in 5.0 seconds = 58.240 FPS
290 frames in 5.0 seconds = 57.840 FPS
292 frames in 5.0 seconds = 58.236 FPS
295 frames in 5.0 seconds = 58.989 FPS
294 frames in 5.0 seconds = 58.673 FPS
288 frames in 5.0 seconds = 57.376 FPS
295 frames in 5.0 seconds = 58.918 FPS
292 frames in 5.0 seconds = 58.168 FPS
291 frames in 5.0 seconds = 58.110 FPS
294 frames in 5.0 seconds = 58.565 FPS
293 frames in 5.0 seconds = 58.510 FPS
288 frames in 5.0 seconds = 57.444 FPS
293 frames in 5.0 seconds = 58.332 FPS
293 frames in 5.0 seconds = 58.463 FPS
^Z
[1]+ Stopped glxgears
sean@linux-kznz:~>
I have no scales or standards to compare these results. I would hazard a guess that a non-integrated GA should fare somewhat better than these tests.
I am trying to find another thread (maybe in the "Hardware" forum) that talked about this same Arrandale/Intel GMA HD coupled with another GA (switchable graphics). My recollection relates to a technique for disabling one of the two GA's at boot, to avoid attempting to power both.
11.3 will not load after the first reboot during install post #44 ?
In regards to this, It seems unclear weather or not you tried that suggestion.
I know it seems unlikely to help, but then, some of what has already worked would also seem unlikely!
To enable DPMS you can use Monitor section in xorg.conf.d:
Option "DPMS" "true"
IIRC “true” is the default, so you can use just Option “DPMS”
It may be good idea to try that now, to see what difference if any. You can take a look at DPMS in System Settings>Advanced>Power Management, check out Capabilities and Edit Profiles.
Thanks! That is the thread, and I should have had greater clarity of recollection, as I had posted to it!
The reason that thread has been nagging at me is the hypothesis that the black screen problem (which seems to occur very early in boot up) is occurring during the driver loading. If I understand correctly, switchable | discrete graphics is controlled by the BIOS, and at boot, the Ironlake graphics onboard the Arrandale is in control. To determine if any other GA is present may require disabling of the onboard GA.
Since the workaround involves lid closure/reopening, Power Management is involved, and completes the recovery. Of course, this is speculation of the real ale and pipe-smoke brainstorming, and I have tried other speculative approaches, some with success.
Something that would be greatly desired: a keyboard function (ctrl +/- alt +/- anything that simulates lid closure/reopening. Such would save hands and wrists, as well as the hinges and inverter wires!
From an earlier post, you may remember I said:
You need a better alternative UMS driver e.g. “intellegacy”, but @oldcpu has explained the problem with that and your newer h/w.
Well I checked my Xorg.0.log with “intellegacy” driver loaded, and here are the relative lines:
24.805] (II) LoadModule: "intellegacy"
24.806] (II) Loading /usr/lib64/xorg/modules/drivers/intellegacy_drv.so
24.827] (II) Module intellegacy: vendor="X.Org Foundation"
24.827] compiled for 1.8.0, module version = 2.9.1
24.827] Module class: X.Org Video Driver
24.827] ABI class: X.Org Video Driver, version 7.0
24.827] (II) intellegacy: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
24.827] (++) using VT number 7
Talk about speaking from both sides of the mouth at the same time!
Also, the chipsets in red don’t appear in the man page (11.3) for “intellegacy”.
Arrandale does appear in the Xorg.0.log for driver “intel”, but it doesn’t appear in the man page (11.3) for driver “intel”, see here:
SUPPORTED HARDWARE
intel supports the i810, i810-DC100, i810e, i815, i830M, 845G, 852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME, G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, and Pineview-M in Atom N400 series, Pineview-D in Atom D400/D500 series.
Which one to believe? If the man page is right, Arrandale isn’t supported. Who knows. Comments, anyone?
BTW Sean, did you ever try “intellegacy” driver? If not, why not try, you have nothing to lose. If so, here’s how:
Make sure its separate package is installed on your system. To load “intellegacy” driver at startup, edit the file /etc/X11/xorg.conf.d/50-device.conf to add this line:
Driver "intellegacy"
For example:
Section "Device"
Identifier "Default Device"
#Driver "radeon"
## Required magic for radeon/radeonhd drivers; output name
## (here: "DVI-0") can be figured out via 'xrandr -q'
#Option "monitor-DVI-0" "Default Monitor"
Driver "intellegacy"
EndSection
Save, and reboot. Let us know the result.
With the “intel” driver (KMS), I get approx 62 FPS. So yours are in line with that, not bad considering Arrandale support is dubious.
With “intellegacy” driver (UMS), I get 537-695 FPS. Hmm, can’t tell the difference between the drivers with the human eye.
Re: “intellegacy” vs. “intel” drivers
My xorg.0.log shows
209.996] (II) Module** intel**: vendor="X.Org Foundation"
209.996] compiled for 1.9.2.901, module version = 2.13.901
209.996] Module class: X.Org Video Driver
209.996] ABI class: X.Org Video Driver, version 8.0
209.996] (II) LoadModule: "fbdev"
209.996] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
209.996] (II) Module fbdev: vendor="X.Org Foundation"
209.996] compiled for 1.9.2.901, module version = 0.4.2
209.996] ABI class: X.Org Video Driver, version 8.0
209.996] (II) LoadModule: "vesa"
209.996] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
209.996] (II) Module vesa: vendor="X.Org Foundation"
209.996] compiled for 1.9.2.901, module version = 2.3.0
209.996] Module class: X.Org Video Driver
209.996] ABI class: X.Org Video Driver, version 8.0
209.996] (II) **inte**l: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
4 Series, G45/G43, Q45/Q43, G41, B43, B43, **Clarkdale, Arrandale**,
Sandybridge, Sandybridge, Sandybridge, Sandybridge, Sandybridge,
Sandybridge, Sandybridge
209.997] (II) FBDEV: driver for framebuffer: fbdev
209.997] (II) VESA: driver for VESA chipsets: vesa
209.997] (++) using VT number 7
The intel driver is running, and it is from the ramped-up Xorg Index of /repositories/X11:/XOrg/openSUSE_11.3.
After I test the Options “DPMS” “true”, I will give the intellegacy driver a test.
Result of the Options “DPMS” “true” :
ca line 149
23.187] (II) intel(0): No DPMS capabilities specified
ca line 221
23.596] (**) intel(0): DPMS enabled
As to effect(s) on the black screen, active specification (i.e.: “true” or “false”) allows recovery via lid closure/reopen. Default (no specification) seems to require full workaround (keyboard entries and lid closure/reopen). (See finding below regarding the Login screen)
Additional findings:
Suspension recovery presents differently depending on desktop. Gnome requires the workaround, and KDE recovers directly to the KDE desktop.
If suspension occurs at the Login screen (Gnome and KDE), full workaround is required. This tested true for both gdm and kde DisplayManager(s), and gnome and kde WindowManager(s) (Default_WM).
Results of the Driver “intellegacy” test:
Xorg.0.log is found here - SUSE Paste. Net result was a “crash and burn”. Curiously, however, the result was a blank screen, as opposed to a black screen. This, in and of itself, is significant. The blank screen has active backlighting, indicating that the Ga and display are in contact. The black screen is basically nada.
The “burn” part was that the PC was totally unresponsive, requiring a hard power off/on to recover.
As to specification of Driver “intel”, as opposed to an empty 50-device.conf, the net effect was the same. The Xorg.0.log is shorter, as is the startup, and is pasted here - SUSE Paste.
Absent suggestions to the contrary, I plan on leaving the DPMS set to “true”, and revert the 50-device.conf to the default(s).
Possible next steps include:
Application of outstanding Xorg updates (4, and 2 ownership changes), outlined here - Drivers, Xorg Updates and Recovery, then retest. (One of the updates is to the Xorg Intel drivers).
Application of the “blacklisting” outlined here - 11.3 will not load after the first reboot during install. For this step, I need to know if the mkinitrd command recreates the initrd of all kernels (I have two), and will a backup of the current initrd(s) be of any value ? If necessary, I could restore such using the liveCD or Ubuntu.