[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gfxterm / grub_virtual_screen_setcolorstate()
From: |
Marco Gerards |
Subject: |
Re: gfxterm / grub_virtual_screen_setcolorstate() |
Date: |
Wed, 23 Jan 2008 13:23:52 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Vesa Jääskeläinen <address@hidden> writes:
> 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)
This was fixed already?
--
Marco
- Re: gfxterm / grub_virtual_screen_setcolorstate(),
Marco Gerards <=