[Top][All Lists]
[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
- Re: Fwd: [PATCH 1/2] Framebuffer split, (continued)
- Re: Fwd: [PATCH 1/2] Framebuffer split, Michal Suchanek, 2009/08/14
- Re: Fwd: [PATCH 1/2] Framebuffer split, Vladimir 'phcoder' Serbinenko, 2009/08/14
- Re: Fwd: [PATCH 1/2] Framebuffer split, Michal Suchanek, 2009/08/14
- Re: Fwd: [PATCH 1/2] Framebuffer split, Vladimir 'phcoder' Serbinenko, 2009/08/14
- Re: Fwd: [PATCH 1/2] Framebuffer split, Vladimir 'phcoder' Serbinenko, 2009/08/14
- Re: Fwd: [PATCH 1/2] Framebuffer split, Michal Suchanek, 2009/08/12
- Re: Fwd: [PATCH 1/2] Framebuffer split, Vladimir 'phcoder' Serbinenko, 2009/08/12
- Re: Fwd: [PATCH 1/2] Framebuffer split, Michal Suchanek, 2009/08/12
- Re: Fwd: [PATCH 1/2] Framebuffer split, Robert Millan, 2009/08/02
- Re: Fwd: [PATCH 1/2] Framebuffer split, Vladimir 'phcoder' Serbinenko, 2009/08/02
Re: Fwd: [PATCH 1/2] Framebuffer split,
Michal Suchanek <=