From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MXGI9-0000g7-AN for mharc-grub-devel@gnu.org; Sat, 01 Aug 2009 11:14:37 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MXGI7-0000g2-KT for grub-devel@gnu.org; Sat, 01 Aug 2009 11:14:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MXGI6-0000f6-1f for grub-devel@gnu.org; Sat, 01 Aug 2009 11:14:34 -0400 Received: from [199.232.76.173] (port=50300 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXGI5-0000em-TO for grub-devel@gnu.org; Sat, 01 Aug 2009 11:14:33 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:42344) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MXGI4-0008U8-RH for grub-devel@gnu.org; Sat, 01 Aug 2009 11:14:33 -0400 Received: by fg-out-1718.google.com with SMTP id l26so719321fgb.7 for ; Sat, 01 Aug 2009 08:14:32 -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=iq02o6YsoUUIbBg8luLLmAkKiroTchw3HpMvISHb42s=; b=mz+E6B4eh5ipFP2CNZWzc33AC8t9l4S7R0sNmXQ7GpOnvDBqgFocm/jyz8VnCAOLIj kVd3egAVHsQL9JJ4vfYtVIzm4hDZY4yblKZcLa1I75WgYJhLxQn4jKNF+eq+51CYmUiB 5pq3HPEsPCgbAHHwSMlfqQd3NXqLZS1ek8RxQ= 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=a4lZrDehcx+j0l+u0Mc/Ky10cubPtd1nWwsET5bAGG1dyckqoUEfdC3Xh7/Lk2iBi1 d5BjaHwun8AZtfljjDP9vq0/Ja1nVhiCzs8EaUaGAyn+3RIW8QXel7CgbohYuDWXqe9i RuYEZ+T329QqhK7I7d+HAtokuG7eyikpnnOnU= MIME-Version: 1.0 Sender: hramrach@gmail.com Received: by 10.86.60.9 with SMTP id i9mr1335053fga.10.1249139671997; Sat, 01 Aug 2009 08:14:31 -0700 (PDT) In-Reply-To: <20090801150118.GB23133@thorin> References: <1248392495.2661.208.camel@mj> <20090801150118.GB23133@thorin> Date: Sat, 1 Aug 2009 17:14:31 +0200 X-Google-Sender-Auth: 311c278403e7808b Message-ID: From: Michal Suchanek To: The development of GRUB 2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 01 Aug 2009 15:14:36 -0000 2009/8/1 Robert Millan : > On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko w= rote: >> =C2=A0 =C2=A0grub_err_t (*get_info) (struct grub_video_mode_info *mode_i= nfo); >> >> + =C2=A0grub_err_t (*get_info_and_fini) (struct grub_video_mode_info *mo= de_info, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void **framebuffer); >> + >> [...] >> +/* Framebuffer address may change as a part of normal operation >> + =C2=A0 (e.g. double buffering). That's why you need to stop video subs= ystem to be >> + =C2=A0 sure that framebuffer address doesn't change. To ensure this ab= straction >> + =C2=A0 grub_video_get_info_and_fini is the only function supplying fra= mebuffer >> + =C2=A0 address. */ >> +grub_err_t grub_video_get_info_and_fini (struct grub_video_mode_info *m= ode_info, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0void **frameb= uffer); >> + > > I see that returning framebuffer address and finishing the video subsyste= m > must be together, but is there a reason to couple this with getting mode_= info ? > > If mode_info is also affected by this problem, or if getting mode info on= ly > makes sense in a situation in which we'd also want to obtain framebuffer > address or finishing the subsystem, then the existing get_info() function > is no longer necessary. > > Otherwise, users who want both things can just invoke get_info() first an= d then > the new function to obtain FB address. > > Btw, if I understand correctly, we have a race condition right now. =C2= =A0As a > bugfix it'd be better to merge this separately from the interface redesig= n if > possible. > > Also, does finishing the video subsystem only affect GRUB internally, or > result in any effect at the display level? =C2=A0I want to avoid having v= isual > glitches when the payload is loaded without switching video mode. > I guess the current initialization is somewhat fishy. I haven't looked at the code so far but the way it works is odd. When I change output to gfxterm it apparently tries to initialize the vbe graphics but it fails to find any videomode unless I run vbetest before starting gfxterm. The situation is the same both pre- and post- split. Thanks Michal