[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gfxterm / grub_virtual_screen_setcolorstate()
From: |
Vesa Jääskeläinen |
Subject: |
Re: gfxterm / grub_virtual_screen_setcolorstate() |
Date: |
Sun, 30 Dec 2007 01:50:33 +0200 |
User-agent: |
Thunderbird 2.0.0.9 (Windows/20071031) |
Robert Millan wrote:
> On Mon, Dec 24, 2007 at 02:28:18AM +0100, Robert Millan wrote:
>> New patch. Corrects a minor mistake when filling the last colum in the
>> menu. Also, it doesn't change the colors on gfxterm since some reasjustments
>> were needed for that, and there's also a bug that makes it impossible to
>> change colors on the fly with gfxterm/vbe (I'll write more on that later).
>
> This patch (relative to previous one) basicaly makes it work with a big
> ugly kludge (see "| 0xff000000" line). The problem seems to be that alpha
> channel is set to 0 for all return values of grub_video_map_color() after
> gfxterm initialization. I checked the few places in the code where those
> variables are zeroed, but to no avail. I assume the problem is just they
> haven't been initialised, but I just have no idea where they're supposed to.
>
> Any clues?
Ok... Your "fix" with OR'ing is not a good one as that makes an
assumption about display mode settings. Idea of mapping colors is to get
most optimal color settings for desired video mode. Nevertheless I think
I know the problem and I get back to you shortly... now I sleep :)
That zero alpha setting most likely comes from color table being
specified. (or from video mode settings currently in use, eg. no
alpha/reserved bits)