I shutdown Fedora, and booted openSUSE 11.3, standard kernel 2.6.34.7-5.1, and followed the Fedora procedure. The result: openSUSE working as designed on the Intel GMA (1600 x 900) !!!
Admittedly, each boot requires additional steps, as well as a bit of timing, but it works !!! And with desktop effects working as well! Now, this is currently a Gnome-only. Next step is adding KDE.
As to why this works, I can only speculate. It seems that power management is involved, and perhaps desktop switching.
The procedure followed to boot openSUSE 11.3 with an Intel GMA HD on an “Arrandale” processor:
Select the desired GRUB entry
Boot
After some brief display(s), the screen will go blank (usually black, without “backlighting”)
Wait until the boot is complete. (In KDE, a login sound should be produced. In Gnome, well I have not been able to make the Gnome logon sound work.)
Key ctrl+alt+F2 (switch desktops)
Close the lid (see note below). The original suggested wait was 10 seconds. It seems to not be time-sensitive.
Open the lid, and key ctrl+alt+F1, returning to the original desktop. Although this step supposedly returns to the actual desktop, I return to the command line. If this is so, key ctrl+alt+F7, and the desktop is presented.
Desktop effects are active, including animations. Power management exhibits some oddities: disconnect of AC line and switch to battery needed to complete the screen dimming before any further activity (keyboard and touchpad unresponsive), about 2 seconds. As to suspension (fka “suspend to RAM”), the suspension worked as expected, but awakening returns to the “black screen”. Repeat of the outlined procedure completes the restore satisfactorily.
A note regarding lid closure: the entire procedure is much easier by changing power management. Alter the “What to do when the lid is closed” from “Suspend” to “Blank Screen”. (Yes, I know that is exactly what we are trying to avoid!).
This procedure was discovered and confirmed on the following :
as well as with kernel 2.6.34-94.1, from the /Kernel:/HEAD repositories.
Further, the procedure was performed with the latest (that I could find) Xorg, from Index of /repositories/X11:/XOrg/openSUSE_11.3, with xorg-x11-driver-video @ 7.5-131.2, and xorg-x11-driver-video-intel-legacy @ 2.9.1-4.2 .
Prior to proceeding with the KDE install, I have some questions:
Should I re-install without the Xorg upgrade ? This would test the procedure with an OOTB platform.
The platform successfully tested was from an 11.3 liveCD (Gnome), which we know boots and completes the install without incident. Should this be tried with a DVD install ?
As to the “intervening” boot during installation, where this “black screen” has been reported in other threads: this procedure was performed during the install of Fedora 14, and recovered the display after the installation boot.
Interesting. Why “intellegacy” driver? Have you tried the boot workaround but with the “intel” driver?
Power management exhibits some oddities: disconnect of AC line and switch to battery needed to complete the screen dimming before any further activity (keyboard and touchpad unresponsive), about 2 seconds. As to suspension (fka “suspend to RAM”), the suspension worked as expected, but awakening returns to the “black screen”.
Also happens with my ThinkPad SL510, about 1 year old now, hmm.
Indeed, intellegacy is a red herring. Thats a 2.9.1 Intel driver, while from what I have read, one needs at least a 2.11 Intel driver. In fact, IMHO one could even delete the xorg-x11-driver-video-intel-legacy rpm and IMHO there would be no difference for the hardware in question on this thread.
Ignoring the already explained “intellegasy” thing, This does offer a potential explanation for a number of conditions that @SeanMc98 and others have experienced, eg, “can’t work ?, Then why does it work well from the liveCD?”
Thats something those with the actual hardware have to advise us. They are the one’s who can boot to the liveCD, and check the logs, and see what drivers and kernel modules are in place. And then they can compare those to the drivers and kernel modules that are in place when the system does not function correctly. Without their posting such information, its likely anything other view point is speculation.
Thats something those with the actual hardware have to advise us. They are the one’s who can boot to the liveCD, and check the logs, and see what drivers and kernel modules are in place. And then they can compare those to the drivers and kernel modules that are in place when the system does not function correctly. Without their posting such information, its likely anything other view point is speculation.
To my knowledge, the drivers and kernel modules are the same when running the liveCD as those used for a fresh install from that liveCD, If I am not wrong on this, then it is neither the driver or kernel (alone) that cause this. That leaves it open for other possibilities.
Another way to put this, is , if it can work from the CD drive, It can work from the hard disk! If not, why not! This is not a hard disk issue!!
If a driver (kernel module) doesn’t work, It doesn’t work, on CD or HD.
What is important is many users (most ??? ) will as part of the installation perform an update. As soon as they do that update, they NO LONGER have the same configuration as the liveCD. Often that installation update includes a kernel update, an xorg server update, and possibly driver updates. Hence typically the configuration IMMEDIATELY after an install is NOT the same as that of the liveCD. The ONLY way that I know to easily keep the same configuration (as the liveCD) after an install is to deliberately say NO to updates during the install.
My experience is most users, EVEN WHEN ASKED TO DO SO (ie asked NOT to update), are loathe to do so.
That is certainly true. We should invite users with potential hw problem to not perform an update after first reboot and check if everything is ok. It is not that simple though.
What is important is many users (most ??? ) will as part of the installation perform an update. As soon as they do that update, they NO LONGER have the same configuration as the liveCD. Often that installation update includes a kernel update, an xorg server update, and possibly driver updates. Hence typically the configuration IMMEDIATELY after an install is NOT the same as that of the liveCD. The ONLY way that I know to easily keep the same configuration (as the liveCD) after an install is to deliberately say NO to updates during the install.
My experience is most users, EVEN WHEN ASKED TO DO SO (ie asked NOT to update), are loathe to do so.
But from what I can tell its NOT updates causing this,
It seems that power management is involved, and perhaps desktop switching.
This seems closer to what is happening!
I offered kernel updates, xorg server updates, and driver updates as examples. Those are only examples. They are not the “be-all and end-all” (and no one says they are, but based on the quote in your post, I can’t help but get an impression that my point was missed). For the point was UPDATES and I can not say which update. Thats because I do NOT have the hardware.
If it works on a liveCD and if it does not work on an install it is because SOMETHING HAS CHANGED. IMHO it is NOT the hard drive. That IMHO is a MAJOR red herring. It is an update !
Take the graphics chip and integrate it directly into the CPU, and with all complications involved in doing so, Is it really a surprise that things don’t work as expected? (if the vendor chooses to not put the work in to support it) ! That does not mean there can not be a workaround !!!
At the last boot and install of the liveCD, I did NOT (per suggestion) perform any updates. In spite of persistent prompts, no updates were done at my behest, although I cannot speak for any updates done outside of my control. I can, however, say with certainty that NO network connection, wired OR wireless was active prior to, during and following the installation.
To recap:
Boot 11.3 liveCD (Gnome)
Display/graphics appears in correct mode (1600 x 900)
The driver was “intel”
Installation via click of desktop icon (not from the liveCD boot menu)
Installation completes without incident, with the normal remove liveCD/reboot
Boot of the installed configuration
At this point, the net result was the black screen (no backlighting). A re-boot with nomodeset presented a running 11.3, albeit with either the VESA or fbdev driver, at 1024 x 768 resolution. Up to this point, no updates were performed by me.
After this point, any and all updates were applied. Kernel was updated to 2.6.34.7-5.1. The result was no change in the display behavior. Absent any better suggestion or ideas, I ramped up the kernel to 2.6.34-94.1, with no change in result.
Following the posts referenced in the OP, I ramped up Xorg to the repo mentioned in the OP. No change in the display effects, or lack thereof.
I had been testing other distros, and found the workaround in the Fedora forums. The workaround was described earlier (post #3). Using this workaround, the installed configuration (i.e. NOT the liveCD) acted correctly, as described. With the exception of boot and login, the PC acts correctly in everything I have tested. (Gnome desktop effects are satisfactory, though not up to KDE qualities).
New development(s):
Boot to runlevel 3 is successful, responding to the same workaround(s). X - configure fails with a missing module, though that may be a problem with the factory Xorg.
If the installed system is placed in “suspend”, the black screen is re-presented. Simply CLOSING and OPENING the lid restores the display without the ctrl+alt+F2/F1 sequences. It appears that said sequences are only required at the login screen.
I updated the kernel to 2.6.37-rc2-1.1. This kernel has been highly touted for a number of reasons, including the Intel/Arrandale/Ironlake problem(s). This kernel exhibited NO change as far as the display. On an unscientific note, it did seem faster in many tasks.
I do not know the internals of the drivers, the kernel or X. I do believe, however, that the drivers in question must be correct, and believe that the problem(s) are related to power management (as well as the management of the Arrandale eDP facilities).
I have tested as much as I can in this Gnome-only configuration. The next step, as previously noted, is to install KDE. The only questions now are:
Do I install KDE on the now near-to-the-edge Xorg, or re-install the entire 11.3 ?
Do I reinstall from the liveCD, or (as I would prefer), the DVD ?
Do I add non-standard kernel(s) 2.6.34.7-35.1, 2.6.36.94.1 or 2.6.37-rc2-1.1 ?
Do I add the -factory or near-to-the-edge Xorg ? (Edited)
Do I let the installer perform the GRUB installation ? (The most recent install and current environment is using my Ubuntu GRUB2. I did this to eliminate GRUB from the boot problem(s), although it now appears that may not be the root cause).
Is there ANY way to completely disable Power Management ? I can disable some things in Gnome, a lot more in KDE. Specifically, I would like to disable action on lid closure PRIOR to login. This would allow the workaround WITHOUT the ctrl+alt+F2/F1 steps.
In summary, the workarounds are successful on openSUSE 11.3 (2.6.34-, 2.6.36.- and 2.6.37-), Fedora 14 (2.6.35.6-45) and LinuxMint 10 (2.6.35-22) kernels. Earlier kernels, such as 2.6.32 (Ubuntu 10.04.1 and LinuxMint 9) appear to function correctly, although now seem graphically slower than the later kernels.
(The graphics is perceptibly faster on the openSUSE kernels over the earlier kernels AND the 2.6.35 Fedora/Mint installs.)
If it works on a liveCD and if it does not work on an install it is because SOMETHING HAS CHANGED.
I recall looking into this, and there are differences in the way hardware is detected and the driver modules loaded, between the method used to load the liveCD, and the method used to install it, at least that is the explanation I was given.
That makes sence, and it would be useful to try and track down what those differences might be. Unfortunately I do not have the knowledge to provide good guidance here. Somewhere must be recorded the EXACT boot codes and exact configuration files that the liveCD uses when booting.
![http://thumbnails32.imagebam.com/10716/f09c47107150487.jpg[/size][/size]](http://thumbnails32.imagebam.com/10716/f09c47107150487.jpg%5B/size%5D%5B/size%5D){kind=link}