All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Improve handling of "keep" in gfxpayload
Date: Mon, 9 Nov 2009 18:18:41 +0100	[thread overview]
Message-ID: <20091109171841.GA6868@thorin> (raw)
In-Reply-To: <20090810110102.GP11691@riva.ucam.org>

On Mon, Aug 10, 2009 at 12:01:02PM +0100, Colin Watson wrote:
> If the user set "keep" in gfxpayload, as I understand it, that indicates
> that they want the graphical mode set by GRUB to persist through to the
> kernel. In order for this to actually work with Linux, we need to set up
> the vid_mode boot parameter to indicate that it should keep the current
> video mode, otherwise it'll just reset the mode to text at boot and
> nothing much is gained. This patch fixes that.
> 
> Note that I'm explicitly not enabling GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
> in the Ubuntu grub2 package. I can understand why support for it was
> added, and I'd be willing to assume that the Ubuntu kernel has the
> necessary support, but I'm not willing to assume that every Linux kernel
> booted by the Ubuntu grub2 build has the necessary support; that seems
> one assumption too far for me. As such I'm interested in making this
> work properly with run-time configuration as well as build-time
> configuration.
> 
> This doesn't quite work perfectly yet. It's better than before - I've
> tested this, and if everything works properly then the result is a
> smooth zero-flicker transition, which is wonderful. However, if
> something goes wrong before the kernel starts a framebuffer then it has
> no way to display any text at all, and it doesn't seem to start one
> until relatively late for me. It may be that the next step here is to
> try to explicitly tell the kernel to set the correct VESA mode rather
> than using 0x0F04, but I thought I'd send this patch anyway in the
> meantime ...
> 
> 2009-08-10  Colin Watson  <cjwatson@ubuntu.com>
> 
>         * include/grub/i386/linux.h (GRUB_LINUX_VID_MODE_CURRENT): New
>         macro.
>         * loader/i386/linux.c (grub_linux_boot): If gfxpayload starts
>         with "keep", or if GRUB_ASSUME_LINUX_HAS_FB_SUPPORT is defined,
>         then set the vid_mode boot parameter to
>         GRUB_LINUX_VID_MODE_CURRENT.

Hi Colin,

We don't have GRUB_ASSUME_LINUX_HAS_FB_SUPPORT anymore.  Does this patch
still make sense?  (or some part of it?  I suspect GRUB_LINUX_VID_MODE_CURRENT
is still useful).

> diff -Nur -x '*.orig' -x '*~' grub2-1.96+20090725/include/grub/i386/linux.h grub2-1.96+20090725.new/include/grub/i386/linux.h
> --- grub2-1.96+20090725/include/grub/i386/linux.h	2009-07-06 03:10:57.000000000 +0100
> +++ grub2-1.96+20090725.new/include/grub/i386/linux.h	2009-08-08 19:45:10.000000000 +0100
> @@ -39,6 +39,7 @@
>  #define GRUB_LINUX_VID_MODE_NORMAL	0xFFFF
>  #define GRUB_LINUX_VID_MODE_EXTENDED	0xFFFE
>  #define GRUB_LINUX_VID_MODE_ASK		0xFFFD
> +#define GRUB_LINUX_VID_MODE_CURRENT	0x0F04
>  #define GRUB_LINUX_VID_MODE_VESA_START	0x0300
>  
>  #define GRUB_LINUX_SETUP_MOVE_SIZE	0x9100
> diff -Nur -x '*.orig' -x '*~' grub2-1.96+20090725/loader/i386/linux.c grub2-1.96+20090725.new/loader/i386/linux.c
> --- grub2-1.96+20090725/loader/i386/linux.c	2009-08-08 19:31:00.000000000 +0100
> +++ grub2-1.96+20090725.new/loader/i386/linux.c	2009-08-08 19:45:09.000000000 +0100
> @@ -446,6 +446,7 @@
>    int e820_num;
>    grub_err_t err = 0;
>    char *modevar, *tmp;
> +  int keep_mode = 0;
>  
>    params = real_mode_mem;
>  
> @@ -460,11 +461,19 @@
>        if (! tmp)
>  	return grub_errno;
>        grub_sprintf (tmp, "%s;" DEFAULT_VIDEO_MODE, modevar);
> +#ifndef GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
> +      if (grub_memcmp (modevar, "keep", sizeof ("keep")) == 0
> +	  || grub_memcmp (modevar, "keep,", sizeof ("keep,") - 1) == 0
> +	  || grub_memcmp (modevar, "keep;", sizeof ("keep;") - 1) == 0)
> +	keep_mode = 1;
> +#endif
>        err = grub_video_set_mode (tmp, 0);
>        grub_free (tmp);
>      }
> -#ifndef GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
>    else
> +#ifdef GRUB_ASSUME_LINUX_HAS_FB_SUPPORT
> +    keep_mode = 1;
> +#else
>      err = grub_video_set_mode (DEFAULT_VIDEO_MODE, 0);
>  #endif
>  
> @@ -474,6 +483,8 @@
>        grub_printf ("Booting however\n");
>        grub_errno = GRUB_ERR_NONE;
>      }
> +  else if (keep_mode)
> +    params->vid_mode = GRUB_LINUX_VID_MODE_CURRENT;
>  
>    if (! grub_linux_setup_video (params))
>      params->have_vga = GRUB_VIDEO_TYPE_VLFB;

-- 
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."



  parent reply	other threads:[~2009-11-09 17:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-10 11:01 [PATCH] Improve handling of "keep" in gfxpayload Colin Watson
2009-08-10 11:49 ` Robert Millan
2009-08-10 11:58   ` Colin Watson
2009-08-10 15:15     ` Robert Millan
2009-08-10 15:49       ` Colin Watson
2009-08-10 16:27         ` Vladimir 'phcoder' Serbinenko
2009-08-10 16:41           ` Colin Watson
2009-08-24 14:26             ` Vladimir 'phcoder' Serbinenko
2009-08-24 16:38               ` Colin Watson
2009-08-24 17:14                 ` Vladimir 'phcoder' Serbinenko
2009-08-10 12:08   ` Vladimir 'phcoder' Serbinenko
2009-08-10 12:05 ` Vladimir 'phcoder' Serbinenko
2009-08-10 12:21   ` Colin Watson
2009-08-10 12:38     ` Vladimir 'phcoder' Serbinenko
2009-08-10 13:02       ` Colin Watson
2009-08-10 15:27   ` Robert Millan
2009-08-10 16:18     ` Colin Watson
2009-08-10 20:01       ` Vladimir 'phcoder' Serbinenko
2009-08-10 20:16         ` Colin Watson
2009-08-10 20:24           ` Vladimir 'phcoder' Serbinenko
2009-08-12  0:30       ` Robert Millan
2009-11-09 17:18 ` Robert Millan [this message]
2009-11-09 17:53   ` Colin Watson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091109171841.GA6868@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.