From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1ElBrH-0001Rs-Tc for mharc-grub-devel@gnu.org; Sat, 10 Dec 2005 16:02:20 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ElBrF-0001PP-Hy for grub-devel@gnu.org; Sat, 10 Dec 2005 16:02:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ElBrE-0001Om-TS for grub-devel@gnu.org; Sat, 10 Dec 2005 16:02:17 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ElBrE-0001Og-RB for grub-devel@gnu.org; Sat, 10 Dec 2005 16:02:16 -0500 Received: from [194.109.24.28] (helo=smtp-vbr8.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ElBsf-0007xY-Ce for grub-devel@gnu.org; Sat, 10 Dec 2005 16:03:45 -0500 Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by smtp-vbr8.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBAL1nXC097145 for ; Sat, 10 Dec 2005 22:01:49 +0100 (CET) (envelope-from mgerards@xs4all.nl) Mail-Copies-To: mgerards@xs4all.nl 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> <4387AC45.20208@nic.fi> <20051126153624.3b4f486f@synapse> <43891089.1050403@nic.fi> <87ek4lq4ak.fsf@xs4all.nl> <439AAE9A.3050504@nic.fi> From: Marco Gerards Date: Sat, 10 Dec 2005 22:01:53 +0100 In-Reply-To: <439AAE9A.3050504@nic.fi> (Vesa =?iso-8859-1?Q?J=E4=E4skel=E4?= =?iso-8859-1?Q?inen's?= message of "Sat, 10 Dec 2005 12:31:54 +0200") Message-ID: <877jacmzsu.fsf@xs4all.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by XS4ALL Virus Scanner 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, 10 Dec 2005 21:02:17 -0000 Vesa J=E4=E4skel=E4inen writes: >> First of all I'd like to see some double buffering feature. Will that >> be somehow possible? In that case we need functions like: >>=20 >> - Switching to a buffer, making it visible. >> - Selecting which buffer is used for output. > > Yes, double buffering is possible of course ;) It's not even hard one. > There are some issues that must be decided. > > Most important one is, what you want to do with double buffer, do you > want access to actual pixel data? Should this access be hidden or > emulated. What happens when there are different graphics modes. Do we > need to implement pixel data conversion layer. > > Or do you want only to hide some possible artifacts? Eg. having many > changes to whole screen per refresh cycle? Current idea was only draw to > screen when there is something new to draw. Right, but in that case you can draw to another buffer and just switch. Usually that switch changing a pointer or offset in a register of your video card. > Now if we assume that there will be double buffering then there is > problem where the actual data is stored. As we don't have fancy drivers > for each video card there, we must use provided features of VBE (or > similar interface). If double buffering is not available we have to make a copy of the buffer to the video memory. > In banked modes, switching the bank can be slow, and if we require that > double buffer is store on video memory, accessing (read&write) can be > slow. It could also limit some modes from user as there is no room for > double buffer. And worst case is here that some implementations of VBE > can be buggy in this case... Ever seen div by zero from video bios ;) ? AFAIK you can access all video memory from protected mode without bank switching. Please correct me if I am wrong. Anyways, we can always implement double buffering in software or make it optional or so. > If we store this memory to host memory, then accessing it is fast, but > swapping the whole screen can be slow. We could of course implement some > dirty regions to optimize transfer time. Now if you want direct access > to frame buffer data (read&write) then who is responsible to make sure > pixel data is correct for the display? Do we need to convert pixel data > on transfer? In that case the pixel data should be correct for the display so it can be directly copied. Anyways, if the hardware is capable of doing double buffer, I would prefer that to avoid flickering. It could be optional or so. But it would be nice if the option is there. > My idea was following in current implementation: > - Supply basic operations on video driver > - If there is complex graphics needed, use bitmap (it would have > transparency support) How would it support transparency? > - When bitmap is loaded, it would be converted to device compatible bitmap Sounds sane. > - If there is a need to generate bitmap data, it should be done in > emulated pixel buffer (something like R8G8B8A8) and then converted to > device compatible bitmap. Ok. -- Marco