[Top][All Lists]

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

Fw: GRUB: Hercules console and vbeset command

From: OKUJI Yoshinori
Subject: Fw: GRUB: Hercules console and vbeset command
Date: Fri, 15 Dec 2000 02:09:27 +0900

  Frank, please send patches to bug-grub rather than me. I'm not the
only one who is working on GRUB. Thus, I forward your mail to the

  About your patch: Hercules support is great. I'll apply this
part. But the VBE support is not very good. Certainly, a command to
switch to a graphics mode explicitly is necessary, but the mode
switching shouldn't happen until you actually boot up your OS, because
you won't be able to control GRUB interactively on the ordinary
console after switching to a graphics mode. There are some other
problems as well. Anyway, I think this work must be done myself, to
make the graphics support ideal for me. I'll work on this, once a new
implementation of track_int13 is stabilized (I have the code, but I
haven't checked it in yet, because of some known bugs).

--- Begin Message --- Subject: GRUB: Hercules console and vbeset command Date: Thu, 14 Dec 2000 11:08:18 +0100
Hi Okuji Yoshinori,

I've appended a patch to the current GRUB in cvs. This patch adds two
features to GRUB:

- The "terminal" command knows about a "hercules" type:

   "terminal hercules" 

  switches to a hercules screen. In our test machines we usually have two
  graphics cards installed: The primary VGA card and an additional Hercules
  graphics card for debugging purposes.
  (added hercules functions to shared.h, asm.S, stage2.c, char_io.c and

- There is a new command vbeset: vbeset <mode> switches into VESA2 graphics
  mode <mode>. This works simular to testvbe but there are some differents
  to testvbe:
  * the mode will _not_ switched back to text after the command finished
  * the VESA2 graphics mode info and controller mode info is stored in a
    memory block, and pointers to this info is stored in the multiboot_info
    structure (create_vbe_module in boot.c) so that all multiboot modules
    can use the information

  (added vbeset stuff to shared.h, builtins.c and boot.c)

  drawbacks of my solution:
  * because I allocate a memory chunk with help of the cur_addr pointer,
    a multiboot kernel has to be loaded before the vbeset command may be
  * for each vbeset command a new chunk of memory is allocated
  => perhaps we could overcome these two drawbacks when we allocate a single
    memory area for the VESA2 info and reuse it on every vbeset command.

Please apply the patch with the following commands to the current CVS release
(12-14-2000) of grub:

  cd grub/stage2
  patch < grub_stage2_patch


Frank Mehnert
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## E-Mail: address@hidden    http://os.inf.tu-dresden.de/~fm3 ##

Attachment: grub_stage2_patch
Description: GRUB Patch

--- End Message ---

reply via email to

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