diff options
Diffstat (limited to 'docs/grub-dev.info')
| -rw-r--r-- | docs/grub-dev.info | 2171 |
1 files changed, 0 insertions, 2171 deletions
diff --git a/docs/grub-dev.info b/docs/grub-dev.info deleted file mode 100644 index 0510b36..0000000 --- a/docs/grub-dev.info +++ /dev/null @@ -1,2171 +0,0 @@ -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 |