diff options
Diffstat (limited to 'docs/grub-dev.info')
| -rw-r--r-- | docs/grub-dev.info | 2171 |
1 files changed, 2171 insertions, 0 deletions
diff --git a/docs/grub-dev.info b/docs/grub-dev.info new file mode 100644 index 0000000..0510b36 --- /dev/null +++ b/docs/grub-dev.info @@ -0,0 +1,2171 @@ +This is /home/phcoder/grub2/bzr/grub-1.99/docs/grub-dev.info, produced +by makeinfo version 4.13 from +/home/phcoder/grub2/bzr/grub-1.99/docs/grub-dev.texi. + +This developer manual is for GNU GRUB (version 1.99, 13 April 2011). + + Copyright (C) 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 +Free Software Foundation, Inc. + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.2 or any later version published by the Free Software + Foundation; with no Invariant Sections. + +INFO-DIR-SECTION Kernel +START-INFO-DIR-ENTRY +* grub-dev: (grub-dev). The GRand Unified Bootloader Dev +END-INFO-DIR-ENTRY + + +File: grub-dev.info, Node: Top, Next: Getting the source code, Up: (dir) + +GNU GRUB developer manual +************************* + +This is the developer documentation of GNU GRUB, the GRand Unified +Bootloader, a flexible and powerful boot loader program for a wide +range of architectures. + + This edition documents version 1.99. + + This developer manual is for GNU GRUB (version 1.99, 13 April 2011). + + Copyright (C) 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 +Free Software Foundation, Inc. + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.2 or any later version published by the Free Software + Foundation; with no Invariant Sections. + +* Menu: + +* Getting the source code:: +* Finding your way around:: +* Coding style:: +* Contributing Changes:: +* Error Handling:: +* CIA:: +* BIOS port memory map:: +* Video Subsystem:: +* PFF2 Font File Format:: +* Graphical Menu Software Design:: +* Copying This Manual:: Copying This Manual +* Index:: + + +File: grub-dev.info, Node: Getting the source code, Next: Finding your way around, Prev: Top, Up: Top + +1 Getting the source code +************************* + +GRUB is maintained using the Bazaar revision control system +(http://bazaar-vcs.org/). To fetch the primary development branch: + + bzr get http://bzr.savannah.gnu.org/r/grub/trunk/grub + + The GRUB developers maintain several other branches with work in +progress. Of these, the most interesting is the experimental branch, +which is a staging area for new code which we expect to eventually +merge into trunk but which is not yet ready: + + bzr get http://bzr.savannah.gnu.org/r/grub/branches/experimental + + Once you have used `bzr get' to fetch an initial copy of a branch, +you can use `bzr pull' to keep it up to date. If you have modified your +local version, you may need to resolve conflicts when pulling. + + +File: grub-dev.info, Node: Coding style, Next: Contributing Changes, Prev: Finding your way around, Up: Top + +2 Coding style +************** + +Basically we follow the GNU Coding Standards +(http://www.gnu.org/prep/standards_toc.html). We define additional +conventions for GRUB here. + +* Menu: + +* Naming Conventions:: +* Functions:: +* Variables:: +* Types:: +* Macros:: +* Comments:: +* Multi-Line Comments:: + + +File: grub-dev.info, Node: Naming Conventions, Next: Functions, Up: Coding style + +2.1 Naming Conventions +====================== + +All 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. + + +File: grub-dev.info, Node: Functions, Next: Variables, Prev: Naming Conventions, Up: Coding style + +2.2 Functions +============= + +If 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. + + After 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). + + If a function is local, its name may not start with any prefix. It +must start with a verb. + + +File: grub-dev.info, Node: Variables, Next: Types, Prev: Functions, Up: Coding style + +2.3 Variables +============= + +The 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_. + + After 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). + + If 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. + + If a variable is local, you may choose any shorter name, as long as +it wouldn't make code less readable (e.g. i). + + +File: grub-dev.info, Node: Types, Next: Macros, Prev: Variables, Up: Coding style + +2.4 Types +========= + +The 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_. + + The name must be suffixed with _t, to emphasize the fact that it is +a type but not a variable or a function. + + +File: grub-dev.info, Node: Macros, Next: Comments, Prev: Types, Up: Coding style + +2.5 Macros +========== + +If 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. + + +File: grub-dev.info, Node: Comments, Next: Multi-Line Comments, Prev: Macros, Up: Coding style + +2.6 Comments +============ + +All comments shall be C-style comments, of the form `/* ... */'. + + Comments 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. + + Acceptable: + /* The page # that is the front buffer. */ + int displayed_page; + /* The page # that is the back buffer. */ + int render_page; + + Unacceptable: + int displayed_page; /* The page # that is the front buffer. */ + int render_page; /* The page # that is the back buffer. */ + + +File: grub-dev.info, Node: Multi-Line Comments, Prev: Comments, Up: Coding style + +2.7 Multi-Line Comments +======================= + +Comments spanning multiple lines shall be formatted with all lines +after the first aligned with the first line. + + Asterisk characters should not be repeated a the start of each +subsequent line. + + Acceptable: + /* This is a comment + which spans multiple lines. + It is long. */ + + Unacceptable: + /* + * This is a comment + * which spans multiple lines. + * It is long. */ + + The opening `/*' and closing `*/' should be placed together on a +line with text. + + +File: grub-dev.info, Node: Finding your way around, Next: Coding style, Prev: Getting the source code, Up: Top + +3 Finding your way around +************************* + +Here is a brief map of the GRUB code base. + + GRUB uses Autoconf and Automake, with most of the Automake input +generated by AutoGen. The top-level build rules are in `configure.ac', +`grub-core/Makefile.core.def', and `Makefile.util.def'. Each block in +a `*.def' file represents a build target, and specifies the source +files used to build it on various platforms. The `*.def' files are +processed into AutoGen input by `gentpl.py' (which you only need to +look at if you are extending the build system). If you are adding a new +module which follows an existing pattern, such as a new command or a new +filesystem implementation, it is usually easiest to grep +`grub-core/Makefile.core.def' and `Makefile.util.def' for an existing +example of that pattern to find out where it should be added. + + In general, code that may be run at boot time is in a subdirectory of +`grub-core', while code that is only run from within a full operating +system is in a subdirectory of the top level. + + Low-level boot code, such as the MBR implementation on PC BIOS +systems, is in the `grub-core/boot/' directory. + + The GRUB kernel is in `grub-core/kern/'. This contains core +facilities such as the device, disk, and file frameworks, environment +variable handling, list processing, and so on. The kernel should +contain enough to get up to a rescue prompt. Header files for kernel +facilities, among others, are in `include/'. + + Terminal implementations are in `grub-core/term/'. + + Disk access code is spread across `grub-core/disk/' (for accessing +the disk devices themselves), `grub-core/partmap/' (for interpreting +partition table data), and `grub-core/fs/' (for accessing filesystems). +Note that, with the odd specialised exception, GRUB only contains code +to _read_ from filesystems and tries to avoid containing any code to +_write_ to filesystems; this lets us confidently assure users that GRUB +cannot be responsible for filesystem corruption. + + PCI and USB bus handling is in `grub-core/bus/'. + + Video handling code is in `grub-core/video/'. The graphical menu +system uses this heavily, but is in a separate directory, +`grub-core/gfxmenu/'. + + Most commands are implemented by files in `grub-core/commands/', with +the following exceptions: + + * A few core commands live in `grub-core/kern/corecmd.c'. + + * Commands related to normal mode live under `grub-core/normal/'. + + * Commands that load and boot kernels live under `grub-core/loader/'. + + * The `loopback' command is really a disk device, and so lives in + `grub-core/disk/loopback.c'. + + * The `gettext' command lives under `grub-core/gettext/'. + + * The `loadfont' and `lsfonts' commands live under `grub-core/font/'. + + * The `serial', `terminfo', and `background_image' commands live + under `grub-core/term/'. + + * The `efiemu_*' commands live under `grub-core/efiemu/'. + + There are a few other special-purpose exceptions; grep for them if +they matter to you. + + Utility programs meant to be run from a full operating system are in +`util/'. + + +File: grub-dev.info, Node: Contributing Changes, Next: Error Handling, Prev: Coding style, Up: Top + +4 Contributing changes +********************** + +Contributing changes to GRUB 2 is welcomed activity. However we have a +bit of control what kind of changes will be accepted to GRUB 2. +Therefore it is important to discuss your changes on grub-devel mailing +list (see MailingLists). On this page there are some basic details on +the development process and activities. + + First of all you should come up with the idea yourself what you want +to contribute. If you do not have that beforehand you are advised to +study this manual and try GRUB 2 out to see what you think is missing +from there. + + Here are additional pointers: + * `https://savannah.gnu.org/task/?group=grub GRUB's Task Tracker' + + * `https://savannah.gnu.org/bugs/?group=grub GRUB's Bug Tracker' + + If you intended to make changes to GRUB Legacy (<=0.97) those are +not accepted anymore. + +* Menu: + +* Getting started:: +* Typical Developer Experience:: +* When you are approved for write access to project's files:: + + +File: grub-dev.info, Node: Getting started, Next: Typical Developer Experience, Up: Contributing Changes + +4.1 Getting started +=================== + + * Always use latest GRUB 2 source code. So get that first. + + For 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. + + Please check Savannah's GRUB project page for details how to get + newest bzr: GRUB 2 bzr Repository + (http://savannah.gnu.org/bzr/?group=grub) + + * Compile it and try it out. + + It is always good idea to first see that things work somehow and + after that to start to implement new features or develop fixes to + bugs. + + * Study the code. + + There are sometimes odd ways to do things in GRUB 2 code base. + This is mainly related to limited environment where GRUB 2 is + being executed. You usually do not need to understand it all so + it is better to only try to look at places that relates to your + work. Please do not hesitate to ask for help if there is something + that you do not understand. + + * Develop a new feature. + + Now that you know what to do and how it should work in GRUB 2 code + base, please be free to develop it. If you have not so far + announced your idea on grub-devel mailing list, please do it now. + This is to make sure you are not wasting your time working on the + solution that will not be integrated to GRUB 2 code base. + + You might want to study our coding style before starting + development so you do not need to change much of the code when + your patch is being reviewed. (see *note Coding style::) + + For every accepted patch there has to exist a ChangeLog entry. Our + ChangeLog consist of changes within source code and are not + describing about what the change logically does. Please see + examples from previous entries. + + Also remember that GRUB 2 is licensed under GPLv3 license and that + usually means that you are not allowed to copy pieces of code from + other projects. Even if the source project's license would be + compatible with GPLv3, please discuss it beforehand on grub-devel + mailing list. + + * Test your change. + + Test that your change works properly. Try it out a couple of + times, preferably on different systems, and try to find problems + with it. + + * Publish your change. + + When you are happy with your change, first make sure it is + compilable with latest development version of GRUB 2. After that + please send a patch to grub-devel for review. Please describe in + your email why you made the change, what it changes and so on. + Please be prepared to receive even discouraging comments about + your patch. There is usually at least something that needs to be + improved in every patch. + + Please use unified diff to make your patch (good match of + arguments for diff is `-pruN'). + + * Respond to received feedback. + + If you are asked to modify your patch, please do that and resubmit + it for review. If your change is large you are required to submit + a copyright agreement to FSF. Please keep in mind that if you are + asked to submit for copyright agreement, process can take some + time and is mandatory in order to get your changes integrated. + + If you are not on grub-devel to respond to questions, most likely + your patch will not be accepted. Also if problems arise from your + changes later on, it would be preferable that you also fix the + problem. So stay around for a while. + + * Your patch is accepted. + + Good 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. + + Now you are welcome to do further improvements :) + + +File: grub-dev.info, Node: Typical Developer Experience, Next: When you are approved for write access to project's files, Prev: Getting started, Up: Contributing Changes + +4.2 Typical Developer Experience +================================ + +The typical experience for a developer in this project is the following: + + 1. You find yourself wanting to do something (e.g. fixing a bug). + + 2. You show some result in the mailing list or the IRC. + + 3. You are getting to be known to other developers. + + 4. You accumulate significant amount of contribution, so copyright + assignment is processed. + + 5. You are free to check in your changes on your own, legally + speaking. + + At this point, it is rather annoying that you ought to ask somebody +else every change to be checked in. For efficiency, it is far better, +if you can commit it yourself. Therefore, our policy is to give you the +write permission to our official repository, once you have shown your +skill and will, and the FSF clerks have dealt with your copyright +assignment. + + +File: grub-dev.info, Node: When you are approved for write access to project's files, Prev: Typical Developer Experience, Up: Contributing Changes + +4.3 When you are approved for write access to project's files +============================================================= + +As you might know, GRUB is hosted on +`https://savannah.gnu.org/projects/grub Savannah', thus the membership +is managed by Savannah. This means that, if you want to be a member of +this project: + + 1. You need to create your own account on Savannah. + + 2. You can submit "Request for Inclusion" from "My Groups" on + Savannah. + + Then, one of the admins can approve your request, and you will be a +member. If you don't want to use the Savannah interface to submit a +request, you can simply notify the admins by email or something else, +alternatively. But you still need to create an account beforehand. + + NOTE: we sometimes receive a "Request for Inclusion" from an unknown +person. In this case, the request would be just discarded, since it is +too dangerous to allow a stranger to be a member, which automatically +gives him a commit right to the repository, both for a legal reason and +for a technical reason. + + If your intention is to just get started, please do not submit a +inclusion request. Instead, please subscribe to the mailing list, and +communicate first (e.g. sending a patch, asking a question, commenting +on another message...). + + +File: grub-dev.info, Node: Error Handling, Next: CIA, Prev: Contributing Changes, Up: Top + +5 Error Handling +**************** + +Error handling in GRUB 2 is based on exception handling model. As C +language doesn't directly support exceptions, exception handling +behavior is emulated in software. + + When exception is raised, function must return to calling function. +If calling function does not provide handling of the exception it must +return back to its calling function and so on, until exception is +handled. If exception is not handled before prompt is displayed, error +message will be shown to user. + + Exception information is stored on `grub_errno' global variable. If +`grub_errno' variable contains value `GRUB_ERR_NONE', there is no active +exception and application can continue normal processing. When +`grub_errno' has other value, it is required that application code +either handles this error or returns instantly to caller. If function +is with return type `grub_err_t' is about to return `GRUB_ERR_NONE', it +should not set `grub_errno' to that value. Only set `grub_errno' in +cases where there is error situation. + + Simple exception forwarder. + grub_err_t + forwarding_example (void) + { + /* Call function that might cause exception. */ + foobar (); + + /* No special exception handler, just forward possible exceptions. */ + if (grub_errno != GRUB_ERR_NONE) + { + return grub_errno; + } + + /* All is OK, do more processing. */ + + /* Return OK signal, to caller. */ + return GRUB_ERR_NONE; + } + + Error reporting has two components, the actual error code (of type +`grub_err_t') and textual message that will be displayed to user. List +of valid error codes is listed in header file `include/grub/err.h'. +Textual error message can contain any textual data. At time of writing, +error message can contain up to 256 characters (including terminating +NUL). To ease error reporting there is a helper function `grub_error' +that allows easier formatting of error messages and should be used +instead of writing directly to global variables. + + Example of error reporting. + grub_err_t + failing_example () + { + return grub_error (GRUB_ERR_FILE_NOT_FOUND, + "Failed to read %s, tried %d times.", + "test.txt", + 10); + } + + If there is a special reason that error code does not need to be +taken account, `grub_errno' can be zeroed back to `GRUB_ERR_NONE'. In +cases like this all previous error codes should have been handled +correctly. This makes sure that there are no unhandled exceptions. + + Example of zeroing `grub_errno'. + grub_err_t + probe_example () + { + /* Try to probe device type 1. */ + probe_for_device (); + if (grub_errno == GRUB_ERR_NONE) + { + /* Device type 1 was found on system. */ + register_device (); + return GRUB_ERR_NONE; + } + /* Zero out error code. */ + grub_errno = GRUB_ERR_NONE; + + /* No device type 1 found, try to probe device type 2. */ + probe_for_device2 (); + if (grub_errno == GRUB_ERR_NONE) + { + /* Device type 2 was found on system. */ + register_device2 (); + return GRUB_ERR_NONE; + } + /* Zero out error code. */ + grub_errno = GRUB_ERR_NONE; + + /* Return custom error message. */ + return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No device type 1 or 2 found."); + } + + Some times there is a need to continue processing even if there is a +error state in application. In situations like this, there is a needed +to save old error state and then call other functions that might fail. +To aid in this, there is a error stack implemented. Error state can be +pushed to error stack by calling function `grub_error_push ()'. When +processing has been completed, `grub_error_pop ()' can be used to pop +error state from stack. Error stack contains predefined amount of error +stack items. Error stack is protected for overflow and marks these +situations so overflow error does not get unseen. If there is no space +available to store error message, it is simply discarded and overflow +will be marked as happened. When overflow happens, it most likely will +corrupt error stack consistency as for pushed error there is no matching +pop, but overflow message will be shown to inform user about the +situation. Overflow message will be shown at time when prompt is about +to be drawn. + + Example usage of error stack. + /* Save possible old error message. */ + grub_error_push (); + + /* Do your stuff here. */ + call_possibly_failing_function (); + + if (grub_errno != GRUB_ERR_NONE) + { + /* Inform rest of the code that there is error (grub_errno + is set). There is no pop here as we want both error states + to be displayed. */ + return; + } + + /* Restore old error state by popping previous item from stack. */ + grub_error_pop (); + + +File: grub-dev.info, Node: CIA, Next: BIOS port memory map, Prev: Error Handling, Up: Top + +6 CIA +***** + +If you have commit access, please setup CIA in your Bazaar config so +those in IRC receive notification of your commits. + + In `~/.bazaar/bazaar.conf', add "cia_send_revno = true". +Optionally, you can also add "cia_user = myusername" if you'd like CIA +service to use a specific account (for statistical purpose). + + In the `.bzr/branch/branch.conf' of your checkout branch, "set +nickname = /path_to_this_branch" and "cia_project = GNU GRUB". + + Additionally, please set cia_send_revno in the [DEFAULT] section of +your `~/.bazaar/bazaar.conf'. E.g.: + + [DEFAULT] + cia_send_revno = true + + Remember to install cia-clients (Debian/Ubuntu package) to be able +to use CIA. + + Keep in mind Bazaar sends notifications for all commits to branches +that have this setting, regardless of whether they're bound branches +(checkouts) or not. So if you make local commits in a non-bound branch +and it bothers you that others can read them, do not use this setting. + + +File: grub-dev.info, Node: BIOS port memory map, Next: Video Subsystem, Prev: CIA, Up: Top + +7 BIOS port memory map +********************** + +Start End Usage +-------------------------------------------------------------------- +0 0x1000 - 1 BIOS and real mode interrupts +0x07BE 0x07FF Partition table passed to another + boot loader +? 0x2000 - 1 Real mode stack +0x7C00 0x7D00 - 1 Boot sector +0x8000 ? GRUB kernel +0x68000 0x78000 - 1 Disk buffer +? 0x80000 - 1 Protected mode stack +0x80000 ? Heap +? 0xA0000 - 1 Extended BIOS Data Area +0xA0000 0xC0000 - 1 Video RAM +0xC0000 0x100000 - 1 BIOS +0x100000 ? Heap and module code + + +File: grub-dev.info, Node: Video Subsystem, Next: PFF2 Font File Format, Prev: BIOS port memory map, Up: Top + +8 Video Subsystem +***************** + +This document contains specification for Video Subsystem for GRUB2. +Currently only the usage interface is described in this document. +Internal structure of how video drivers are registering and how video +driver manager works are not included here. + +* Menu: + +* Video API:: +* Bitmap API:: +* Example usage of Video API:: + + +File: grub-dev.info, Node: Video API, Next: Bitmap API, Up: Video Subsystem + +8.1 Video API +============= + +8.1.1 grub_video_setup +---------------------- + + * Prototype: + grub_err_t + grub_video_setup (unsigned int width, unsigned int height, unsigned int mode_type); + + * Description: + + Driver will use information provided to it to select best possible + video mode and switch to it. Supported values for `mode_type' are + `GRUB_VIDEO_MODE_TYPE_INDEX_COLOR' for index color modes, + `GRUB_VIDEO_MODE_TYPE_RGB' for direct RGB color modes and + `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 `GRUB_ERR_NONE'. + + This 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. + + +8.1.2 grub_video_restore +------------------------ + + * Prototype: + + grub_err_t + grub_video_restore (void); + + * Description: + + Video subsystem will deinitialize activated video driver to + restore old state of video device. This can be used to switch back + to text mode. + +8.1.3 grub_video_get_info +------------------------- + + * Prototype: + + grub_err_t + grub_video_get_info (struct grub_video_mode_info *mode_info); + + struct grub_video_mode_info + { + /* Width of the screen. */ + unsigned int width; + /* Height of the screen. */ + unsigned int height; + /* Mode type bitmask. Contains information like is it Index color or + RGB mode. */ + unsigned int mode_type; + /* Bits per pixel. */ + unsigned int bpp; + /* Bytes per pixel. */ + unsigned int bytes_per_pixel; + /* Pitch of one scanline. How many bytes there are for scanline. */ + unsigned int pitch; + /* In index color mode, number of colors. In RGB mode this is 256. */ + unsigned int number_of_colors; + /* Optimization hint how binary data is coded. */ + enum grub_video_blit_format blit_format; + /* How many bits are reserved for red color. */ + unsigned int red_mask_size; + /* What is location of red color bits. In Index Color mode, this is 0. */ + unsigned int red_field_pos; + /* How many bits are reserved for green color. */ + unsigned int green_mask_size; + /* What is location of green color bits. In Index Color mode, this is 0. */ + unsigned int green_field_pos; + /* How many bits are reserved for blue color. */ + unsigned int blue_mask_size; + /* What is location of blue color bits. In Index Color mode, this is 0. */ + unsigned int blue_field_pos; + /* How many bits are reserved in color. */ + unsigned int reserved_mask_size; + /* What is location of reserved color bits. In Index Color mode, + this is 0. */ + unsigned int reserved_field_pos; + }; + + * Description: + + Software 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 `GRUB_ERR_BAD_DEVICE' is returned, otherwise + `mode_info' is filled with valid information and `GRUB_ERR_NONE' + is returned. + +8.1.4 grub_video_get_blit_format +-------------------------------- + + * Prototype: + + enum grub_video_blit_format + grub_video_get_blit_format (struct grub_video_mode_info *mode_info); + + enum grub_video_blit_format + { + /* Follow exactly field & mask information. */ + GRUB_VIDEO_BLIT_FORMAT_RGBA, + /* Make optimization assumption. */ + GRUB_VIDEO_BLIT_FORMAT_R8G8B8A8, + /* Follow exactly field & mask information. */ + GRUB_VIDEO_BLIT_FORMAT_RGB, + /* Make optimization assumption. */ + GRUB_VIDEO_BLIT_FORMAT_R8G8B8, + /* When needed, decode color or just use value as is. */ + GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR + }; + + * Description: + + Used 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 + `grub_video_get_info' to query video color coding settings. + +8.1.5 grub_video_set_palette +---------------------------- + + * Prototype: + + grub_err_t + grub_video_set_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data); + + struct grub_video_palette_data + { + grub_uint8_t r; /* Red color value (0-255). */ + grub_uint8_t g; /* Green color value (0-255). */ + grub_uint8_t b; /* Blue color value (0-255). */ + grub_uint8_t a; /* Reserved bits value (0-255). */ + }; + + * Description: + + Used 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. `start' will tell what + hardware color index (or emulated color index) will be set to + according information in first indice of `palette_data', after + that both hardware color index and `palette_data' index will be + incremented until `count' number of colors have been set. + +8.1.6 grub_video_get_palette +---------------------------- + + * Prototype: + + grub_err_t + grub_video_get_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data); + + struct grub_video_palette_data + { + grub_uint8_t r; /* Red color value (0-255). */ + grub_uint8_t g; /* Green color value (0-255). */ + grub_uint8_t b; /* Blue color value (0-255). */ + grub_uint8_t a; /* Reserved bits value (0-255). */ + }; + + * Description: + + Used 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. `start' will tell what + hardware color index (or emulated color index) will be used as a + source for first indice of `palette_data', after that both + hardware color index and `palette_data' index will be incremented + until `count' number of colors have been read. + +8.1.7 grub_video_set_viewport +----------------------------- + + * Prototype: + + grub_err_t + grub_video_set_viewport (unsigned int x, unsigned int y, unsigned int width, unsigned int height); + + * Description: + + Used to specify viewport where draw commands are performed. When + viewport is set, all draw commands coordinates relate to those + specified by `x' and `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 `x' and `y' are out of bounds, all functions drawing to screen + will not be displayed. In order to maximize viewport, use + `grub_video_get_info' to query actual screen dimensions and + provide that information to this function. + +8.1.8 grub_video_get_viewport +----------------------------- + + * Prototype: + + grub_err_t + grub_video_get_viewport (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height); + + * Description: + + Used to query current viewport dimensions. Software developer can + use this to choose best way to render contents of the viewport. + +8.1.9 grub_video_map_color +-------------------------- + + * Prototype: + + grub_video_color_t + grub_video_map_color (grub_uint32_t color_name); + + * Description: + + Map 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 + `GRUB_COLOR_CONSOLE_BACKGROUND', `GRUB_COLOR_CONSOLE_TEXT'. The + actual color defines are not specified at this point. + +8.1.10 grub_video_map_rgb +------------------------- + + * Prototype: + + grub_video_color_t + grub_video_map_rgb (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue); + + * Description: + + Map 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. + +8.1.11 grub_video_map_rgba +-------------------------- + + * Prototype: + + grub_video_color_t + grub_video_map_rgba (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue, grub_uint8_t alpha); + + * Description: + + Map 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. + +8.1.12 grub_video_unmap_color +----------------------------- + + * Prototype: + + grub_err_t + grub_video_unmap_color (grub_video_color_t color, grub_uint8_t *red, grub_uint8_t *green, grub_uint8_t *blue, grub_uint8_t *alpha); + + * Description: + + Unmap color value from `color' to color channels in `red', + `green', `blue' and `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). + +8.1.13 grub_video_fill_rect +--------------------------- + + * Prototype: + + grub_err_t + grub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height); + + * Description: + + Fill 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. + + Software developer should use either `grub_video_map_color', + `grub_video_map_rgb' or `grub_video_map_rgba' to map requested + color to `color' parameter. + +8.1.14 grub_video_blit_glyph +---------------------------- + + * Prototype: + + grub_err_t + grub_video_blit_glyph (struct grub_font_glyph *glyph, grub_video_color_t color, int x, int y); + + struct grub_font_glyph { + /* TBD. */ + }; + + * Description: + + Used 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 `grub_video_map_rgb' or + `grub_video_map_rgba' to map requested color to `color' parameter. + +8.1.15 grub_video_blit_bitmap +----------------------------- + + * Prototype: + + grub_err_t + grub_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); + + struct grub_video_bitmap + { + /* TBD. */ + }; + + enum grub_video_blit_operators + { + GRUB_VIDEO_BLIT_REPLACE, + GRUB_VIDEO_BLIT_BLEND + }; + + * Description: + + Used 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 `oper' specifies should source pixel replace + data in screen or blend with pixel alpha value. + + Software developer should use `grub_video_bitmap_create' or + `grub_video_bitmap_load' to create or load bitmap data. + +8.1.16 grub_video_blit_render_target +------------------------------------ + + * Prototype: + + grub_err_t + grub_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); + + struct grub_video_render_target { + /* This is private data for video driver. Should not be accessed from elsewhere directly. */ + }; + + enum grub_video_blit_operators + { + GRUB_VIDEO_BLIT_REPLACE, + GRUB_VIDEO_BLIT_BLEND + }; + + * Description: + + Used 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 `oper' specifies should + source pixel replace data in screen or blend with pixel alpha + value. + +8.1.17 grub_video_scroll +------------------------ + + * Prototype: + + grub_err_t + grub_video_scroll (grub_video_color_t color, int dx, int dy); + + * Description: + + Used 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. + +8.1.18 grub_video_swap_buffers +------------------------------ + + * Prototype: + + grub_err_t + grub_video_swap_buffers (void); + + * Description: + + If 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. + +8.1.19 grub_video_create_render_target +-------------------------------------- + + * Prototype: + + grub_err_t + grub_video_create_render_target (struct grub_video_render_target **result, unsigned int width, unsigned int height, unsigned int mode_type); + + struct grub_video_render_target { + /* This is private data for video driver. Should not be accessed from elsewhere directly. */ + }; + + * Description: + + Driver will use information provided to it to create best fitting + render target. `mode_type' will be used to guide on selecting what + features are wanted for render target. Supported values for + `mode_type' are `GRUB_VIDEO_MODE_TYPE_INDEX_COLOR' for index color + modes, `GRUB_VIDEO_MODE_TYPE_RGB' for direct RGB color modes and + `GRUB_VIDEO_MODE_TYPE_ALPHA' for alpha component. + +8.1.20 grub_video_delete_render_target +-------------------------------------- + + * Prototype: + + grub_err_t + grub_video_delete_render_target (struct grub_video_render_target *target); + + * Description: + + Used to delete previously created render target. If `target' + contains `NULL' pointer, nothing will be done. If render target is + correctly destroyed, GRUB_ERR_NONE is returned. + +8.1.21 grub_video_set_active_render_target +------------------------------------------ + + * Prototype: + + grub_err_t + grub_video_set_active_render_target (struct grub_video_render_target *target); + + * Description: + + Sets active render target. If this comand is successful all + drawing commands will be done to specified `target'. There is also + special values for target, `GRUB_VIDEO_RENDER_TARGET_DISPLAY' used + to reference screen's front buffer, + `GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER' used to reference screen's + front buffer (alias for `GRUB_VIDEO_RENDER_TARGET_DISPLAY') and + `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. + + +8.1.22 grub_video_get_active_render_target +------------------------------------------ + + * Prototype: + + grub_err_t + grub_video_get_active_render_target (struct grub_video_render_target **target); + + * Description: + + Returns currently active render target. It returns value in + `target' that can be subsequently issued back to + `grub_video_set_active_render_target'. + + +File: grub-dev.info, Node: Example usage of Video API, Prev: Bitmap API, Up: Video Subsystem + +8.2 Example usage of Video API +============================== + +8.2.1 Example of screen setup +----------------------------- + + grub_err_t rc; + /* Try to initialize video mode 1024 x 768 with direct RGB. */ + rc = grub_video_setup (1024, 768, GRUB_VIDEO_MODE_TYPE_RGB); + if (rc != GRUB_ERR_NONE) + { + /* Fall back to standard VGA Index Color mode. */ + rc = grub_video_setup (640, 480, GRUB_VIDEO_MODE_TYPE_INDEX); + if (rc != GRUB_ERR_NONE) + { + /* Handle error. */ + } + } + +8.2.2 Example of setting up console viewport +-------------------------------------------- + + grub_uint32_t x, y, width, height; + grub_video_color_t color; + struct grub_font_glyph glyph; + grub_err_t rc; + /* Query existing viewport. */ + grub_video_get_viewport (&x, &y, &width, &height); + /* Fill background. */ + color = grub_video_map_color (GRUB_COLOR_BACKGROUND); + grub_video_fill_rect (color, 0, 0, width, height); + /* Setup console viewport. */ + grub_video_set_viewport (x + 10, y + 10, width - 20, height - 20); + grub_video_get_viewport (&x, &y, &width, &height); + color = grub_video_map_color (GRUB_COLOR_CONSOLE_BACKGROUND); + grub_video_fill_rect (color, 0, 0, width, height); + /* Draw text to viewport. */ + color = grub_video_map_color (GRUB_COLOR_CONSOLE_TEXT); + grub_font_get_glyph ('X', &glyph); + grub_video_blit_glyph (&glyph, color, 0, 0); + + +File: grub-dev.info, Node: Bitmap API, Next: Example usage of Video API, Prev: Video API, Up: Video Subsystem + +8.3 Bitmap API +============== + +8.3.1 grub_video_bitmap_create +------------------------------ + + * Prototype: + grub_err_t grub_video_bitmap_create (struct grub_video_bitmap **bitmap, unsigned int width, unsigned int height, enum grub_video_blit_format blit_format) + + * Description: + + Creates a new bitmap with given dimensions and blitting format. + Allocated bitmap data can then be modified freely and finally + blitted with `grub_video_blit_bitmap' to rendering target. + +8.3.2 grub_video_bitmap_destroy +------------------------------- + + * Prototype: + grub_err_t grub_video_bitmap_destroy (struct grub_video_bitmap *bitmap); + + * Description: + + When bitmap is no longer needed, it can be freed from memory using + this command. `bitmap' is previously allocated bitmap with + `grub_video_bitmap_create' or loaded with `grub_video_bitmap_load'. + +8.3.3 grub_video_bitmap_load +---------------------------- + + * Prototype: + grub_err_t grub_video_bitmap_load (struct grub_video_bitmap **bitmap, const char *filename); + + * Description: + + Tries to load given bitmap (`filename') using registered bitmap + loaders. In case bitmap format is not recognized or supported + error `GRUB_ERR_BAD_FILE_TYPE' is returned. + +8.3.4 grub_video_bitmap_get_width +--------------------------------- + + * Prototype: + unsigned int grub_video_bitmap_get_width (struct grub_video_bitmap *bitmap); + + * Description: + + Returns bitmap width. + +8.3.5 grub_video_bitmap_get_height +---------------------------------- + + * Prototype: + unsigned int grub_video_bitmap_get_height (struct grub_video_bitmap *bitmap); + + * Description: + + Return bitmap height. + +8.3.6 grub_video_bitmap_get_mode_info +------------------------------------- + + * Prototype: + void grub_video_bitmap_get_mode_info (struct grub_video_bitmap *bitmap, struct grub_video_mode_info *mode_info); + + * Description: + + Returns bitmap format details in form of `grub_video_mode_info'. + +8.3.7 grub_video_bitmap_get_data +-------------------------------- + + * Prototype: + void *grub_video_bitmap_get_data (struct grub_video_bitmap *bitmap); + + * Description: + + Return 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. + + +File: grub-dev.info, Node: PFF2 Font File Format, Next: Graphical Menu Software Design, Prev: Video Subsystem, Up: Top + +9 PFF2 Font File Format +*********************** + +* Menu: + +* Introduction:: +* File Structure:: +* Font Metrics:: + + +File: grub-dev.info, Node: Introduction, Next: File Structure, Up: PFF2 Font File Format + +9.1 Introduction +================ + +The goal of this format is to provide a bitmap font format that is +simple to use, compact, and cleanly supports Unicode. + +9.1.1 Goals of the GRUB Font Format +----------------------------------- + + * Simple to read and use. Since GRUB will only be reading the font + files, we are more concerned with making the code to read the font + simple than we are with writing the font. + + * Compact storage. The fonts will generally be stored in a small + boot partition where GRUB is located, and this may be on a + removable storage device such as a CD or USB flash drive where + space is more limited than it is on most hard drives. + + * Unicode. GRUB should not have to deal with multiple character + encodings. The font should always use Unicode character codes for + simple internationalization. + +9.1.2 Why Another Font Format? +------------------------------ + +There are many existing bitmap font formats that GRUB could use. +However, there are aspects of these formats that may make them less +than suitable for use in GRUB at this time: + +`BDF' + Inefficient storage; uses ASCII to describe properties and + hexadecimal numbers in ASCII for the bitmap rows. + +`PCF' + Many format variations such as byte order and bitmap padding (rows + padded to byte, word, etc.) would result in more complex code to + handle the font format. + + +File: grub-dev.info, Node: File Structure, Next: Font Metrics, Prev: Introduction, Up: PFF2 Font File Format + +9.2 File Structure +================== + +A file *section* consists of a 4-byte name, a 32-bit big-endian length +(not including the name or length), and then LENGTH more +section-type-specific bytes. + + The standard file extension for PFF2 font files is `.pf2'. + +9.2.1 Section Types +------------------- + +`FILE' + *File type ID* (ASCII string). This must be the first section in + the file. It has length 4 and the contents are the four bytes of + the ASCII string `PFF2'. + +`NAME' + *Font name* (ASCII string). This is the full font name including + family, weight, style, and point size. For instance, "Helvetica + Bold Italic 14". + +`FAMI' + *Font family name* (ASCII string). For instance, "Helvetica". + This should be included so that intelligent font substitution can + take place. + +`WEIG' + *Font weight* (ASCII string). Valid values are `bold' and + `normal'. This should be included so that intelligent font + substitution can take place. + +`SLAN' + *Font slant* (ASCII string). Valid values are `italic' and + `normal'. This should be included so that intelligent font + substitution can take place. + +`PTSZ' + *Font point size* (uint16be). + +`MAXW' + *Maximum character width in pixels* (uint16be). + +`MAXH' + *Maximum character height in pixels* (uint16be). + +`ASCE' + *Ascent in pixels* (uint16be). *Note Font Metrics::, for details. + +`DESC' + *Descent in pixels* (uint16be). *Note Font Metrics::, for details. + +`CHIX' + *Character index.* The character index begins with a 32-bit + big-endian unsigned integer indicating the total size of the + section, not including this size value. For each character, there + is an instance of the following entry structure: + + * *Unicode code point.* (32-bit big-endian integer.) + + * *Storage flags.* (byte.) + + * Bits 2..0: + + If equal to 000 binary, then the character data is stored + uncompressed beginning at the offset indicated by the + character's *offset* value. + + If equal to 001 binary, then the character data is + stored within a compressed character definition block + that begins at the offset within the file indicated by + the character's *offset* value. + + * *Offset.* (32-bit big-endian integer.) + + A marker that indicates the remainder of the file is data + accessed via the character index (CHIX) section. When + reading this font file, the rest of the file can be ignored + when scanning the sections. The length should be set to -1 + (0xFFFFFFFF). + + Supported data structures: + + Character definition Each character definition consists of: + + * *Width.* Width of the bitmap in pixels. The bitmap's + extents represent the glyph's bounding box. `uint16be'. + + * *Height.* Height of the bitmap in pixels. The bitmap's + extents represent the glyph's bounding box. `uint16be'. + + * *X offset.* The number of pixels to shift the bitmap by + horizontally before drawing the character. `int16be'. + + * *Y offset.* The number of pixels to shift the bitmap by + vertically before drawing the character. `int16be'. + + * *Device width.* The number of pixels to advance + horizontally from this character's origin to the origin + of the next character. `int16be'. + + * *Bitmap data.* This is encoded as a string of bits. It + is organized as a row-major, top-down, left-to-right + bitmap. The most significant bit of each byte is taken + to be the leftmost or uppermost bit in the byte. For + the sake of compact storage, rows are not padded to byte + boundaries (i.e., a single byte may contain bits + belonging to multiple rows). The last byte of the + bitmap *is* padded with zero bits in the bits positions + to the right of the last used bit if the bitmap data + does not fill the last byte. + + The length of the *bitmap data* field is (WIDTH * HEIGHT + + 7) / 8 using integer arithmetic, which is equivalent + to ceil(WIDTH * HEIGHT / 8) using real number arithmetic. + + It remains to be determined whether bitmap fonts usually + make all glyph bitmaps the same height, or if smaller + glyphs are stored with bitmaps having a lesser height. + In the latter case, the baseline would have to be used + to calculate the location the bitmap should be anchored + at on screen. + + + +File: grub-dev.info, Node: Font Metrics, Prev: File Structure, Up: PFF2 Font File Format + +9.3 Font Metrics +================ + + * Ascent. The distance from the baseline to the top of most + characters. Note that in some cases characters may extend above + the ascent. + + * Descent. The distance from the baseline to the bottom of most + characters. Note that in some cases characters may extend below + the descent. + + * Leading. The amount of space, in pixels, to leave between the + descent of one line of text and the ascent of the next line. This + metrics is not specified in the current file format; instead, the + font rendering engine calculates a reasonable leading value based + on the other font metrics. + + * Horizonal leading. The amount of space, in pixels, to leave + horizontally between the left and right edges of two adjacent + glyphs. The *device width* field determines the effective leading + value that is used to render the font. + +[Please fill this in. +] + + An illustration of how the various font metrics apply to characters. + + +File: grub-dev.info, Node: Graphical Menu Software Design, Next: Copying This Manual, Prev: PFF2 Font File Format, Up: Top + +10 Graphical Menu Software Design +********************************* + +* Menu: + +* Introduction_2:: +* Startup Sequence:: +* GUI Components:: +* Command Line Window:: + + +File: grub-dev.info, Node: Introduction_2, Next: Startup Sequence, Up: Graphical Menu Software Design + +10.1 Introduction +================= + +The `gfxmenu' module provides a graphical menu interface for GRUB 2. It +functions as an alternative to the menu interface provided by the +`normal' module, which uses the grub terminal interface to display a +menu on a character-oriented terminal. + + The graphical menu uses the GRUB video API, which is currently for +the VESA BIOS extensions (VBE) 2.0+. This is supported on the i386-pc +platform. However, the graphical menu itself does not depend on using +VBE, so if another GRUB video driver were implemented, the `gfxmenu' +graphical menu would work on the new video driver as well. + + +File: grub-dev.info, Node: Startup Sequence, Next: GUI Components, Prev: Introduction_2, Up: Graphical Menu Software Design + +10.2 Startup Sequence +===================== + + * grub_enter_normal_mode [normal/main.c] + + * grub_normal_execute [normal/main.c] + + * read_config_file [normal/main.c] + + * (When `gfxmenu.mod' is loaded with `insmod', it will call + `grub_menu_viewer_register()' to register itself.) + + * GRUB_MOD_INIT (gfxmenu) [gfxmenu/gfxmenu.c] + + * grub_menu_viewer_register [kern/menu_viewer.c] + + * grub_menu_viewer_show_menu [kern/menu_viewer.c] + + * get_current_menu_viewer() [kern/menu_viewer.c] + + * show_menu() [gfxmenu/gfxmenu.c] + + * grub_gfxmenu_model_new [gfxmenu/model.c] + + * grub_gfxmenu_view_new [gfxmenu/view.c] + + * set_graphics_mode [gfxmenu/view.c] + + * grub_gfxmenu_view_load_theme [gfxmenu/theme_loader.c] + + +File: grub-dev.info, Node: GUI Components, Next: Command Line Window, Prev: Startup Sequence, Up: Graphical Menu Software Design + +10.3 GUI Components +=================== + +The graphical menu implements a GUI component system that supports a +container-based layout system. Components can be added to containers, +and containers (which are a type of component) can then be added to +other containers, to form a tree of components. Currently, the root +component of this tree is a `canvas' component, which allows manual +layout of its child components. + + Components (non-container): + + * label + + * image + + * progress_bar + + * circular_progress + + * list (currently hard coded to be a boot menu list) + + Containers: + + * canvas + + * hbox + + * vbox + + The GUI component instances are created by the theme loader in +`gfxmenu/theme_loader.c' when a theme is loaded. Theme files specify +statements such as `+vbox{ +label { text="Hello" } +label{ text="World" +} }' to add components to the component tree root. By nesting the +component creation statements in the theme file, the instantiated +components are nested the same way. + + When a component is added to a container, that new child is +considered *owned* by the container. Great care should be taken if the +caller retains a reference to the child component, since it will be +destroyed if its parent container is destroyed. A better choice +instead of storing a pointer to the child component is to use the +component ID to find the desired component. Component IDs do not have +to be unique (it is often useful to have multiple components with an ID +of "__timeout__", for instance). + + In order to access and use components in the component tree, there +are two functions (defined in `gfxmenu/gui_util.c') that are +particularly useful: + + * `grub_gui_find_by_id (root, id, callback, userdata)': + + This function ecursively traverses the component tree rooted at + ROOT, and for every component that has an ID equal to ID, calls + the function pointed to by CALLBACK with the matching component + and the void pointer USERDATA as arguments. The callback function + can do whatever is desired to use the component passed in. + + * `grub_gui_iterate_recursively (root, callback, userdata)': + + This function calls the function pointed to by CALLBACK for every + component that is a descendant of ROOT in the component tree. + When the callback function is called, the component and the void + pointer USERDATA as arguments. The callback function can do + whatever is desired to use the component passed in. + + +File: grub-dev.info, Node: Command Line Window, Prev: GUI Components, Up: Graphical Menu Software Design + +10.4 Command Line Window +======================== + +The terminal window used to provide command line access within the +graphical menu is managed by `gfxmenu/view.c'. The `gfxterm' terminal +is used, and it has been modified to allow rendering to an offscreen +render target to allow it to be composed into the double buffering +system that the graphical menu view uses. This is bad for performance, +however, so it would probably be a good idea to make it possible to +temporarily disable double buffering as long as the terminal window is +visible. There are still unresolved problems that occur when commands +are executed from the terminal window that change the graphics mode. +It's possible that making `grub_video_restore()' return to the graphics +mode that was in use before `grub_video_setup()' was called might fix +some of the problems. + + +File: grub-dev.info, Node: Copying This Manual, Next: Index, Prev: Graphical Menu Software Design, Up: Top + +Appendix A Copying This Manual +****************************** + +* Menu: + +* GNU Free Documentation License:: License for copying this manual. + + +File: grub-dev.info, Node: GNU Free Documentation License, Up: Copying This Manual + +A.1 GNU Free Documentation License +================================== + + Version 1.2, November 2002 + + Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + 0. PREAMBLE + + The purpose of this License is to make a manual, textbook, or other + functional and useful document "free" in the sense of freedom: to + assure everyone the effective freedom to copy and redistribute it, + with or without modifying it, either commercially or + noncommercially. Secondarily, this License preserves for the + author and publisher a way to get credit for their work, while not + being considered responsible for modifications made by others. + + This License is a kind of "copyleft", which means that derivative + works of the document must themselves be free in the same sense. + It complements the GNU General Public License, which is a copyleft + license designed for free software. + + We have designed this License in order to use it for manuals for + free software, because free software needs free documentation: a + free program should come with manuals providing the same freedoms + that the software does. But this License is not limited to + software manuals; it can be used for any textual work, regardless + of subject matter or whether it is published as a printed book. + We recommend this License principally for works whose purpose is + instruction or reference. + + 1. APPLICABILITY AND DEFINITIONS + + This License applies to any manual or other work, in any medium, + that contains a notice placed by the copyright holder saying it + can be distributed under the terms of this License. Such a notice + grants a world-wide, royalty-free license, unlimited in duration, + to use that work under the conditions stated herein. The + "Document", below, refers to any such manual or work. Any member + of the public is a licensee, and is addressed as "you". You + accept the license if you copy, modify or distribute the work in a + way requiring permission under copyright law. + + A "Modified Version" of the Document means any work containing the + Document or a portion of it, either copied verbatim, or with + modifications and/or translated into another language. + + A "Secondary Section" is a named appendix or a front-matter section + of the Document that deals exclusively with the relationship of the + publishers or authors of the Document to the Document's overall + subject (or to related matters) and contains nothing that could + fall directly within that overall subject. (Thus, if the Document + is in part a textbook of mathematics, a Secondary Section may not + explain any mathematics.) The relationship could be a matter of + historical connection with the subject or with related matters, or + of legal, commercial, philosophical, ethical or political position + regarding them. + + The "Invariant Sections" are certain Secondary Sections whose + titles are designated, as being those of Invariant Sections, in + the notice that says that the Document is released under this + License. If a section does not fit the above definition of + Secondary then it is not allowed to be designated as Invariant. + The Document may contain zero Invariant Sections. If the Document + does not identify any Invariant Sections then there are none. + + The "Cover Texts" are certain short passages of text that are + listed, as Front-Cover Texts or Back-Cover Texts, in the notice + that says that the Document is released under this License. A + Front-Cover Text may be at most 5 words, and a Back-Cover Text may + be at most 25 words. + + A "Transparent" copy of the Document means a machine-readable copy, + represented in a format whose specification is available to the + general public, that is suitable for revising the document + straightforwardly with generic text editors or (for images + composed of pixels) generic paint programs or (for drawings) some + widely available drawing editor, and that is suitable for input to + text formatters or for automatic translation to a variety of + formats suitable for input to text formatters. A copy made in an + otherwise Transparent file format whose markup, or absence of + markup, has been arranged to thwart or discourage subsequent + modification by readers is not Transparent. An image format is + not Transparent if used for any substantial amount of text. A + copy that is not "Transparent" is called "Opaque". + + Examples of suitable formats for Transparent copies include plain + ASCII without markup, Texinfo input format, LaTeX input format, + SGML or XML using a publicly available DTD, and + standard-conforming simple HTML, PostScript or PDF designed for + human modification. Examples of transparent image formats include + PNG, XCF and JPG. Opaque formats include proprietary formats that + can be read and edited only by proprietary word processors, SGML or + XML for which the DTD and/or processing tools are not generally + available, and the machine-generated HTML, PostScript or PDF + produced by some word processors for output purposes only. + + The "Title Page" means, for a printed book, the title page itself, + plus such following pages as are needed to hold, legibly, the + material this License requires to appear in the title page. For + works in formats which do not have any title page as such, "Title + Page" means the text near the most prominent appearance of the + work's title, preceding the beginning of the body of the text. + + A section "Entitled XYZ" means a named subunit of the Document + whose title either is precisely XYZ or contains XYZ in parentheses + following text that translates XYZ in another language. (Here XYZ + stands for a specific section name mentioned below, such as + "Acknowledgements", "Dedications", "Endorsements", or "History".) + To "Preserve the Title" of such a section when you modify the + Document means that it remains a section "Entitled XYZ" according + to this definition. + + The Document may include Warranty Disclaimers next to the notice + which states that this License applies to the Document. These + Warranty Disclaimers are considered to be included by reference in + this License, but only as regards disclaiming warranties: any other + implication that these Warranty Disclaimers may have is void and + has no effect on the meaning of this License. + + 2. VERBATIM COPYING + + You may copy and distribute the Document in any medium, either + commercially or noncommercially, provided that this License, the + copyright notices, and the license notice saying this License + applies to the Document are reproduced in all copies, and that you + add no other conditions whatsoever to those of this License. You + may not use technical measures to obstruct or control the reading + or further copying of the copies you make or distribute. However, + you may accept compensation in exchange for copies. If you + distribute a large enough number of copies you must also follow + the conditions in section 3. + + You may also lend copies, under the same conditions stated above, + and you may publicly display copies. + + 3. COPYING IN QUANTITY + + If you publish printed copies (or copies in media that commonly + have printed covers) of the Document, numbering more than 100, and + the Document's license notice requires Cover Texts, you must + enclose the copies in covers that carry, clearly and legibly, all + these Cover Texts: Front-Cover Texts on the front cover, and + Back-Cover Texts on the back cover. Both covers must also clearly + and legibly identify you as the publisher of these copies. The + front cover must present the full title with all words of the + title equally prominent and visible. You may add other material + on the covers in addition. Copying with changes limited to the + covers, as long as they preserve the title of the Document and + satisfy these conditions, can be treated as verbatim copying in + other respects. + + If the required texts for either cover are too voluminous to fit + legibly, you should put the first ones listed (as many as fit + reasonably) on the actual cover, and continue the rest onto + adjacent pages. + + If you publish or distribute Opaque copies of the Document + numbering more than 100, you must either include a + machine-readable Transparent copy along with each Opaque copy, or + state in or with each Opaque copy a computer-network location from + which the general network-using public has access to download + using public-standard network protocols a complete Transparent + copy of the Document, free of added material. If you use the + latter option, you must take reasonably prudent steps, when you + begin distribution of Opaque copies in quantity, to ensure that + this Transparent copy will remain thus accessible at the stated + location until at least one year after the last time you + distribute an Opaque copy (directly or through your agents or + retailers) of that edition to the public. + + It is requested, but not required, that you contact the authors of + the Document well before redistributing any large number of + copies, to give them a chance to provide you with an updated + version of the Document. + + 4. MODIFICATIONS + + You may copy and distribute a Modified Version of the Document + under the conditions of sections 2 and 3 above, provided that you + release the Modified Version under precisely this License, with + the Modified Version filling the role of the Document, thus + licensing distribution and modification of the Modified Version to + whoever possesses a copy of it. In addition, you must do these + things in the Modified Version: + + A. Use in the Title Page (and on the covers, if any) a title + distinct from that of the Document, and from those of + previous versions (which should, if there were any, be listed + in the History section of the Document). You may use the + same title as a previous version if the original publisher of + that version gives permission. + + B. List on the Title Page, as authors, one or more persons or + entities responsible for authorship of the modifications in + the Modified Version, together with at least five of the + principal authors of the Document (all of its principal + authors, if it has fewer than five), unless they release you + from this requirement. + + C. State on the Title page the name of the publisher of the + Modified Version, as the publisher. + + D. Preserve all the copyright notices of the Document. + + E. Add an appropriate copyright notice for your modifications + adjacent to the other copyright notices. + + F. Include, immediately after the copyright notices, a license + notice giving the public permission to use the Modified + Version under the terms of this License, in the form shown in + the Addendum below. + + G. Preserve in that license notice the full lists of Invariant + Sections and required Cover Texts given in the Document's + license notice. + + H. Include an unaltered copy of this License. + + I. Preserve the section Entitled "History", Preserve its Title, + and add to it an item stating at least the title, year, new + authors, and publisher of the Modified Version as given on + the Title Page. If there is no section Entitled "History" in + the Document, create one stating the title, year, authors, + and publisher of the Document as given on its Title Page, + then add an item describing the Modified Version as stated in + the previous sentence. + + J. Preserve the network location, if any, given in the Document + for public access to a Transparent copy of the Document, and + likewise the network locations given in the Document for + previous versions it was based on. These may be placed in + the "History" section. You may omit a network location for a + work that was published at least four years before the + Document itself, or if the original publisher of the version + it refers to gives permission. + + K. For any section Entitled "Acknowledgements" or "Dedications", + Preserve the Title of the section, and preserve in the + section all the substance and tone of each of the contributor + acknowledgements and/or dedications given therein. + + L. Preserve all the Invariant Sections of the Document, + unaltered in their text and in their titles. Section numbers + or the equivalent are not considered part of the section + titles. + + M. Delete any section Entitled "Endorsements". Such a section + may not be included in the Modified Version. + + N. Do not retitle any existing section to be Entitled + "Endorsements" or to conflict in title with any Invariant + Section. + + O. Preserve any Warranty Disclaimers. + + If the Modified Version includes new front-matter sections or + appendices that qualify as Secondary Sections and contain no + material copied from the Document, you may at your option + designate some or all of these sections as invariant. To do this, + add their titles to the list of Invariant Sections in the Modified + Version's license notice. These titles must be distinct from any + other section titles. + + You may add a section Entitled "Endorsements", provided it contains + nothing but endorsements of your Modified Version by various + parties--for example, statements of peer review or that the text + has been approved by an organization as the authoritative + definition of a standard. + + You may add a passage of up to five words as a Front-Cover Text, + and a passage of up to 25 words as a Back-Cover Text, to the end + of the list of Cover Texts in the Modified Version. Only one + passage of Front-Cover Text and one of Back-Cover Text may be + added by (or through arrangements made by) any one entity. If the + Document already includes a cover text for the same cover, + previously added by you or by arrangement made by the same entity + you are acting on behalf of, you may not add another; but you may + replace the old one, on explicit permission from the previous + publisher that added the old one. + + The author(s) and publisher(s) of the Document do not by this + License give permission to use their names for publicity for or to + assert or imply endorsement of any Modified Version. + + 5. COMBINING DOCUMENTS + + You may combine the Document with other documents released under + this License, under the terms defined in section 4 above for + modified versions, provided that you include in the combination + all of the Invariant Sections of all of the original documents, + unmodified, and list them all as Invariant Sections of your + combined work in its license notice, and that you preserve all + their Warranty Disclaimers. + + The combined work need only contain one copy of this License, and + multiple identical Invariant Sections may be replaced with a single + copy. If there are multiple Invariant Sections with the same name + but different contents, make the title of each such section unique + by adding at the end of it, in parentheses, the name of the + original author or publisher of that section if known, or else a + unique number. Make the same adjustment to the section titles in + the list of Invariant Sections in the license notice of the + combined work. + + In the combination, you must combine any sections Entitled + "History" in the various original documents, forming one section + Entitled "History"; likewise combine any sections Entitled + "Acknowledgements", and any sections Entitled "Dedications". You + must delete all sections Entitled "Endorsements." + + 6. COLLECTIONS OF DOCUMENTS + + You may make a collection consisting of the Document and other + documents released under this License, and replace the individual + copies of this License in the various documents with a single copy + that is included in the collection, provided that you follow the + rules of this License for verbatim copying of each of the + documents in all other respects. + + You may extract a single document from such a collection, and + distribute it individually under this License, provided you insert + a copy of this License into the extracted document, and follow + this License in all other respects regarding verbatim copying of + that document. + + 7. AGGREGATION WITH INDEPENDENT WORKS + + A compilation of the Document or its derivatives with other + separate and independent documents or works, in or on a volume of + a storage or distribution medium, is called an "aggregate" if the + copyright resulting from the compilation is not used to limit the + legal rights of the compilation's users beyond what the individual + works permit. When the Document is included in an aggregate, this + License does not apply to the other works in the aggregate which + are not themselves derivative works of the Document. + + If the Cover Text requirement of section 3 is applicable to these + copies of the Document, then if the Document is less than one half + of the entire aggregate, the Document's Cover Texts may be placed + on covers that bracket the Document within the aggregate, or the + electronic equivalent of covers if the Document is in electronic + form. Otherwise they must appear on printed covers that bracket + the whole aggregate. + + 8. TRANSLATION + + Translation is considered a kind of modification, so you may + distribute translations of the Document under the terms of section + 4. Replacing Invariant Sections with translations requires special + permission from their copyright holders, but you may include + translations of some or all Invariant Sections in addition to the + original versions of these Invariant Sections. You may include a + translation of this License, and all the license notices in the + Document, and any Warranty Disclaimers, provided that you also + include the original English version of this License and the + original versions of those notices and disclaimers. In case of a + disagreement between the translation and the original version of + this License or a notice or disclaimer, the original version will + prevail. + + If a section in the Document is Entitled "Acknowledgements", + "Dedications", or "History", the requirement (section 4) to + Preserve its Title (section 1) will typically require changing the + actual title. + + 9. TERMINATION + + You may not copy, modify, sublicense, or distribute the Document + except as expressly provided for under this License. Any other + attempt to copy, modify, sublicense or distribute the Document is + void, and will automatically terminate your rights under this + License. However, parties who have received copies, or rights, + from you under this License will not have their licenses + terminated so long as such parties remain in full compliance. + + 10. FUTURE REVISIONS OF THIS LICENSE + + The Free Software Foundation may publish new, revised versions of + the GNU Free Documentation License from time to time. Such new + versions will be similar in spirit to the present version, but may + differ in detail to address new problems or concerns. See + `http://www.gnu.org/copyleft/'. + + Each version of the License is given a distinguishing version + number. If the Document specifies that a particular numbered + version of this License "or any later version" applies to it, you + have the option of following the terms and conditions either of + that specified version or of any later version that has been + published (not as a draft) by the Free Software Foundation. If + the Document does not specify a version number of this License, + you may choose any version ever published (not as a draft) by the + Free Software Foundation. + +A.1.1 ADDENDUM: How to use this License for your documents +---------------------------------------------------------- + +To use this License in a document you have written, include a copy of +the License in the document and put the following copyright and license +notices just after the title page: + + Copyright (C) YEAR YOUR NAME. + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.2 + or any later version published by the Free Software Foundation; + with no Invariant Sections, no Front-Cover Texts, and no Back-Cover + Texts. A copy of the license is included in the section entitled ``GNU + Free Documentation License''. + + If you have Invariant Sections, Front-Cover Texts and Back-Cover +Texts, replace the "with...Texts." line with this: + + with the Invariant Sections being LIST THEIR TITLES, with + the Front-Cover Texts being LIST, and with the Back-Cover Texts + being LIST. + + If you have Invariant Sections without Cover Texts, or some other +combination of the three, merge those two alternatives to suit the +situation. + + If your document contains nontrivial examples of program code, we +recommend releasing these examples in parallel under your choice of +free software license, such as the GNU General Public License, to +permit their use in free software. + + +File: grub-dev.info, Node: Index, Prev: Copying This Manual, Up: Top + +Index +***** + + +* Menu: + +* FDL, GNU Free Documentation License: GNU Free Documentation License. + (line 6) + + + +Tag Table: +Node: Top718 +Node: Getting the source code1780 +Node: Coding style2660 +Node: Naming Conventions3065 +Node: Functions3348 +Node: Variables4215 +Node: Types5321 +Node: Macros5919 +Node: Comments6250 +Node: Multi-Line Comments7012 +Node: Finding your way around7643 +Node: Contributing Changes10840 +Node: Getting started11924 +Node: Typical Developer Experience15970 +Node: When you are approved for write access to project's files17013 +Node: Error Handling18443 +Node: CIA23516 +Node: BIOS port memory map24588 +Node: Video Subsystem25458 +Node: Video API25930 +Node: Example usage of Video API44184 +Node: Bitmap API45740 +Node: PFF2 Font File Format48271 +Node: Introduction48509 +Node: File Structure50006 +Node: Font Metrics54909 +Node: Graphical Menu Software Design56011 +Node: Introduction_256303 +Node: Startup Sequence57037 +Node: GUI Components57900 +Node: Command Line Window60505 +Node: Copying This Manual61457 +Node: GNU Free Documentation License61713 +Node: Index84125 + +End Tag Table |