Re: gfxterm / grub_virtual_screen_setcolorstate()

[Robert Millan]

On Wed, Jan 23, 2008 at 01:23:52PM +0100, Marco Gerards wrote:
> 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?

Vesa fixed it.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)