[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gfxterm / grub_virtual_screen_setcolorstate()
From: |
Robert Millan |
Subject: |
Re: gfxterm / grub_virtual_screen_setcolorstate() |
Date: |
Wed, 23 Jan 2008 14:07:35 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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 /.)