2N/A@c %**start of header
2N/A@settitle GNU GRUB Developers Manual @value{VERSION}
2N/A@c Unify all our little indices for now.
2N/A@footnotestyle separate
2N/AThis developer manual is for GNU GRUB (version @value{VERSION},
2N/ACopyright @copyright{} 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 Free Software Foundation, Inc.
2N/APermission is granted to copy, distribute
and/or modify this document
2N/Aunder the terms of the GNU Free Documentation License, Version 1.2 or
2N/Aany later version published by the Free Software Foundation; with no
2N/A* grub-dev: (grub-dev). The GRand Unified Bootloader Dev
2N/A@setchapternewpage odd
2N/A@title the GNU GRUB developer manual
2N/A@subtitle The GRand Unified Bootloader, version @value{VERSION}, @value{UPDATED}.
2N/A@author Yoshinori K. Okuji
2N/A@author Colin D Bennett
2N/A@author Vesa Jääskeläinen
2N/A@author Robert Millan
2N/A@c The following two commands start the copyright page.
2N/A@vskip 0pt plus 1filll
2N/A@c Output the table of contents at the beginning.
2N/A@top GNU GRUB developer manual
2N/AThis is the developer documentation of GNU GRUB, the GRand Unified Bootloader,
2N/Aa flexible and powerful boot loader program for a wide range of
2N/AThis edition documents version @value{VERSION}.
2N/A* Getting the source code::
2N/A* Finding your way around::
2N/A* Contributing Changes::
2N/A* BIOS port memory map::
2N/A* PFF2 Font File Format::
2N/A* Graphical Menu Software Design::
2N/A* Copying This Manual:: Copying This Manual
2N/A@node Getting the source code
2N/A@chapter Getting the source code
2N/Acontrol system}. To fetch the primary development branch:
2N/AThe GRUB developers maintain several other branches with work in progress.
2N/AOf these, the most interesting is the experimental branch, which is a
2N/Astaging area for new code which we expect to eventually merge into trunk but
2N/Awhich is not yet ready:
2N/AOnce you have used @kbd{bzr get} to fetch an initial copy of a branch, you
2N/Acan use @kbd{bzr pull} to keep it up to date. If you have modified your
2N/Alocal version, you may need to resolve conflicts when pulling.
2N/A@chapter Coding style
2N/A@c By YoshinoriOkuji, VesaJääskeläinen and ColinBennett
2N/A* Naming Conventions::
2N/A* Multi-Line Comments::
2N/A@node Naming Conventions
2N/A@section Naming Conventions
2N/AAll global symbols (
i.e. functions, variables, types, and macros) must have the prefix grub_ or GRUB_. The all capital form is used only by macros.
2N/AIf a function is global, its name must be prefixed with grub_ and must consist of only small letters. If the function belongs to a specific function module, the name must also be prefixed with the module name. For example, if a function is for file systems, its name is prefixed with grub_fs_. If a function is for FAT file system but not for all file systems, its name is prefixed with grub_fs_fat_. The hierarchy is noted this way.
2N/AAfter a prefix, a function name must start with a verb (such as get or is). It must not be a noun. Some kind of abbreviation is permitted, as long as it wouldn't make code less readable (
e.g. init).
2N/AIf a function is local, its name may not start with any prefix. It must start with a verb.
2N/AThe rule is mostly the same as functions, as noted above. If a variable is global, its name must be prefixed with grub_ and must consist of only small letters. If the variable belongs to a specific function module, the name must also be prefixed with the module name. For example, if a function is for dynamic loading, its name is prefixed with grub_dl_. If a variable is for ELF but not for all dynamic loading systems, its name is prefixed with grub_dl_elf_.
2N/AAfter a prefix, a variable name must start with a noun or an adjective (such as name or long) and it should end with a noun. Some kind of abbreviation is permitted, as long as it wouldn't make code less readable (
e.g. i18n).
2N/AIf a variable is global in the scope of a single file (
i.e. it is declared with static), its name may not start with any prefix. It must start with a noun or an adjective.
2N/AIf a variable is local, you may choose any shorter name, as long as it wouldn't make code less readable (
e.g. i).
2N/AThe name of a type must be prefixed with grub_ and must consist of only small letters. If the type belongs to a specific function module, the name must also be prefixed with the module name. For example, if a type is for OS loaders, its name is prefixed with grub_loader_. If a type is for Multiboot but not for all OS loaders, its name is prefixed with grub_loader_linux_.
2N/AThe name must be suffixed with _t, to emphasize the fact that it is a type but not a variable or a function.
2N/AIf a macro is global, its name must be prefixed with GRUB_ and must consist of only large letters. Other rules are the same as functions or variables, depending on whether a macro is used like a function or a variable.
2N/AAll comments shall be C-style comments, of the form @samp{/* @dots{} */}.
2N/AComments shall be placed only on a line by themselves. They shall not be placed together with code, variable declarations, or other non-comment entities. A comment should be placed immediately preceding the entity it describes.
2N/A/* The page # that is the front buffer. */
2N/A/* The page # that is the back buffer. */
2N/Aint displayed_page; /* The page # that is the front buffer. */
2N/Aint render_page; /* The page # that is the back buffer. */
2N/A@node Multi-Line Comments
2N/A@section Multi-Line Comments
2N/AComments spanning multiple lines shall be formatted with all lines after the first aligned with the first line.
2N/AAsterisk characters should not be repeated a the start of each subsequent line.
2N/A which spans multiple lines.
2N/A * which spans multiple lines.
2N/AThe opening @samp{/*} and closing @samp{*/} should be placed together on a line with text.
2N/A@node Finding your way around
2N/A@chapter Finding your way around
2N/AHere is a brief map of the GRUB code base.
2N/AGRUB uses Autoconf and Automake, with most of the Automake input generated
2N/Ablock in a @file{*.def} file represents a build target, and specifies the
2N/Asource files used to build it on various platforms. The @file{*.def} files
2N/Aare processed into AutoGen input by @file{
gentpl.py} (which you only need to
2N/Alook at if you are extending the build system). If you are adding a new
2N/Amodule which follows an existing pattern, such as a new command or a new
2N/Afilesystem implementation, it is usually easiest to grep
2N/Aexisting example of that pattern to find out where it should be added.
2N/AIn general, code that may be run at boot time is in a subdirectory of
2N/A@file{grub-core}, while code that is only run from within a full operating
2N/Asystem is in a subdirectory of the top level.
2N/ALow-level boot code, such as the MBR implementation on PC BIOS systems, is
2N/Asuch as the device, disk, and file frameworks, environment variable
2N/Ahandling, list processing, and so on. The kernel should contain enough to
2N/Aget up to a rescue prompt. Header files for kernel facilities, among
2N/Aothers, are in @file{include/}.
2N/Apartition table data), and @file{
grub-core/fs/} (for accessing filesystems).
2N/ANote that, with the odd specialised exception, GRUB only contains code to
2N/A@emph{read} from filesystems and tries to avoid containing any code to
2N/A@emph{write} to filesystems; this lets us confidently assure users that GRUB
2N/Acannot be responsible for filesystem corruption.
2N/Asystem uses this heavily, but is in a separate directory,
2N/Athe following exceptions:
2N/AThe @samp{loopback} command is really a disk device, and so lives in
2N/AThe @samp{loadfont} and @samp{lsfonts} commands live under
2N/AThe @samp{serial}, @samp{terminfo}, and @samp{background_image} commands
2N/AThere are a few other special-purpose exceptions; grep for them if they
2N/AUtility programs meant to be run from a full operating system are in
2N/A@node Contributing Changes
2N/A@chapter Contributing changes
2N/A@c By YoshinoriOkuji, VesaJääskeläinen, ColinWatson
2N/AContributing changes to GRUB 2 is welcomed activity. However we have a
2N/Abit of control what kind of changes will be accepted to GRUB 2.
2N/ATherefore it is important to discuss your changes on grub-devel mailing list
2N/A(see MailingLists). On this page there are some basic details on the
2N/Adevelopment process and activities.
2N/AFirst of all you should come up with the idea yourself what you want to
2N/Acontribute. If you do not have that beforehand you are advised to study this
2N/Amanual and try GRUB 2 out to see what you think is missing from there.
2N/AHere are additional pointers:
2N/AIf you intended to make changes to GRUB Legacy (<=0.97) those are not accepted
2N/A* Typical Developer Experience::
2N/A* When you are approved for write access to project's files::
2N/A@node Getting started
2N/A@section Getting started
2N/A@item Always use latest GRUB 2 source code. So get that first.
2N/AFor developers it is recommended always to use the newest development version of GRUB 2. If development takes a long period of time, please remember to keep in sync with newest developments regularly so it is much easier to integrate your change in the future. GRUB 2 is being developed in a Bazaar (bzr) repository.
2N/APlease check Savannah's GRUB project page for details how to get newest bzr:
2N/A@item Compile it and try it out.
2N/AIt is always good idea to first see that things work somehow and after that
2N/Ato start to implement new features or develop fixes to bugs.
2N/A@item Study the code.
2N/AThere are sometimes odd ways to do things in GRUB 2 code base.
2N/AThis is mainly related to limited environment where GRUB 2 is being executed.
2N/AYou usually do not need to understand it all so it is better to only try to
2N/Alook at places that relates to your work. Please do not hesitate to ask for
2N/Ahelp if there is something that you do not understand.
2N/A@item Develop a new feature.
2N/ANow that you know what to do and how it should work in GRUB 2 code base, please
2N/Abe free to develop it. If you have not so far announced your idea on grub-devel
2N/Amailing list, please do it now. This is to make sure you are not wasting your
2N/Atime working on the solution that will not be integrated to GRUB 2 code base.
2N/AYou might want to study our coding style before starting development so you
2N/Ado not need to change much of the code when your patch is being reviewed.
2N/A(see @ref{Coding style})
2N/AFor every accepted patch there has to exist a ChangeLog entry. Our ChangeLog
2N/Aconsist of changes within source code and are not describing about what the
2N/Achange logically does. Please see examples from previous entries.
2N/AAlso remember that GRUB 2 is licensed under GPLv3 license and that usually
2N/Ameans that you are not allowed to copy pieces of code from other projects.
2N/AEven if the source project's license would be compatible with GPLv3, please
2N/Adiscuss it beforehand on grub-devel mailing list.
2N/A@item Test your change.
2N/ATest that your change works properly. Try it out a couple of times, preferably on different systems, and try to find problems with it.
2N/A@item Publish your change.
2N/AWhen you are happy with your change, first make sure it is compilable with
2N/Alatest development version of GRUB 2. After that please send a patch to
2N/Agrub-devel for review. Please describe in your email why you made the change,
2N/Awhat it changes and so on. Please be prepared to receive even discouraging
2N/Acomments about your patch. There is usually at least something that needs
2N/Ato be improved in every patch.
2N/APlease use unified diff to make your patch (good match of arguments for diff is @samp{-pruN}).
2N/A@item Respond to received feedback.
2N/AIf you are asked to modify your patch, please do that and resubmit it for
2N/Areview. If your change is large you are required to submit a copyright
2N/Aagreement to FSF. Please keep in mind that if you are asked to submit
2N/Afor copyright agreement, process can take some time and is mandatory
2N/Ain order to get your changes integrated.
2N/AIf you are not on grub-devel to respond to questions, most likely your patch
2N/Awill not be accepted. Also if problems arise from your changes later on,
2N/Ait would be preferable that you also fix the problem. So stay around
2N/A@item Your patch is accepted.
2N/AGood job! Your patch will now be integrated into GRUB 2 mainline, and if it didn't break anything it will be publicly available in the next release.
2N/ANow you are welcome to do further improvements :)
2N/A@node Typical Developer Experience
2N/A@section Typical Developer Experience
2N/AThe typical experience for a developer in this project is the following:
2N/A@item You find yourself wanting to do something (
e.g. fixing a bug).
2N/A@item You show some result in the mailing list or the IRC.
2N/A@item You are getting to be known to other developers.
2N/A@item You accumulate significant amount of contribution, so copyright assignment is processed.
2N/A@item You are free to check in your changes on your own, legally speaking.
2N/AAt this point, it is rather annoying that you ought to ask somebody else every
2N/Achange to be checked in. For efficiency, it is far better, if you can commit
2N/Ait yourself. Therefore, our policy is to give you the write permission to our
2N/Aofficial repository, once you have shown your skill and will,
2N/Aand the FSF clerks have dealt with your copyright assignment.
2N/A@node When you are approved for write access to project's files
2N/A@section When you are approved for write access to project's files
2N/AAs you might know, GRUB is hosted on
2N/Ais managed by Savannah. This means that, if you want to be a member of this
2N/A@item You need to create your own account on Savannah.
2N/A@item You can submit ``Request for Inclusion'' from ``My Groups'' on Savannah.
2N/AThen, one of the admins can approve your request, and you will be a member.
2N/AIf you don't want to use the Savannah interface to submit a request, you can
2N/Asimply notify the admins by email or something else, alternatively. But you
2N/Astill need to create an account beforehand.
2N/ANOTE: we sometimes receive a ``Request for Inclusion'' from an unknown person.
2N/AIn this case, the request would be just discarded, since it is too dangerous
2N/Ato allow a stranger to be a member, which automatically gives him a commit
2N/Aright to the repository, both for a legal reason and for a technical reason.
2N/AIf your intention is to just get started, please do not submit a inclusion
2N/Arequest. Instead, please subscribe to the mailing list, and communicate first
2N/A(
e.g. sending a patch, asking a question, commenting on another message...).
2N/A@chapter Error Handling
2N/AError handling in GRUB 2 is based on exception handling model. As C language
2N/Adoesn't directly support exceptions, exception handling behavior is emulated
2N/AWhen exception is raised, function must return to calling function. If calling
2N/Afunction does not provide handling of the exception it must return back to its
2N/Acalling function and so on, until exception is handled. If exception is not
2N/Ahandled before prompt is displayed, error message will be shown to user.
2N/AException information is stored on @code{grub_errno} global variable. If
2N/A@code{grub_errno} variable contains value @code{GRUB_ERR_NONE}, there is no active
2N/Aexception and application can continue normal processing. When @code{grub_errno} has
2N/Aother value, it is required that application code either handles this error or
2N/Areturns instantly to caller. If function is with return type @code{grub_err_t} is
2N/Aabout to return @code{GRUB_ERR_NONE}, it should not set @code{grub_errno} to that
2N/Avalue. Only set @code{grub_errno} in cases where there is error situation.
2N/ASimple exception forwarder.
2N/Aforwarding_example (void)
2N/A /* Call function that might cause exception. */
2N/A /* No special exception handler, just forward possible exceptions. */
2N/A if (grub_errno != GRUB_ERR_NONE)
2N/A /* All is OK, do more processing. */
2N/A /* Return OK signal, to caller. */
2N/A return GRUB_ERR_NONE;
2N/AError reporting has two components, the actual error code (of type
2N/A@code{grub_err_t}) and textual message that will be displayed to user. List of
2N/Aerror message can contain any textual data. At time of writing, error message
2N/Acan contain up to 256 characters (including terminating NUL). To ease error
2N/Areporting there is a helper function @code{grub_error} that allows easier
2N/Aformatting of error messages and should be used instead of writing directly to
2N/AExample of error reporting.
2N/A return grub_error (GRUB_ERR_FILE_NOT_FOUND,
2N/A "Failed to read %s, tried %d times.",
2N/AIf there is a special reason that error code does not need to be taken account,
2N/A@code{grub_errno} can be zeroed back to @code{GRUB_ERR_NONE}. In cases like this all
2N/Aprevious error codes should have been handled correctly. This makes sure that
2N/Athere are no unhandled exceptions.
2N/AExample of zeroing @code{grub_errno}.
2N/A /* Try to probe device type 1. */
2N/A probe_for_device ();
2N/A if (grub_errno == GRUB_ERR_NONE)
2N/A /* Device type 1 was found on system. */
2N/A return GRUB_ERR_NONE;
2N/A /* Zero out error code. */
2N/A grub_errno = GRUB_ERR_NONE;
2N/A /* No device type 1 found, try to probe device type 2. */
2N/A probe_for_device2 ();
2N/A if (grub_errno == GRUB_ERR_NONE)
2N/A /* Device type 2 was found on system. */
2N/A register_device2 ();
2N/A return GRUB_ERR_NONE;
2N/A /* Zero out error code. */
2N/A grub_errno = GRUB_ERR_NONE;
2N/A /* Return custom error message. */
2N/A return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No device type 1 or 2 found.");
2N/ASome times there is a need to continue processing even if there is a error
2N/Astate in application. In situations like this, there is a needed to save old
2N/Aerror state and then call other functions that might fail. To aid in this,
2N/Athere is a error stack implemented. Error state can be pushed to error stack
2N/Aby calling function @code{grub_error_push ()}. When processing has been completed,
2N/A@code{grub_error_pop ()} can be used to pop error state from stack. Error stack
2N/Acontains predefined amount of error stack items. Error stack is protected for
2N/Aoverflow and marks these situations so overflow error does not get unseen.
2N/AIf there is no space available to store error message, it is simply discarded
2N/Aand overflow will be marked as happened. When overflow happens, it most likely
2N/Awill corrupt error stack consistency as for pushed error there is no matching
2N/Apop, but overflow message will be shown to inform user about the situation.
2N/AOverflow message will be shown at time when prompt is about to be drawn.
2N/AExample usage of error stack.
2N/A/* Save possible old error message. */
2N/A/* Do your stuff here. */
2N/Acall_possibly_failing_function ();
2N/Aif (grub_errno != GRUB_ERR_NONE)
2N/A /* Inform rest of the code that there is error (grub_errno
2N/A is set). There is no pop here as we want both error states
2N/A/* Restore old error state by popping previous item from stack. */
2N/A@c By Robert Millan and Carles Pina
2N/AIf you have commit access, please setup CIA in your Bazaar
2N/Aconfig so those in IRC receive notification of your commits.
2N/AOptionally, you can also add "cia_user = myusername" if you'd
2N/Alike CIA service to use a specific account (for statistical purpose).
2N/A"set nickname = /path_to_this_branch" and "cia_project = GNU GRUB".
2N/AAdditionally, please set cia_send_revno in the [DEFAULT] section
2N/Acia_send_revno = true
2N/AKeep in mind Bazaar sends notifications for all commits to branches that have
2N/Athis setting, regardless of whether they're bound branches (checkouts) or not.
2N/ASo if you make local commits in a non-bound branch and it bothers you that
2N/Aothers can read them, do not use this setting.
2N/A@node BIOS port memory map
2N/A@chapter BIOS port memory map
2N/A@c By Yoshinori K Okuji
2N/A@multitable @columnfractions .15 .25 .5
2N/A@headitem Start @tab End @tab Usage
2N/A@item 0 @tab 0x1000 - 1 @tab BIOS and real mode interrupts
2N/A@item 0x07BE @tab 0x07FF @tab Partition table passed to another boot loader
2N/A@item ? @tab 0x2000 - 1 @tab Real mode stack
2N/A@item 0x7C00 @tab 0x7D00 - 1 @tab Boot sector
2N/A@item 0x8000 @tab ? @tab GRUB kernel
2N/A@item 0x68000 @tab 0x78000 - 1 @tab Disk buffer
2N/A@item ? @tab 0x80000 - 1 @tab Protected mode stack
2N/A@item 0x80000 @tab ? @tab Heap
2N/A@item ? @tab 0xA0000 - 1 @tab Extended BIOS Data Area
2N/A@item 0xA0000 @tab 0xC0000 - 1 @tab Video RAM
2N/A@item 0xC0000 @tab 0x100000 - 1 @tab BIOS
2N/A@item 0x100000 @tab ? @tab Heap and module code
2N/A@node Video Subsystem
2N/A@chapter Video Subsystem
2N/A@c By VesaJääskeläinen
2N/AThis document contains specification for Video Subsystem for GRUB2.
2N/ACurrently only the usage interface is described in this document.
2N/AInternal structure of how video drivers are registering and how video
2N/Adriver manager works are not included here.
2N/A* Example usage of Video API::
2N/A@subsection grub_video_setup
2N/Agrub_video_setup (unsigned int width, unsigned int height, unsigned int mode_type);
2N/ADriver will use information provided to it to select best possible video mode and switch to it. Supported values for @code{mode_type} are @code{GRUB_VIDEO_MODE_TYPE_INDEX_COLOR} for index color modes, @code{GRUB_VIDEO_MODE_TYPE_RGB} for direct RGB color modes and @code{GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED} for double buffering. When requesting RGB mode, highest bits per pixel mode will be selected. When requesting Index color mode, mode with highest number of colors will be selected. If all parameters are specified as zero, video adapter will try to figure out best possible mode and initialize it, platform specific differences are allowed here. If there is no mode matching request, error X will be returned. If there are no problems, function returns @code{GRUB_ERR_NONE}.
2N/AThis function also performs following task upon succesful mode switch. Active rendering target is changed to screen and viewport is maximized to allow whole screen to be used when performing graphics operations. In RGB modes, emulated palette gets 16 entries containing default values for VGA palette, other colors are defined as black. When switching to Indexed Color mode, driver may set default VGA palette to screen if the video card allows the operation.
2N/A@subsection grub_video_restore
2N/Agrub_video_restore (void);
2N/AVideo subsystem will deinitialize activated video driver to restore old state of video device. This can be used to switch back to text mode.
2N/A@subsection grub_video_get_info
2N/Agrub_video_get_info (struct grub_video_mode_info *mode_info);
2N/Astruct grub_video_mode_info
2N/A /* Width of the screen. */
2N/A /* Height of the screen. */
2N/A unsigned int height;
2N/A /* Mode type bitmask. Contains information like is it Index color or
2N/A unsigned int mode_type;
2N/A /* Bits per pixel. */
2N/A /* Bytes per pixel. */
2N/A unsigned int bytes_per_pixel;
2N/A /* Pitch of one scanline. How many bytes there are for scanline. */
2N/A /* In index color mode, number of colors. In RGB mode this is 256. */
2N/A unsigned int number_of_colors;
2N/A /* Optimization hint how binary data is coded. */
2N/A enum grub_video_blit_format blit_format;
2N/A /* How many bits are reserved for red color. */
2N/A unsigned int red_mask_size;
2N/A /* What is location of red color bits. In Index Color mode, this is 0. */
2N/A unsigned int red_field_pos;
2N/A /* How many bits are reserved for green color. */
2N/A unsigned int green_mask_size;
2N/A /* What is location of green color bits. In Index Color mode, this is 0. */
2N/A unsigned int green_field_pos;
2N/A /* How many bits are reserved for blue color. */
2N/A unsigned int blue_mask_size;
2N/A /* What is location of blue color bits. In Index Color mode, this is 0. */
2N/A unsigned int blue_field_pos;
2N/A /* How many bits are reserved in color. */
2N/A unsigned int reserved_mask_size;
2N/A /* What is location of reserved color bits. In Index Color mode,
2N/A unsigned int reserved_field_pos;
2N/ASoftware developer can use this function to query properties of active rendering taget. Information provided here can be used by other parts of GRUB, like image loaders to convert loaded images to correct screen format to allow more optimized blitters to be used. If there there is no configured video driver with active screen, error @code{GRUB_ERR_BAD_DEVICE} is returned, otherwise @code{mode_info} is filled with valid information and @code{GRUB_ERR_NONE} is returned.
2N/A@subsection grub_video_get_blit_format
2N/Aenum grub_video_blit_format
2N/Agrub_video_get_blit_format (struct grub_video_mode_info *mode_info);
2N/Aenum grub_video_blit_format
2N/A /* Follow exactly field & mask information. */
2N/A GRUB_VIDEO_BLIT_FORMAT_RGBA,
2N/A /* Make optimization assumption. */
2N/A GRUB_VIDEO_BLIT_FORMAT_R8G8B8A8,
2N/A /* Follow exactly field & mask information. */
2N/A GRUB_VIDEO_BLIT_FORMAT_RGB,
2N/A /* Make optimization assumption. */
2N/A GRUB_VIDEO_BLIT_FORMAT_R8G8B8,
2N/A /* When needed, decode color or just use value as is. */
2N/A GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR
2N/AUsed to query how data could be optimized to suit specified video mode. Returns exact video format type, or a generic one if there is no definition for the type. For generic formats, use @code{grub_video_get_info} to query video color coding settings.
2N/A@subsection grub_video_set_palette
2N/Agrub_video_set_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
2N/Astruct grub_video_palette_data
2N/A grub_uint8_t r; /* Red color value (0-255). */
2N/A grub_uint8_t g; /* Green color value (0-255). */
2N/A grub_uint8_t b; /* Blue color value (0-255). */
2N/A grub_uint8_t a; /* Reserved bits value (0-255). */
2N/AUsed to setup indexed color palettes. If mode is RGB mode, colors will be set to emulated palette data. In Indexed Color modes, palettes will be set to hardware. Color values will be converted to suit requirements of the video mode. @code{start} will tell what hardware color index (or emulated color index) will be set to according information in first indice of @code{palette_data}, after that both hardware color index and @code{palette_data} index will be incremented until @code{count} number of colors have been set.
2N/A@subsection grub_video_get_palette
2N/Agrub_video_get_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
2N/Astruct grub_video_palette_data
2N/A grub_uint8_t r; /* Red color value (0-255). */
2N/A grub_uint8_t g; /* Green color value (0-255). */
2N/A grub_uint8_t b; /* Blue color value (0-255). */
2N/A grub_uint8_t a; /* Reserved bits value (0-255). */
2N/AUsed to query indexed color palettes. If mode is RGB mode, colors will be copied from emulated palette data. In Indexed Color modes, palettes will be read from hardware. Color values will be converted to suit structure format. @code{start} will tell what hardware color index (or emulated color index) will be used as a source for first indice of @code{palette_data}, after that both hardware color index and @code{palette_data} index will be incremented until @code{count} number of colors have been read.
2N/A@subsection grub_video_set_viewport
2N/Agrub_video_set_viewport (unsigned int x, unsigned int y, unsigned int width, unsigned int height);
2N/AUsed to specify viewport where draw commands are performed. When viewport is set, all draw commands coordinates relate to those specified by @code{x} and @code{y}. If draw commands try to draw over viewport, they are clipped. If developer requests larger than possible viewport, width and height will be clamped to fit screen. If @code{x} and @code{y} are out of bounds, all functions drawing to screen will not be displayed. In order to maximize viewport, use @code{grub_video_get_info} to query actual screen dimensions and provide that information to this function.
2N/A@subsection grub_video_get_viewport
2N/Agrub_video_get_viewport (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height);
2N/AUsed to query current viewport dimensions. Software developer can use this to choose best way to render contents of the viewport.
2N/A@subsection grub_video_map_color
2N/Agrub_video_map_color (grub_uint32_t color_name);
2N/AMap color can be used to support color themes in GRUB. There will be collection of color names that can be used to query actual screen mapped color data. Examples could be @code{GRUB_COLOR_CONSOLE_BACKGROUND}, @code{GRUB_COLOR_CONSOLE_TEXT}. The actual color defines are not specified at this point.
2N/A@subsection grub_video_map_rgb
2N/Agrub_video_map_rgb (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue);
2N/AMap RGB values to compatible screen color data. Values are expected to be in range 0-255 and in RGB modes they will be converted to screen color data. In index color modes, index color palette will be searched for specified color and then index is returned.
2N/A@subsection grub_video_map_rgba
2N/Agrub_video_map_rgba (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue, grub_uint8_t alpha);
2N/AMap RGBA values to compatible screen color data. Values are expected to be in range 0-255. In RGBA modes they will be converted to screen color data. In index color modes, index color palette will be searched for best matching color and its index is returned.
2N/A@subsection grub_video_unmap_color
2N/Agrub_video_unmap_color (grub_video_color_t color, grub_uint8_t *red, grub_uint8_t *green, grub_uint8_t *blue, grub_uint8_t *alpha);
2N/AUnmap color value from @code{color} to color channels in @code{red}, @code{green}, @code{blue} and @code{alpha}. Values will be in range 0-255. Active rendering target will be used for color domain. In case alpha information is not available in rendering target, it is assumed to be opaque (having value 255).
2N/A@subsection grub_video_fill_rect
2N/Agrub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height);
2N/AFill specified area limited by given coordinates within specified viewport. Negative coordinates are accepted in order to allow easy moving of rectangle within viewport. If coordinates are negative, area of the rectangle will be shrinken to follow size limits of the viewport.
2N/ASoftware developer should use either @code{grub_video_map_color}, @code{grub_video_map_rgb} or @code{grub_video_map_rgba} to map requested color to @code{color} parameter.
2N/A@subsection grub_video_blit_glyph
2N/Agrub_video_blit_glyph (struct grub_font_glyph *glyph, grub_video_color_t color, int x, int y);
2N/Astruct grub_font_glyph @{
2N/AUsed to blit glyph to viewport in specified coodinates. If glyph is at edge of viewport, pixels outside of viewport will be clipped out. Software developer should use either @code{grub_video_map_rgb} or @code{grub_video_map_rgba} to map requested color to @code{color} parameter.
2N/A@subsection grub_video_blit_bitmap
2N/Agrub_video_blit_bitmap (struct grub_video_bitmap *bitmap, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, unsigned int width, unsigned int height);
2N/Astruct grub_video_bitmap
2N/Aenum grub_video_blit_operators
2N/A GRUB_VIDEO_BLIT_REPLACE,
2N/A GRUB_VIDEO_BLIT_BLEND
2N/AUsed to blit bitmap to viewport in specified coordinates. If part of bitmap is outside of viewport region, it will be clipped out. Offsets affect bitmap position where data will be copied from. Negative values for both viewport coordinates and bitmap offset coordinates are allowed. If data is looked out of bounds of bitmap, color value will be assumed to be transparent. If viewport coordinates are negative, area of the blitted rectangle will be shrinken to follow size limits of the viewport and bitmap. Blitting operator @code{oper} specifies should source pixel replace data in screen or blend with pixel alpha value.
2N/ASoftware developer should use @code{grub_video_bitmap_create} or @code{grub_video_bitmap_load} to create or load bitmap data.
2N/A@subsection grub_video_blit_render_target
2N/Agrub_video_blit_render_target (struct grub_video_render_target *source, enum grub_video_blit_operators oper, int x, int y, int offset_x, int offset_y, unsigned int width, unsigned int height);
2N/Astruct grub_video_render_target @{
2N/A /* This is private data for video driver. Should not be accessed from elsewhere directly. */
2N/Aenum grub_video_blit_operators
2N/A GRUB_VIDEO_BLIT_REPLACE,
2N/A GRUB_VIDEO_BLIT_BLEND
2N/AUsed to blit source render target to viewport in specified coordinates. If part of source render target is outside of viewport region, it will be clipped out. If blitting operator is specified and source contains alpha values, resulting pixel color components will be calculated using formula ((src_color * src_alpha) + (dst_color * (255 - src_alpha)) / 255, if target buffer has alpha, it will be set to src_alpha. Offsets affect render target position where data will be copied from. If data is looked out of bounds of render target, color value will be assumed to be transparent. Blitting operator @code{oper} specifies should source pixel replace data in screen or blend with pixel alpha value.
2N/A@subsection grub_video_scroll
2N/Agrub_video_scroll (grub_video_color_t color, int dx, int dy);
2N/AUsed to scroll viewport to specified direction. New areas are filled with specified color. This function is used when screen is scroller up in video terminal.
2N/A@subsection grub_video_swap_buffers
2N/Agrub_video_swap_buffers (void);
2N/AIf double buffering is enabled, this swaps frontbuffer and backbuffer, in order to show values drawn to back buffer. Video driver is free to choose how this operation is techincally done.
2N/A@subsection grub_video_create_render_target
2N/Agrub_video_create_render_target (struct grub_video_render_target **result, unsigned int width, unsigned int height, unsigned int mode_type);
2N/Astruct grub_video_render_target @{
2N/A /* This is private data for video driver. Should not be accessed from elsewhere directly. */
2N/ADriver will use information provided to it to create best fitting render target. @code{mode_type} will be used to guide on selecting what features are wanted for render target. Supported values for @code{mode_type} are @code{GRUB_VIDEO_MODE_TYPE_INDEX_COLOR} for index color modes, @code{GRUB_VIDEO_MODE_TYPE_RGB} for direct RGB color modes and @code{GRUB_VIDEO_MODE_TYPE_ALPHA} for alpha component.
2N/A@subsection grub_video_delete_render_target
2N/Agrub_video_delete_render_target (struct grub_video_render_target *target);
2N/AUsed to delete previously created render target. If @code{target} contains @code{NULL} pointer, nothing will be done. If render target is correctly destroyed, GRUB_ERR_NONE is returned.
2N/A@subsection grub_video_set_active_render_target
2N/Agrub_video_set_active_render_target (struct grub_video_render_target *target);
2N/ASets active render target. If this comand is successful all drawing commands will be done to specified @code{target}. There is also special values for target, @code{GRUB_VIDEO_RENDER_TARGET_DISPLAY} used to reference screen's front buffer, @code{GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER} used to reference screen's front buffer (alias for @code{GRUB_VIDEO_RENDER_TARGET_DISPLAY}) and @code{GRUB_VIDEO_RENDER_TARGET_BACK_BUFFER} used to reference back buffer (if double buffering is enabled). If render target is correclty switched GRUB_ERR_NONE is returned. In no any event shall there be non drawable active render target.
2N/A@subsection grub_video_get_active_render_target
2N/Agrub_video_get_active_render_target (struct grub_video_render_target **target);
2N/AReturns currently active render target. It returns value in @code{target} that can be subsequently issued back to @code{grub_video_set_active_render_target}.
2N/A@node Example usage of Video API
2N/A@section Example usage of Video API
2N/A@subsection Example of screen setup
2N/A/* Try to initialize video mode 1024 x 768 with direct RGB. */
2N/Arc = grub_video_setup (1024, 768, GRUB_VIDEO_MODE_TYPE_RGB);
2N/Aif (rc != GRUB_ERR_NONE)
2N/A /* Fall back to standard VGA Index Color mode. */
2N/A rc = grub_video_setup (640, 480, GRUB_VIDEO_MODE_TYPE_INDEX);
2N/A if (rc != GRUB_ERR_NONE)
2N/A@subsection Example of setting up console viewport
2N/Agrub_uint32_t x, y, width, height;
2N/Agrub_video_color_t color;
2N/Astruct grub_font_glyph glyph;
2N/A/* Query existing viewport. */
2N/Agrub_video_get_viewport (&x, &y, &width, &height);
2N/A/* Fill background. */
2N/Acolor = grub_video_map_color (GRUB_COLOR_BACKGROUND);
2N/Agrub_video_fill_rect (color, 0, 0, width, height);
2N/A/* Setup console viewport. */
2N/Agrub_video_set_viewport (x + 10, y + 10, width - 20, height - 20);
2N/Agrub_video_get_viewport (&x, &y, &width, &height);
2N/Acolor = grub_video_map_color (GRUB_COLOR_CONSOLE_BACKGROUND);
2N/Agrub_video_fill_rect (color, 0, 0, width, height);
2N/A/* Draw text to viewport. */
2N/Acolor = grub_video_map_color (GRUB_COLOR_CONSOLE_TEXT);
2N/Agrub_font_get_glyph ('X', &glyph);
2N/Agrub_video_blit_glyph (&glyph, color, 0, 0);
2N/A@subsection grub_video_bitmap_create
2N/Agrub_err_t grub_video_bitmap_create (struct grub_video_bitmap **bitmap, unsigned int width, unsigned int height, enum grub_video_blit_format blit_format)
2N/ACreates a new bitmap with given dimensions and blitting format. Allocated bitmap data can then be modified freely and finally blitted with @code{grub_video_blit_bitmap} to rendering target.
2N/A@subsection grub_video_bitmap_destroy
2N/Agrub_err_t grub_video_bitmap_destroy (struct grub_video_bitmap *bitmap);
2N/AWhen bitmap is no longer needed, it can be freed from memory using this command. @code{bitmap} is previously allocated bitmap with @code{grub_video_bitmap_create} or loaded with @code{grub_video_bitmap_load}.
2N/A@subsection grub_video_bitmap_load
2N/Agrub_err_t grub_video_bitmap_load (struct grub_video_bitmap **bitmap, const char *filename);
2N/ATries to load given bitmap (@code{filename}) using registered bitmap loaders. In case bitmap format is not recognized or supported error @code{GRUB_ERR_BAD_FILE_TYPE} is returned.
2N/A@subsection grub_video_bitmap_get_width
2N/Aunsigned int grub_video_bitmap_get_width (struct grub_video_bitmap *bitmap);
2N/AReturns bitmap width.
2N/A@subsection grub_video_bitmap_get_height
2N/Aunsigned int grub_video_bitmap_get_height (struct grub_video_bitmap *bitmap);
2N/AReturn bitmap height.
2N/A@subsection grub_video_bitmap_get_mode_info
2N/Avoid grub_video_bitmap_get_mode_info (struct grub_video_bitmap *bitmap, struct grub_video_mode_info *mode_info);
2N/AReturns bitmap format details in form of @code{grub_video_mode_info}.
2N/A@subsection grub_video_bitmap_get_data
2N/Avoid *grub_video_bitmap_get_data (struct grub_video_bitmap *bitmap);
2N/AReturn pointer to bitmap data. Contents of the pointed data can be freely modified. There is no extra protection against going off the bounds so you have to be carefull how to access the data.
2N/A@node PFF2 Font File Format
2N/A@chapter PFF2 Font File Format
2N/A@c Author: Colin D. Bennett <colin@gibibit.com>
2N/A@c Date: 8 January 2009
2N/A@section Introduction
2N/AThe goal of this format is to provide a bitmap font format that is simple to
2N/Ause, compact, and cleanly supports Unicode.
2N/A@subsection Goals of the GRUB Font Format
2N/A@item Simple to read and use.
2N/ASince GRUB will only be reading the font files,
2N/Awe are more concerned with making the code to read the font simple than we
2N/Aare with writing the font.
2N/A@item Compact storage.
2N/AThe fonts will generally be stored in a small boot
2N/Apartition where GRUB is located, and this may be on a removable storage
2N/Adevice such as a CD or USB flash drive where space is more limited than it
2N/Ais on most hard drives.
2N/AGRUB should not have to deal with multiple character
2N/Aencodings. The font should always use Unicode character codes for simple
2N/Ainternationalization.
2N/A@subsection Why Another Font Format?
2N/AThere are many existing bitmap font formats that GRUB could use. However,
2N/Athere are aspects of these formats that may make them less than suitable for
2N/Ause in GRUB at this time:
2N/AInefficient storage; uses ASCII to describe properties and
2N/Ahexadecimal numbers in ASCII for the bitmap rows.
2N/AMany format variations such as byte order and bitmap padding (rows
2N/Apadded to byte, word, etc.) would result in more complex code to
2N/Ahandle the font format.
2N/A@section File Structure
2N/AA file @strong{section} consists of a 4-byte name, a 32-bit big-endian length (not
2N/Aincluding the name or length), and then @var{length} more section-type-specific
2N/AThe standard file extension for PFF2 font files is @file{.pf2}.
2N/A@subsection Section Types
2N/A@strong{File type ID} (ASCII string). This must be the first section in the file. It has length 4
2N/Aand the contents are the four bytes of the ASCII string @samp{PFF2}.
2N/A@strong{Font name} (ASCII string). This is the full font name including family,
2N/Aweight, style, and point size. For instance, "Helvetica Bold Italic 14".
2N/A@strong{Font family name} (ASCII string). For instance, "Helvetica". This should
2N/Abe included so that intelligent font substitution can take place.
2N/A@strong{Font weight} (ASCII string). Valid values are @samp{bold} and @samp{normal}.
2N/AThis should be included so that intelligent font substitution can take
2N/A@strong{Font slant} (ASCII string). Valid values are @samp{italic} and @samp{normal}.
2N/AThis should be included so that intelligent font substitution can take
2N/A@strong{Font point size} (uint16be).
2N/A@strong{Maximum character width in pixels} (uint16be).
2N/A@strong{Maximum character height in pixels} (uint16be).
2N/A@strong{Ascent in pixels} (uint16be). @xref{Font Metrics}, for details.
2N/A@strong{Descent in pixels} (uint16be). @xref{Font Metrics}, for details.
2N/A@strong{Character index.}
2N/AThe character index begins with a 32-bit big-endian unsigned integer
2N/Aindicating the total size of the section, not including this size value.
2N/AFor each character, there is an instance of the following entry structure:
2N/A@item @strong{Unicode code point.} (32-bit big-endian integer.)
2N/A@item @strong{Storage flags.} (byte.)
2N/AIf equal to 000 binary, then the character data is stored
2N/Auncompressed beginning at the offset indicated by the character's
2N/A@strong{offset} value.
2N/AIf equal to 001 binary, then the character data is stored within a
2N/Acompressed character definition block that begins at the offset
2N/Awithin the file indicated by the character's @strong{offset} value.
2N/A@item @strong{Offset.} (32-bit big-endian integer.)
2N/AA marker that indicates the remainder of the file is data accessed via
2N/Athe character index (CHIX) section. When reading this font file, the rest
2N/Aof the file can be ignored when scanning the sections. The length should
2N/Abe set to -1 (0xFFFFFFFF).
2N/ASupported data structures:
2N/AEach character definition consists of:
2N/A@item @strong{Width.}
2N/AWidth of the bitmap in pixels. The bitmap's extents
2N/Arepresent the glyph's bounding box. @code{uint16be}.
2N/A@item @strong{Height.}
2N/AHeight of the bitmap in pixels. The bitmap's extents
2N/Arepresent the glyph's bounding box. @code{uint16be}.
2N/A@item @strong{X offset.}
2N/AThe number of pixels to shift the bitmap by
2N/Ahorizontally before drawing the character. @code{int16be}.
2N/A@item @strong{Y offset.}
2N/AThe number of pixels to shift the bitmap by
2N/Avertically before drawing the character. @code{int16be}.
2N/A@item @strong{Device width.}
2N/AThe number of pixels to advance horizontally from
2N/Athis character's origin to the origin of the next character.
2N/A@item @strong{Bitmap data.}
2N/AThis is encoded as a string of bits. It is
2N/Aorganized as a row-major, top-down, left-to-right bitmap. The most
2N/Asignificant bit of each byte is taken to be the leftmost or uppermost
2N/Abit in the byte. For the sake of compact storage, rows are not padded
2N/Ato byte boundaries (
i.e., a single byte may contain bits belonging to
2N/Amultiple rows). The last byte of the bitmap @strong{is} padded with zero
2N/Abits in the bits positions to the right of the last used bit if the
2N/Abitmap data does not fill the last byte.
2N/AThe length of the @strong{bitmap data} field is (@var{width} * @var{height} + 7) / 8
2N/Ausing integer arithmetic, which is equivalent to ceil(@var{width} *
2N/A@var{height} / 8) using real number arithmetic.
2N/AIt remains to be determined whether bitmap fonts usually make all
2N/Aglyph bitmaps the same height, or if smaller glyphs are stored with
2N/Abitmaps having a lesser height. In the latter case, the baseline
2N/Awould have to be used to calculate the location the bitmap should be
2N/Aanchored at on screen.
2N/A@section Font Metrics
2N/AThe distance from the baseline to the top of most characters.
2N/ANote that in some cases characters may extend above the ascent.
2N/AThe distance from the baseline to the bottom of most characters. Note that
2N/Ain some cases characters may extend below the descent.
2N/AThe amount of space, in pixels, to leave between the descent of one line of
2N/Atext and the ascent of the next line. This metrics is not specified in the
2N/Acurrent file format; instead, the font rendering engine calculates a
2N/Areasonable leading value based on the other font metrics.
2N/A@item Horizonal leading.
2N/AThe amount of space, in pixels, to leave horizontally between the left and
2N/Aright edges of two adjacent glyphs. The @strong{device width} field determines
2N/Athe effective leading value that is used to render the font.
2N/A@image{font_char_metrics,,,,.png}
2N/AAn illustration of how the various font metrics apply to characters.
2N/A@node Graphical Menu Software Design
2N/A@chapter Graphical Menu Software Design
2N/A@c By Colin D. Bennett <colin@gibibit.com>
2N/A@c Date: 17 August 2008
2N/A* Command Line Window::
2N/A@section Introduction
2N/AThe @samp{gfxmenu} module provides a graphical menu interface for GRUB 2. It
2N/Afunctions as an alternative to the menu interface provided by the @samp{normal}
2N/Amodule, which uses the grub terminal interface to display a menu on a
2N/Acharacter-oriented terminal.
2N/AThe graphical menu uses the GRUB video API, which is currently for the VESA
2N/ABIOS extensions (VBE) 2.0+. This is supported on the i386-pc platform.
2N/AHowever, the graphical menu itself does not depend on using VBE, so if another
2N/AGRUB video driver were implemented, the @samp{gfxmenu} graphical menu would work
2N/Aon the new video driver as well.
2N/A@node Startup Sequence
2N/A@section Startup Sequence
2N/A@item (When @file{
gfxmenu.mod} is loaded with @command{insmod}, it will call @code{grub_menu_viewer_register()} to register itself.)
2N/A@section GUI Components
2N/AThe graphical menu implements a GUI component system that supports a
2N/Acontainer-based layout system. Components can be added to containers, and
2N/Acontainers (which are a type of component) can then be added to other
2N/Acontainers, to form a tree of components. Currently, the root component of
2N/Athis tree is a @samp{canvas} component, which allows manual layout of its child
2N/AComponents (non-container):
2N/A@item circular_progress
2N/A@item list (currently hard coded to be a boot menu list)
2N/AThe GUI component instances are created by the theme loader in
2N/Astatements such as @samp{+vbox@{ +label @{ text="Hello" @} +label@{ text="World" @} @}}
2N/Ato add components to the component tree root. By nesting the component
2N/Acreation statements in the theme file, the instantiated components are nested
2N/AWhen a component is added to a container, that new child is considered @strong{owned}
2N/Aby the container. Great care should be taken if the caller retains a
2N/Areference to the child component, since it will be destroyed if its parent
2N/Acontainer is destroyed. A better choice instead of storing a pointer to the
2N/Achild component is to use the component ID to find the desired component.
2N/AComponent IDs do not have to be unique (it is often useful to have multiple
2N/Acomponents with an ID of "__timeout__", for instance).
2N/AIn order to access and use components in the component tree, there are two
2N/A@item @code{grub_gui_find_by_id (root, id, callback, userdata)}:
2N/AThis function ecursively traverses the component tree rooted at @var{root}, and
2N/Afor every component that has an ID equal to @var{id}, calls the function pointed
2N/Ato by @var{callback} with the matching component and the void pointer @var{userdata}
2N/Aas arguments. The callback function can do whatever is desired to use the
2N/A@item @code{grub_gui_iterate_recursively (root, callback, userdata)}:
2N/AThis function calls the function pointed to by @var{callback} for every
2N/Acomponent that is a descendant of @var{root} in the component tree. When the
2N/Acallback function is called, the component and the void pointer @var{userdata}
2N/Aas arguments. The callback function can do whatever is desired to use the
2N/A@node Command Line Window
2N/A@section Command Line Window
2N/AThe terminal window used to provide command line access within the graphical
2N/Ait has been modified to allow rendering to an offscreen render target to allow
2N/Ait to be composed into the double buffering system that the graphical menu
2N/Aview uses. This is bad for performance, however, so it would probably be a
2N/Agood idea to make it possible to temporarily disable double buffering as long
2N/Aas the terminal window is visible. There are still unresolved problems that
2N/Aoccur when commands are executed from the terminal window that change the
2N/Agraphics mode. It's possible that making @code{grub_video_restore()} return to
2N/Athe graphics mode that was in use before @code{grub_video_setup()} was called
2N/Amight fix some of the problems.
2N/A@node Copying This Manual
2N/A@appendix Copying This Manual
2N/A* GNU Free Documentation License:: License for copying this manual.
2N/A@c Currently, we use only the Concept Index.