grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] linux/gfxterm integration


From: Robert Millan
Subject: Re: [PATCH] linux/gfxterm integration
Date: Sun, 8 Mar 2009 14:09:29 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Sorry, forgot to attach it.

On Sun, Mar 08, 2009 at 02:01:06PM +0100, Robert Millan wrote:
> On Fri, Mar 06, 2009 at 08:57:35PM +0100, Robert Millan wrote:
> > 
> > This patch integrates the generic Linux loader with gfxterm.  The result is
> > that graphical mode becomes usable with this loader.  Our loader gets the
> > screen settings from the video subsystem (as per gfxterm setup), and passes
> > them to Linux.
> > 
> > This way GRUB/gfxterm can transition to Linux/fb with no further mode
> > setting.  Perhaps this can be exploited to make the transition seamless
> > by using the same background image in both places, but I haven't explored
> > this possibility yet :-)
> > 
> > Note: As the comment in grub/video.h says, struct grub_video_render_target
> > didn't really want to be moved.  My code only needs to access it to find
> > the framebuffer address.  Perhaps it'd be better to move this information
> > elsewhere?  Or split it in a separate structure / getter?
> 
> New patch.  This one calls grub_linux_setup_video() from grub_linux32_boot
> instead of grub_rescue_cmd_linux.  This way it gets the video status we have
> when "boot" is issued instead of the one we have when linux is loaded.
> 
> Any comments on my question about struct grub_video_render_target ?
> 
> -- 
> Robert Millan
> 
>   The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>   how) you may access your data; but nobody's threatening your freedom: we
>   still allow you to remove your data and not access it at all."

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Attachment: linux_gfxterm.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]