From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MaZo4-0007Fh-Rk for mharc-grub-devel@gnu.org; Mon, 10 Aug 2009 14:41:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaZo2-0007F0-Uo for grub-devel@gnu.org; Mon, 10 Aug 2009 14:41:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaZo2-0007Ei-E7 for grub-devel@gnu.org; Mon, 10 Aug 2009 14:41:14 -0400 Received: from [199.232.76.173] (port=35678 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaZo2-0007Ed-95 for grub-devel@gnu.org; Mon, 10 Aug 2009 14:41:14 -0400 Received: from fg-out-1718.google.com ([72.14.220.157]:22162) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MaZo1-0003OA-Ov for grub-devel@gnu.org; Mon, 10 Aug 2009 14:41:14 -0400 Received: by fg-out-1718.google.com with SMTP id 22so735203fge.7 for ; Mon, 10 Aug 2009 11:41:13 -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=dOMwKR66+Q33xzo0eEiize7F0ubVPDjsVikTf3FGpDY=; b=QJXLxVAmIgKepgJHIYNyEhF9GAsdVWjk8x3HtK85929+HOSxijzwrZZd+RMM+qqtIg hrIRb2DxqIorZhv1BynNjn0BY2UlwQcO8JVJs3mVuPjTwkJWGwoY50IzoZFQHLhh8KNL cFnCeoPZ2DREXeTHMpuIVwB5qBPfNXnN9Fvbs= 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=T26v2Y/6/wtyuzHRxk3B64dqbz5ycWhG1DGWbKnzORIxWYBqR3bjvBwvdoxWn3vE7V fYDqKgLxNI282Hf/iNkQIqdqhfZ1OpwYGjn5gFlr6HChhHlF6GSmE3hD4ys3LFny5OeJ sPn5MBfStGCokRmHItCgMDSX+34MdaS1zGdrk= MIME-Version: 1.0 Sender: hramrach@gmail.com Received: by 10.86.30.9 with SMTP id d9mr3450649fgd.28.1249929673030; Mon, 10 Aug 2009 11:41:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2009 20:41:12 +0200 X-Google-Sender-Auth: 25066b0c3b151d18 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: Mon, 10 Aug 2009 18:41:15 -0000 2009/8/10 Vladimir 'phcoder' Serbinenko : > On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanek wrote: >> Yes, but set_viewport works on the active target. You create an >> offscreen target and set it as the active target and want to set the >> viewport on it. Depending on its size this function either needlessly >> limits you to the current screen mode or allows illegal viewport to be >> set. >> >> It simply compares apples and oranges. >> > Fixed in repo. New patch is coming after testing Thanks >> I just want the drivers not touch the render target structure so that >> it is possible to add features to video_fb (such as framebuffer >> rotation) later without breaking the drivers that do not use them. >> >> Because it breaks encapsulation and needlessly duplicates code. > I'm not sure that encapsulation is good in this particular case. > Clearly the driver should take the lead and not the framebuffer > library. Now it's coded with "library of functions" concept and > changing concept will put strains on drivers. I don't know which > approach is better in a long run >>> Both pieces of code check against the current mode. It's just because >>> vbe does most of job for us that this code is a bunch of assignments >>> but it may be more complex. I don't see what your problem with filling >>> render target about screen parameters is >> >> Exactly that it may get more complex. You have to change the code in >> all drivers then. > Why? Driver just sets fields framebuf? In which cases does it need to > be modified? >>> Then you pass video mode info which is just a screen render target >> >> Yes, without any needless redundancy. > Passing framebuffer parameters one way or another you have redundancy >> For that they should be able to create and use render targets but not >> manipulate them directly. >> > They do. They need to say "this render target is at ... with these parameters" >> >> The mode_info is already part of the framebuffer so I only ask that >> the driver fills in the mode_info and has a render target created from >> that rather than creating a render target itself. > mode_info lacks crucial data like framebuffer address. Yes, it does. I would like a video_fb function like grub_video_fb_create_render_target_from_buffer(void * buffer, int allocated, const grub_video_mode_info_t * mode_info) >> If features are later added to the render target (such as rotation) >> this code needs to be aware of them. However, if the structure was >> filled out in fb_video then these new features are transparent. >> > But if a driver partially accelerates rotation it needs to tell which > buffers are rotated and which aren't. Basically we have 2 possible Yes, and it can create them rotated or not as appropriate (and specify that in the mode_info). If the rotation is done in hardware then it should be transparent and the buffer is effectively non-rotated as far as video_fb cares. > benefits but I'm not sure which one is better. What do others think? I am sure that for doing transparent rotation in video_fb encapsulation is good. I can do without it or patch it in with the rotation if I get it into working state. The only other users of the render_target structure are drivers and from what I have seen so far they should better be kept at good distance from it. However, an opinion of somebody else who looks at the graphics subsystem would be welcome. Thanks Michal