Re: Completely disable graphics support in grub2 x86_64-efi

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3252 bytes --]

On 08/26/2010 10:02 AM, KESHAV P.R. wrote:
> On Wed, Aug 25, 2010 at 17:43, KESHAV P.R. <skodabenz@gmail.com> wrote:
>   
>> 2010/8/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>     
>>> Were you testing inside qemu? If so then mainline version has used
>>> video_cirrus module which wasn't propagated into newreloc until I
>>> resynced it recently
>>>       
>> No, I was not testing in qemu or VirtualBox (or any virtual machine).
>> I tried it in real hardware. My GPU is ATI Mobility Radeon HD 3450
>> with 256 MB Graphics RAM, 1280x800 native resolution of my Dell Studio
>> 1537 laptop. Should I use newreloc or experimental branch?
>>
>> Maybe I will try newreloc separately and come back to you.
>>
>>     
> I tried the newreloc branch
> https://code.launchpad.net/~skodabenz/grub/grub2-branch-newreloc but I
> found no difference in fuctionality between experimental and newreloc
> in case of x86_64-efi (I do not know about i386-efi). "newreloc"
> solves the problem of initramfs not being loaded properly and leading
> to kernel panic that currently occurs with mainline, but the graphics
> problem in experimental also occurs with newreloc, I think this
> problem is due to efigfx branch.
efigfx was merged into mainline quite some time ago
>  Is there any command which makes
> grub2 stop trying to load a graphics/video mode and instead fallback
> to efi simple text protocol?
efi simple text protocol was never used for this. Moreover it's not
usable by OS (you can read spec for details, part boot and runtime
protocols)
>  Please include the way mainline handles
> the issue, as a fallback option in efigfx, in case no graphics/video
> mode is found.
>   
I don't understand what happens in your case. According to you
"videotest" doesn't work (can you confirm?) and according to code GRUB
in neither branch tries to detect any other way of configure graphics on
EFI. I have a theory that for some reason Linux uses vga_text normally.
It's possible to have this behaviour with patch at the end of this
e-mail. But that patch can't be incorporated because there is no way to
actualy check the availability of vga_text on EFI and on EFI as a
firmware it's usualy not. EFI is pretty loosy firmware and is definitely
not what I recommend. I recognize that in some cases you have to use EFI
(if your hardware is shipped with it) but in case of DUET, it's
specifically searching for trouble.
Additionaly DUET is labeled as being for test purposes only and not for
regular use.
=== modified file 'grub-core/loader/i386/linux.c'
--- grub-core/loader/i386/linux.c       2010-04-21 17:13:45 +0000
+++ grub-core/loader/i386/linux.c       2010-08-26 08:20:20 +0000
@@ -638,7 +638,7 @@
     }
   else
     {
-#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) ||
defined (GRUB_MACHINE_QEMU)
+#if 1
       params->have_vga = GRUB_VIDEO_LINUX_TYPE_TEXT;
       params->video_mode = 0x3;
 #else


> Regards.
>
> Keshav
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]