From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1FFXLl-0001yc-SA for mharc-grub-devel@gnu.org; Sat, 04 Mar 2006 09:03:13 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FFXLk-0001wu-22 for grub-devel@gnu.org; Sat, 04 Mar 2006 09:03:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FFXLf-0001th-SH for grub-devel@gnu.org; Sat, 04 Mar 2006 09:03:10 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FEi1f-0002qm-F2 for grub-devel@gnu.org; Thu, 02 Mar 2006 02:15:03 -0500 Received: from [157.24.2.30] (helo=smtp1.cc.lut.fi) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FEZkw-0005Wi-NI for grub-devel@gnu.org; Wed, 01 Mar 2006 17:25:15 -0500 Received: from localhost (smtp1 [127.0.0.1]) by smtp1.cc.lut.fi (Postfix) with ESMTP id E84A170032 for ; Thu, 2 Mar 2006 00:23:47 +0200 (EET) Received: from smtp1.cc.lut.fi ([127.0.0.1]) by localhost (smtp1.cc.lut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28217-02 for ; Thu, 2 Mar 2006 00:23:47 +0200 (EET) Received: from [192.168.1.100] (lk4-a-4-1.lnet.lut.fi [157.24.102.107]) by smtp1.cc.lut.fi (Postfix) with ESMTP id 702CB70007 for ; Thu, 2 Mar 2006 00:23:46 +0200 (EET) Message-ID: <44061EF7.4010408@nic.fi> Date: Thu, 02 Mar 2006 00:23:51 +0200 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: The development of GRUB 2 References: <43FA48DD.8090509@nic.fi> <87k6bohq91.fsf@xs4all.nl> <44005AB8.7030408@nic.fi> In-Reply-To: <44005AB8.7030408@nic.fi> X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by lut.fi Content-Transfer-Encoding: quoted-printable Subject: Re: Terminal interface and how it should be used? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 14:03:12 -0000 Vesa J=E4=E4skel=E4inen wrote: > Marco Gerards wrote: >> Vesa J=E4=E4skel=E4inen writes: >>> /* Set the current color to be used */ >>> void (*setcolorstate) (grub_term_color_state state); >>> >>> /* Set the normal color and the highlight color. The format of each >>> color is VGA's. */ >>> void (*setcolor) (grub_uint8_t normal_color, grub_uint8_t highlight_c= olor); >>> >>> And what exactly should these two be doing ? :).. setcolorstate and >>> setcolor. I can imagine that it changes color, but to what. Should th= is >>> be changed to some kinda theming system. Or should I just assume that >>> those are palette indexes and in RGB modes, use emulated R >> normal_color and highlight_color are indexed colors. So you have to >> set up some lookup table to lookup the colors that belong to a certain >> index. Something similar is done for the IEEE 1275 terminal. So you >> can look there for a reference and use that table. >=20 > Will implement this shortly. I have quite good idea how to implement > this, but I will look that code too. Now it copies "factory" defaults as a default emulated palette, and then used indices to there. This highlight and normal color doesn't sound like a foreground & background color :), but I implemented them in similar manner. Currently drawing something to screen will make character and it's background opaque. This might not be a good idea in a long run. Having a transparent terminal might be a nice feature. But that is quite easy to change when we need it. Then the next issue here is that video mode should be selectable for the user (or for the script at least). Any ideas how to implement this? Perhaps some environment variable? After this is solved I will release a new snapshot. Then I need to check out my TODO items :)... and implement support for indexed color modes. And make a cleanup. Do we really need other functionality from VBE to be usable than the information what is needed for multiboot? I would like to remove those "old" setpixel etc. stuff. But basicly in this stage I think drivers for the other archs could be started to be written. The driver interface seems to be good enough for our use. Any ideas what would be a good point when we migrate the code back to CVS ? Thanks, Vesa J=E4=E4skel=E4inen