Adding GRUB_GFXPAYLOAD=text to /etc/default/grub tries to over-ride the
variable set gfxpayload=$linux_gfx_mode in 10_linux where GNU says that
if set in the/etc/defau;t/grub :
## QUOTE ##
GRUB_GFXPAYLOAD_LINUX'
Set to `text' to force the Linux kernel to boot in normal text
mode, `keep' to preserve the graphics mode set using
`GRUB_GFXMODE', `WIDTHxHEIGHT'[`xDEPTH'] to set a particular
graphics mode, or a sequence of these separated by commas or
semicolons to try several modes in sequence.
Depending on your kernel, your distribution, your graphics card,
and the phase of the moon, note that using this option may cause
GNU/Linux to suffer from various display problems, particularly
during the early part of the boot sequence. If you have problems,
set this option to `text' and GRUB will tell Linux to boot in
normal text mode.
## END QUOTE ##
Which later in 10_linux checks $linux_gfx_mode and if set to text tells
the kernel not to boot graphics... (translation)
This is a "WORKAROUND" telling the kernel not to use the GRUB_GFXMODE to
set GFXTERM and not use KMS. This workaround, in essence does the same
as 2 other workarounds of rolling back the kernel to 2.6.37.x or to roll
back the version of Grub 1.99 to GNU Grub 1.98, in that they both them
would ignor the GRUB_GFXMODE call.s All three of these workarounds
circumvent around the present process by crippling it or ignoring it.
A correct and closer Workaround is to set the parameters of GRUB_GFXMODE
and pass them using KMS and the designed process... Which is working as
a viable workaround out on the Support Forum. Setting the parameters of
the video hardware and monitor manually as a workaround and having it
work correctly, tells me the process does work, but it ia apparently s
not being set up correctly with the right data.
So the real question is: What is the process that VBE is using to query
hardware when GRUB_GFXMODE is set auto? HAL? VBEPROBE / VBEINFO? Then
we can check what in that process is passing bad parm's or locking up
hardware. Whatever this process "IS." this does seem to be where this
problem seems to begin.
If you leave this as saying that is "the fix." then you are saying that
GNU Grub 1.99, the Linux 2.6.38.x series kernel and Xorg X11R7.6 are all
broke by not using the process at all.
Anyone of these are all upstream, but this all affects Ubuntu (us).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/781445
Title:
Xorg's HAL causes Purple screen or Black Screen on GDM startup.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
