From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LwI8K-0000al-2t for mharc-grub-devel@gnu.org; Tue, 21 Apr 2009 11:43:40 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LwI8I-0000Z2-73 for grub-devel@gnu.org; Tue, 21 Apr 2009 11:43:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LwI8D-0000XL-N1 for grub-devel@gnu.org; Tue, 21 Apr 2009 11:43:37 -0400 Received: from [199.232.76.173] (port=37430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LwI8D-0000XE-Ep for grub-devel@gnu.org; Tue, 21 Apr 2009 11:43:33 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:59445 helo=kirsi1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LwI8C-0002B8-AD for grub-devel@gnu.org; Tue, 21 Apr 2009 11:43:32 -0400 Received: from [192.168.1.102] (84.248.105.254) by kirsi1.inet.fi (8.5.014) id 49CA1E7301223D9A for grub-devel@gnu.org; Tue, 21 Apr 2009 18:43:28 +0300 Message-ID: <49EDE991.6060905@nic.fi> Date: Tue, 21 Apr 2009 18:43:13 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: The development of GRUB 2 References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: Framebuffer/vbe separation 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: Tue, 21 Apr 2009 15:43:38 -0000 Vladimir Serbinenko wrote: > Hello, currently vbe module contains all the framebuffer functions which are > actually adapter-independent and I think more adapters can be implementing > by providing a function which sets mode and framebuffer. Additionally it > provides an interface to retrieve framebuffer address for loaders: check > that current mode is framebuffer based and if it is, take the address. May I > do it that way? Yes. I have nothing against making frame buffer code as common code as possible because other systems would also benefit from it. Just keep in mind that other video drivers will also need to use it and do not call directly VBE driver itself, provide proper interface over Video Subsystem.