Re: r3172 regresses background_color handling

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

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

On 27.06.2011 17:46, Colin Watson wrote:
> This commit:
>
> revno: 3172
> committer: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
> branch nick: grub
> timestamp: Wed 2011-04-06 13:00:18 +0200
> message:
>         Output errors if theme loading failed.
>
>         * grub-core/gfxmenu/gfxmenu.c (grub_gfxmenu_try): Move the call to
>         grub_gfxterm_fullscreen on error paths to ...
>         * grub-core/normal/menu.c (menu_init): ...here. Wait after showing
>         theme loading error.
>
> ... regresses the handling of background_color: grub_gfxterm_fullscreen
> sets up the virtual screen again, including setting the background
> colour back to black, and now it's called every time we re-enter the
> menu.  Two simple ways to reproduce this are:
>
>   1) Put 'background_color 44,0,30' before the menuentry commands in
>      grub.cfg.  The menu should show up with a purple background, but in
>      fact is black.
>
>   2) From a menu, press 'c' for a command line, then enter
>      'background_color 44,0,30', which should turn the screen purple.
>      Now press Escape to go back to the menu.  The background should
>      stay purple, but in fact turns black.
>
> What's the best fix for this?  grub_gfxterm_fullscreen can run before
> the virtual screen is set up, so I don't think I can just use
> virtual_screen.bg_color_display.  Can we go back to having
> grub_gfxterm_fullscreen called once on startup and then only on error
> paths, which I think was the previous behaviour?
The reason to run it there is to avoid that gfxterm stays in some stuck
mode if theme loading fails midway.
> Thanks,
>


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



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