[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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]