2009/8/1 Robert Millan <r...@aybabtu.com>: > 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
