grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [PATCH 1/2] Framebuffer split


From: Michal Suchanek
Subject: Re: Fwd: [PATCH 1/2] Framebuffer split
Date: Sat, 1 Aug 2009 17:14:31 +0200

2009/8/1 Robert Millan <address@hidden>:
> On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko wrote:
>>    grub_err_t (*get_info) (struct grub_video_mode_info *mode_info);
>>
>> +  grub_err_t (*get_info_and_fini) (struct grub_video_mode_info *mode_info,
>> +                                void **framebuffer);
>> +
>> [...]
>> +/* Framebuffer address may change as a part of normal operation
>> +   (e.g. double buffering). That's why you need to stop video subsystem to 
>> be
>> +   sure that framebuffer address doesn't change. To ensure this abstraction
>> +   grub_video_get_info_and_fini is the only function supplying framebuffer
>> +   address. */
>> +grub_err_t grub_video_get_info_and_fini (struct grub_video_mode_info 
>> *mode_info,
>> +                                      void **framebuffer);
>> +
>
> I see that returning framebuffer address and finishing the video subsystem
> must be together, but is there a reason to couple this with getting mode_info 
> ?
>
> If mode_info is also affected by this problem, or if getting mode info only
> makes sense in a situation in which we'd also want to obtain framebuffer
> address or finishing the subsystem, then the existing get_info() function
> is no longer necessary.
>
> Otherwise, users who want both things can just invoke get_info() first and 
> then
> the new function to obtain FB address.
>
> Btw, if I understand correctly, we have a race condition right now.  As a
> bugfix it'd be better to merge this separately from the interface redesign if
> possible.
>
> Also, does finishing the video subsystem only affect GRUB internally, or
> result in any effect at the display level?  I want to avoid having visual
> glitches when the payload is loaded without switching video mode.
>

I guess the current initialization is somewhat fishy. I haven't looked
at the code so far but the way it works is odd. When I change output
to gfxterm it apparently tries to initialize the vbe graphics but it
fails to find any videomode unless I run vbetest before starting
gfxterm.

The situation is the same both pre- and post- split.

Thanks

Michal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]