From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1EfnwB-0003YR-Bn for mharc-grub-devel@gnu.org; Fri, 25 Nov 2005 19:29:07 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Efnw8-0003Y5-T2 for grub-devel@gnu.org; Fri, 25 Nov 2005 19:29:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Efnw2-0003X9-N0 for grub-devel@gnu.org; Fri, 25 Nov 2005 19:29:04 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Efnw2-0003X4-8S for grub-devel@gnu.org; Fri, 25 Nov 2005 19:28:58 -0500 Received: from [157.24.2.30] (helo=smtp1.cc.lut.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Efnw1-0000H3-2B for grub-devel@gnu.org; Fri, 25 Nov 2005 19:28:57 -0500 Received: from localhost (smtp1 [127.0.0.1]) by smtp1.cc.lut.fi (Postfix) with ESMTP id BB380701CC for ; Sat, 26 Nov 2005 02:28:51 +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 31536-07 for ; Sat, 26 Nov 2005 02:28:51 +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 70903701CA for ; Sat, 26 Nov 2005 02:28:50 +0200 (EET) Message-ID: <4387AC45.20208@nic.fi> Date: Sat, 26 Nov 2005 02:28:53 +0200 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: The development of GRUB 2 References: <435B72E9.6070603@nic.fi> <200511181206.49374.okuji@enbug.org> <43836C33.5090508@nic.fi> <200511252125.29459.okuji@enbug.org> In-Reply-To: <200511252125.29459.okuji@enbug.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: by lut.fi Content-Transfer-Encoding: quoted-printable Subject: Re: Video subsystem draft 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, 26 Nov 2005 00:29:05 -0000 Yoshinori K. Okuji wrote: > On Tuesday 22 November 2005 08:06 pm, Vesa J=C3=A4=C3=A4skel=C3=A4inen = wrote: >> I think it can be gzipped to fit more nicely :).. (and it seems to wor= k >> too). >=20 > Compression might make the performance horrible, because PPF is very=20 > optimized. When there is a caching implemented in a one day, it's only initial cost. So far I haven't seen performance problems with this. But then again I haven't tried it too much. >> After something calls grub_error first read from font file fails, with >> grub_file_read() =3D=3D -1. Now this causes font manager to drop font = from >> memory. If I disable feature that I can see that first character is >> invalid and others come nicely. In case of "error: ..." first 'e' is >> corrupt and rest is ok. I am not sure is this really issue in grub_err= or >> itself but it is in sequence when problem shows up. >> >> I can't find problem in font manager, even the offset that is tries to >> seek is within limits of the file (and correct) and there is enough >> bytes left in file in order to successfully complete the read. >> >> I can send tarred version of grub2 with video subsystem if someone wan= ts >> to help on this one. I will continue to search for possible problems i= n >> case I can pinpoint and fix it. >=20 > I will check this myself later. Just in case you (or someone else) want to test current version, I have uploaded it to: http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051126.tar.gz I noticed that when ever I call grub_error something brakes, but what is doing it I can't tell. There is a testerr3 function in video/video.c that tries to demonstrate when does the corruption occur. Oh.. and before anyone asks, video implementation is not still complete. Code itself probably wont compile in other archs. But I think the interface itself could be OK. But it needs to mature a bit. VGA module is disabled until I have time to look how to modify it to fit new system. >> Is the font file using some standard format or can it's contents be >> changed? Bitmap data for fonts could be placed in better order to more >> easily to render it (currently I modify byte order before giving it to >> glyph renderer). (My guess is that it is [P]upa [F]ont [F]ormat or fil= e) >=20 > If you want to improve it, feel free to do it. It is our own format. Bu= t I=20 > think the byte order was set conveniently. Byte order is currently exactly the same as in .hex file :) It has minor issue with widechar fonts (char width > 1). It like contains two different font data. First there is first half of like normal 8x16 font and then there is second half. My idea would be to store bitmap in scanlines instead of character blocks so I can take whole character width and draw that. Now I need to sleep... I will continue my tracking later one.