From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ma70C-0001Fv-VF for mharc-grub-devel@gnu.org; Sun, 09 Aug 2009 07:55:53 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ma70A-0001Fn-Q3 for grub-devel@gnu.org; Sun, 09 Aug 2009 07:55:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ma709-0001Fb-0Q for grub-devel@gnu.org; Sun, 09 Aug 2009 07:55:49 -0400 Received: from [199.232.76.173] (port=45806 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ma708-0001FY-Sg for grub-devel@gnu.org; Sun, 09 Aug 2009 07:55:48 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:13600) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ma708-0008Ku-CB for grub-devel@gnu.org; Sun, 09 Aug 2009 07:55:48 -0400 Received: by fg-out-1718.google.com with SMTP id l27so286008fgb.7 for ; Sun, 09 Aug 2009 04:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=VnB6IBZg+5kCBZbpoOlItR7iIZYuGNmBxEV4YKtFvrw=; b=HpdLGS3DpMLZ6lV93Ow+9D6D/HZZFP7BfViAhIDcMxgP+ZSbu/ebOJ36TKdUIX8HrZ r9McYa6slhsTzYOt6Mm4InH0u0mRqQOFEDMPkZ4ov6V1nq0IFuLo6Q2nkXIgq99ISX1s w45pPpY1KKCoUnvTXRYpr4ow9IbHDjaVBm+44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=KMMzGweh6Sm/YgQ7rRp0Byu8AAH56jJ2AO7tMQjNjOzr0ePqc0B5HGKMTOJ7JBeNMa g9OcrB1WB5rkrXSPq0KC2x3Jur6vnmLHqWcMbksl6ldI3HJuZd3FrPFEZ4k1nC9G36D9 Gx35F8k7sUGt4dB8tkKSr/oQHSe8bWeIY5ek0= MIME-Version: 1.0 Sender: hramrach@gmail.com Received: by 10.86.81.16 with SMTP id e16mr2351781fgb.78.1249818947632; Sun, 09 Aug 2009 04:55:47 -0700 (PDT) In-Reply-To: References: <1248392495.2661.208.camel@mj> <20090801150118.GB23133@thorin> Date: Sun, 9 Aug 2009 13:55:47 +0200 X-Google-Sender-Auth: c21be5a938fc101d Message-ID: From: Michal Suchanek To: The development of GRUB 2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Fwd: [PATCH 1/2] Framebuffer split 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: Sun, 09 Aug 2009 11:55:51 -0000 Hello, both in the previous complete patch and Vladimir's git repository introduce a grub_video_rect_t type. Is there some intention to change the interface to use this structure? I was looking at the the various places that use points and rectangles. It's quite inconsistent and unclear now. There is an anonymous viewport structure inside render target which is the same as the rectangle type. Many coordinates and sizes are signed and many are unsigned leading to numerous casts and/or signed vs unsigned comparison warnings. The blit functions take a rectangle and a point specified as six separate integers which makes it somewhat unclear what is what. The other thing that bothers me is that the video drivers fill in the render target structure during video initialization. In my view the render target structure should not be public. The video driver should fill in the video mode structure and then call a function that fills in render target based on video mode and video data (framebuffer memory). This code is currently replicated needlessly in the vbe and sdl drivers. Bitmaps could be created in the same way. Thanks Michal