4 @setfilename grub-dev.info
5 @include version-dev.texi
6 @settitle GNU GRUB Developers Manual @value{VERSION}
7 @c Unify all our little indices for now.
15 @footnotestyle separate
20 This developer manual is for GNU GRUB (version @value{VERSION},
23 Copyright @copyright{} 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 Free Software Foundation, Inc.
26 Permission is granted to copy, distribute and/or modify this document
27 under the terms of the GNU Free Documentation License, Version 1.2 or
28 any later version published by the Free Software Foundation; with no
35 * grub-dev: (grub-dev). The GRand Unified Bootloader Dev
38 @setchapternewpage odd
42 @title the GNU GRUB developer manual
43 @subtitle The GRand Unified Bootloader, version @value{VERSION}, @value{UPDATED}.
44 @author Yoshinori K. Okuji
45 @author Colin D Bennett
46 @author Vesa Jääskeläinen
50 @c The following two commands start the copyright page.
52 @vskip 0pt plus 1filll
56 @c Output the table of contents at the beginning.
64 @top GNU GRUB developer manual
66 This is the developer documentation of GNU GRUB, the GRand Unified Bootloader,
67 a flexible and powerful boot loader program for a wide range of
70 This edition documents version @value{VERSION}.
76 * Getting the source code::
77 * Finding your way around::
79 * Contributing Changes::
83 * BIOS port memory map::
85 * PFF2 Font File Format::
86 * Graphical Menu Software Design::
87 * Copying This Manual:: Copying This Manual
92 @node Getting the source code
93 @chapter Getting the source code
95 GRUB is maintained using the @uref{http://bazaar-vcs.org/, Bazaar revision
96 control system}. To fetch the primary development branch:
99 bzr get http://bzr.savannah.gnu.org/r/grub/trunk/grub
102 The GRUB developers maintain several other branches with work in progress.
103 Of these, the most interesting is the experimental branch, which is a
104 staging area for new code which we expect to eventually merge into trunk but
105 which is not yet ready:
108 bzr get http://bzr.savannah.gnu.org/r/grub/branches/experimental
111 Once you have used @kbd{bzr get} to fetch an initial copy of a branch, you
112 can use @kbd{bzr pull} to keep it up to date. If you have modified your
113 local version, you may need to resolve conflicts when pulling.
116 @chapter Coding style
117 @c By YoshinoriOkuji, VesaJääskeläinen and ColinBennett
119 Basically we follow the @uref{http://www.gnu.org/prep/standards_toc.html, GNU Coding Standards}. We define additional conventions for GRUB here.
122 * Naming Conventions::
128 * Multi-Line Comments::
131 @node Naming Conventions
132 @section Naming Conventions
134 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.
139 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.
141 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).
143 If a function is local, its name may not start with any prefix. It must start with a verb.
148 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_.
150 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).
152 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.
154 If a variable is local, you may choose any shorter name, as long as it wouldn't make code less readable (e.g. i).
159 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_.
161 The name must be suffixed with _t, to emphasize the fact that it is a type but not a variable or a function.
166 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.
171 All comments shall be C-style comments, of the form @samp{/* @dots{} */}.
173 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.
177 /* The page # that is the front buffer. */
179 /* The page # that is the back buffer. */
185 int displayed_page; /* The page # that is the front buffer. */
186 int render_page; /* The page # that is the back buffer. */
189 @node Multi-Line Comments
190 @section Multi-Line Comments
192 Comments spanning multiple lines shall be formatted with all lines after the first aligned with the first line.
194 Asterisk characters should not be repeated a the start of each subsequent line.
199 which spans multiple lines.
207 * which spans multiple lines.
211 The opening @samp{/*} and closing @samp{*/} should be placed together on a line with text.
213 @node Finding your way around
214 @chapter Finding your way around
216 Here is a brief map of the GRUB code base.
218 GRUB uses Autoconf and Automake, with most of the Automake input generated
219 by AutoGen. The top-level build rules are in @file{configure.ac},
220 @file{grub-core/Makefile.core.def}, and @file{Makefile.util.def}. Each
221 block in a @file{*.def} file represents a build target, and specifies the
222 source files used to build it on various platforms. The @file{*.def} files
223 are processed into AutoGen input by @file{gentpl.py} (which you only need to
224 look at if you are extending the build system). If you are adding a new
225 module which follows an existing pattern, such as a new command or a new
226 filesystem implementation, it is usually easiest to grep
227 @file{grub-core/Makefile.core.def} and @file{Makefile.util.def} for an
228 existing example of that pattern to find out where it should be added.
230 In general, code that may be run at boot time is in a subdirectory of
231 @file{grub-core}, while code that is only run from within a full operating
232 system is in a subdirectory of the top level.
234 Low-level boot code, such as the MBR implementation on PC BIOS systems, is
235 in the @file{grub-core/boot/} directory.
237 The GRUB kernel is in @file{grub-core/kern/}. This contains core facilities
238 such as the device, disk, and file frameworks, environment variable
239 handling, list processing, and so on. The kernel should contain enough to
240 get up to a rescue prompt. Header files for kernel facilities, among
241 others, are in @file{include/}.
243 Terminal implementations are in @file{grub-core/term/}.
245 Disk access code is spread across @file{grub-core/disk/} (for accessing the
246 disk devices themselves), @file{grub-core/partmap/} (for interpreting
247 partition table data), and @file{grub-core/fs/} (for accessing filesystems).
248 Note that, with the odd specialised exception, GRUB only contains code to
249 @emph{read} from filesystems and tries to avoid containing any code to
250 @emph{write} to filesystems; this lets us confidently assure users that GRUB
251 cannot be responsible for filesystem corruption.
253 PCI and USB bus handling is in @file{grub-core/bus/}.
255 Video handling code is in @file{grub-core/video/}. The graphical menu
256 system uses this heavily, but is in a separate directory,
257 @file{grub-core/gfxmenu/}.
259 Most commands are implemented by files in @file{grub-core/commands/}, with
260 the following exceptions:
264 A few core commands live in @file{grub-core/kern/corecmd.c}.
267 Commands related to normal mode live under @file{grub-core/normal/}.
270 Commands that load and boot kernels live under @file{grub-core/loader/}.
273 The @samp{loopback} command is really a disk device, and so lives in
274 @file{grub-core/disk/loopback.c}.
277 The @samp{gettext} command lives under @file{grub-core/gettext/}.
280 The @samp{loadfont} and @samp{lsfonts} commands live under
281 @file{grub-core/font/}.
284 The @samp{serial}, @samp{terminfo}, and @samp{background_image} commands
285 live under @file{grub-core/term/}.
288 The @samp{efiemu_*} commands live under @file{grub-core/efiemu/}.
291 There are a few other special-purpose exceptions; grep for them if they
294 Utility programs meant to be run from a full operating system are in
297 @node Contributing Changes
298 @chapter Contributing changes
299 @c By YoshinoriOkuji, VesaJääskeläinen, ColinWatson
301 Contributing changes to GRUB 2 is welcomed activity. However we have a
302 bit of control what kind of changes will be accepted to GRUB 2.
303 Therefore it is important to discuss your changes on grub-devel mailing list
304 (see MailingLists). On this page there are some basic details on the
305 development process and activities.
307 First of all you should come up with the idea yourself what you want to
308 contribute. If you do not have that beforehand you are advised to study this
309 manual and try GRUB 2 out to see what you think is missing from there.
311 Here are additional pointers:
313 @item @url{https://savannah.gnu.org/task/?group=grub GRUB's Task Tracker}
314 @item @url{https://savannah.gnu.org/bugs/?group=grub GRUB's Bug Tracker}
317 If you intended to make changes to GRUB Legacy (<=0.97) those are not accepted
322 * Typical Developer Experience::
323 * When you are approved for write access to project's files::
326 @node Getting started
327 @section Getting started
330 @item Always use latest GRUB 2 source code. So get that first.
332 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.
334 Please check Savannah's GRUB project page for details how to get newest bzr:
335 @uref{http://savannah.gnu.org/bzr/?group=grub, GRUB 2 bzr Repository}
337 @item Compile it and try it out.
339 It is always good idea to first see that things work somehow and after that
340 to start to implement new features or develop fixes to bugs.
342 @item Study the code.
344 There are sometimes odd ways to do things in GRUB 2 code base.
345 This is mainly related to limited environment where GRUB 2 is being executed.
346 You usually do not need to understand it all so it is better to only try to
347 look at places that relates to your work. Please do not hesitate to ask for
348 help if there is something that you do not understand.
350 @item Develop a new feature.
352 Now that you know what to do and how it should work in GRUB 2 code base, please
353 be free to develop it. If you have not so far announced your idea on grub-devel
354 mailing list, please do it now. This is to make sure you are not wasting your
355 time working on the solution that will not be integrated to GRUB 2 code base.
357 You might want to study our coding style before starting development so you
358 do not need to change much of the code when your patch is being reviewed.
359 (see @ref{Coding style})
361 For every accepted patch there has to exist a ChangeLog entry. Our ChangeLog
362 consist of changes within source code and are not describing about what the
363 change logically does. Please see examples from previous entries.
365 Also remember that GRUB 2 is licensed under GPLv3 license and that usually
366 means that you are not allowed to copy pieces of code from other projects.
367 Even if the source project's license would be compatible with GPLv3, please
368 discuss it beforehand on grub-devel mailing list.
370 @item Test your change.
372 Test that your change works properly. Try it out a couple of times, preferably on different systems, and try to find problems with it.
374 @item Publish your change.
376 When you are happy with your change, first make sure it is compilable with
377 latest development version of GRUB 2. After that please send a patch to
378 grub-devel for review. Please describe in your email why you made the change,
379 what it changes and so on. Please be prepared to receive even discouraging
380 comments about your patch. There is usually at least something that needs
381 to be improved in every patch.
383 Please use unified diff to make your patch (good match of arguments for diff is @samp{-pruN}).
385 @item Respond to received feedback.
387 If you are asked to modify your patch, please do that and resubmit it for
388 review. If your change is large you are required to submit a copyright
389 agreement to FSF. Please keep in mind that if you are asked to submit
390 for copyright agreement, process can take some time and is mandatory
391 in order to get your changes integrated.
393 If you are not on grub-devel to respond to questions, most likely your patch
394 will not be accepted. Also if problems arise from your changes later on,
395 it would be preferable that you also fix the problem. So stay around
398 @item Your patch is accepted.
400 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.
402 Now you are welcome to do further improvements :)
405 @node Typical Developer Experience
406 @section Typical Developer Experience
408 The typical experience for a developer in this project is the following:
411 @item You find yourself wanting to do something (e.g. fixing a bug).
412 @item You show some result in the mailing list or the IRC.
413 @item You are getting to be known to other developers.
414 @item You accumulate significant amount of contribution, so copyright assignment is processed.
415 @item You are free to check in your changes on your own, legally speaking.
418 At this point, it is rather annoying that you ought to ask somebody else every
419 change to be checked in. For efficiency, it is far better, if you can commit
420 it yourself. Therefore, our policy is to give you the write permission to our
421 official repository, once you have shown your skill and will,
422 and the FSF clerks have dealt with your copyright assignment.
424 @node When you are approved for write access to project's files
425 @section When you are approved for write access to project's files
427 As you might know, GRUB is hosted on
428 @url{https://savannah.gnu.org/projects/grub Savannah}, thus the membership
429 is managed by Savannah. This means that, if you want to be a member of this
433 @item You need to create your own account on Savannah.
434 @item You can submit ``Request for Inclusion'' from ``My Groups'' on Savannah.
437 Then, one of the admins can approve your request, and you will be a member.
438 If you don't want to use the Savannah interface to submit a request, you can
439 simply notify the admins by email or something else, alternatively. But you
440 still need to create an account beforehand.
442 NOTE: we sometimes receive a ``Request for Inclusion'' from an unknown person.
443 In this case, the request would be just discarded, since it is too dangerous
444 to allow a stranger to be a member, which automatically gives him a commit
445 right to the repository, both for a legal reason and for a technical reason.
447 If your intention is to just get started, please do not submit a inclusion
448 request. Instead, please subscribe to the mailing list, and communicate first
449 (e.g. sending a patch, asking a question, commenting on another message...).
454 GRUB2 is designed to be easily portable accross platforms. But because of the
455 nature of bootloader every new port must be done separately. Here is how I did
456 MIPS (loongson and ARC) and Xen ports. Note than this is more of suggestions,
459 First of all grab any architecture specifications you can find in public
462 First stage is ``Hello world''. I've done it outside of GRUB for simplicity.
463 Your task is to have a small program which is loadable as bootloader and
464 clearly shows its presence to you. If you have easily accessible console
465 you can just print a message. If you have a mapped framebuffer you know address
466 of, you can draw a square. If you have a debug facility, just hanging without
467 crashing might be enough. For the first stage you can choose to load the
468 bootloader across the network since format for network image is often easier
469 than for local boot and it skips the need of small intermediary stages and
470 nvram handling. Additionally you can often have a good idea of the needed
471 format by running ``file'' on any netbootable executable for given platform.
473 This program should probably have 2 parts: an assembler and C one. Assembler one
474 handles BSS cleaning and other needed setup (on some platforms you may need
475 to switch modes or copy the executable to its definitive position). So your code
476 may look like (x86 assembly for illustration purposes)
481 movl $_bss_start, %edi
493 static const char msg[] = "Hello, world";
504 const char *ptr = msg;
511 Sometimes you need a third file: assembly stubs for ABI-compatibility.
513 Once this file is functional it's time to move it into GRUB2. The startup
514 assembly file goes to grub-core/kern/$cpu/$platform/startup.S. You should also
515 include grub/symbol.h and replace call to entry point with call to
516 EXT_C(grub_main). The C file goes to grub-core/kern/$cpu/$platform/init.c
517 and its entry point is renamed to void grub_machine_init (void). Keep final
518 infinite loop for now. Stubs file if any goes to
519 grub-core/kern/$cpu/$platform/callwrap.S. Sometimes either $cpu or $platform
520 is dropped if file is used on several cpus respectivelyplatforms.
521 Check those locations if they already have what you're looking for.
523 Then modify in configure.ac the following parts:
528 case "$target_cpu" in
529 i[[3456]]86) target_cpu=i386 ;;
530 amd64) target_cpu=x86_64 ;;
531 sparc) target_cpu=sparc64 ;;
532 s390x) target_cpu=s390 ;;
537 Sometimes CPU have additional architecture names which don't influence booting.
538 You might want to have some canonical name to avoid having bunch of identical
539 platforms with different names.
541 NOTE: it doesn't influence compile optimisations which depend solely on
542 chosen compiler and compile options.
545 if test "x$with_platform" = x; then
546 case "$target_cpu"-"$target_vendor" in
547 i386-apple) platform=efi ;;
548 i386-*) platform=pc ;;
549 x86_64-apple) platform=efi ;;
550 x86_64-*) platform=pc ;;
551 powerpc-*) platform=ieee1275 ;;
559 This part deals with guessing the platform from CPU and vendor. Sometimes you
560 need to use 32-bit mode for booting even if OS runs in 64-bit one. If so add
564 case "$target_cpu"-"$platform" in
567 x86_64-*) target_cpu=i386 ;;
568 powerpc64-ieee1275) target_cpu=powerpc ;;
572 Add your platform to the list of supported ones:
575 case "$target_cpu"-"$platform" in
585 If explicit -m32 or -m64 is needed add it to:
588 case "$target_cpu" in
589 i386 | powerpc) target_m32=1 ;;
590 x86_64 | sparc64) target_m64=1 ;;
594 Finally you need to add a conditional to the following block:
597 AM_CONDITIONAL([COND_mips_arc], [test x$target_cpu = xmips -a x$platform = xarc])
598 AM_CONDITIONAL([COND_sparc64_ieee1275], [test x$target_cpu = xsparc64 -a x$platform = xieee1275])
599 AM_CONDITIONAL([COND_powerpc_ieee1275], [test x$target_cpu = xpowerpc -a x$platform = xieee1275])
602 Next stop is gentpl.py. You need to add your platform to the list of supported
603 ones (sorry that this list is duplicated):
606 GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
607 "i386_multiboot", "i386_ieee1275", "x86_64_efi",
608 "mips_loongson", "sparc64_ieee1275",
609 "powerpc_ieee1275", "mips_arc", "ia64_efi",
610 "mips_qemu_mips", "s390_mainframe" ]
613 You may also want already to add new platform to one or several of available
614 groups. In particular we always have a group for each CPU even when only
615 one platform for given CPU is available.
617 Then comes grub-core/Makefile.core.def. In the block ``kernel'' you'll need
618 to define ldflags for your platform ($cpu_$platform_ldflags). You also need to
619 declare startup asm file ($cpu_$platform_startup) as well as any other files
620 (e.g. init.c and callwrap.S) (e.g. $cpu_$platform = kern/$cpu/$platform/init.c).
621 At this stage you will also need to add dummy dl.c and cache.S with functions
622 grub_err_t grub_arch_dl_check_header (void *ehdr), grub_err_t
623 grub_arch_dl_relocate_symbols (grub_dl_t mod, void *ehdr) (dl.c) and
624 void grub_arch_sync_caches (void *address, grub_size_t len) (cache.S). They
625 won't be used for now.
627 You will need to create directory include/$cpu/$platform and a file
628 include/$cpu/types.h. The later folowing this template:
631 #ifndef GRUB_TYPES_CPU_HEADER
632 #define GRUB_TYPES_CPU_HEADER 1
634 /* The size of void *. */
635 #define GRUB_TARGET_SIZEOF_VOID_P 4
637 /* The size of long. */
638 #define GRUB_TARGET_SIZEOF_LONG 4
640 /* mycpu is big-endian. */
641 #define GRUB_TARGET_WORDS_BIGENDIAN 1
642 /* Alternatively: mycpu is little-endian. */
643 #undef GRUB_TARGET_WORDS_BIGENDIAN
645 #endif /* ! GRUB_TYPES_CPU_HEADER */
648 You will also need to add a dummy file to datetime and setjmp modules to
649 avoid any of it having no files. It can be just completely empty at this stage.
651 You'll need to make grub-mkimage.c (util/grub_mkimage.c) aware of the needed
652 format. For most commonly used formats like ELF, PE, aout or raw the support
653 is already present and you'll need to make it follow the existant code paths
654 for your platform adding adjustments if necessary. When done compile:
658 ./configure --target=$cpu --with-platform=$platform TARGET_CC=.. OBJCOPY=... STRIP=...
665 ./grub-mkimage -d grub-core -O $format_id -o test.img
668 And it's time to test your test.img.
670 If it works next stage is to have heap, console and timer.
672 To have the heap working you need to determine which regions are suitable for
673 heap usage, allocate them from firmware and map (if applicable). Then call
674 grub_mm_init_region (vois *start, grub_size_t s) for every of this region.
675 As a shortcut for early port you can allocate right after _end or have
676 a big static array for heap. If you do you'll probably need to come back to
677 this later. As for output console you should distinguish between an array of
678 text, terminfo or graphics-based console. Many of real-world examples don't
679 fit perfectly into any of these categories but one of the models is easier
680 to be used as base. In second and third case you should add your platform to
681 terminfokernel respectively videoinkernel group. A good example of array of
682 text is i386-pc (kern/i386/pc/init.c and term/i386/pc/console.c).
683 Of terminfo is ieee1275 (kern/ieee1275/init.c and term/ieee1275/console.c).
684 Of video is loongson (kern/mips/loongson/init.c). Note that terminfo has
685 to be inited in 2 stages: one before (to get at least rudimentary console
686 as early as possible) and another after the heap (to get full-featured console).
687 For the input there are string of keys, terminfo and direct hardware. For string
688 of keys look at i386-pc (same files), for termino ieee1275 (same files) and for
689 hardware loongson (kern/mips/loongson/init.c and term/at_keyboard.c).
691 For the timer you'll need to call grub_install_get_time_ms (...) with as sole
692 argument a function returning a grub_uint64_t of a number of milliseconds
693 elapsed since arbitrary point in the past.
695 Once these steps accomplished you can remove the inifinite loop and you should
696 be able to get to the minimal console. Next step is to have module loading
697 working. For this you'll need to fill kern/$cpu/dl.c and kern/$cpu/cache.S
698 with real handling of relocations and respectively the real sync of I and D
699 caches. Also you'll need to decide where in the image to store the modules.
700 Usual way is to have it concatenated at the end. In this case you'll need to
701 modify startup.S to copy modules out of bss to let's say ALIGN_UP (_end, 8)
702 before cleaning out bss. You'll probably find useful to add total_module_size
703 field to startup.S. In init.c you need to set grub_modbase to the address
704 where modules can be found. You may need grub_modules_get_end () to avoid
705 declaring the space occupied by modules as usable for heap. You can test modules
709 ./grub-mkimage -d grub-core -O $format_id -o test.img hello
712 and then running ``hello'' in the shell.
714 Once this works, you should think of implementing disk access. Look around
717 Then, very importantly, you probably need to implement the actual loader
718 (examples available in loader/)
720 Last step to have minimally usable port is to add support to grub-install to
721 put GRUB in a place where firmware or platform will pick it up.
723 Next steps are: filling datetime.c, setjmp.S, network (net/drivers),
724 video (video/), halt (lib/), reboot (lib/).
726 Please add your platform to Platform limitations and Supported kernels chapter
727 in user documentation and mention any steps you skipped which result in reduced
728 features or performance. Here is the quick checklist of features. Some of them
729 are less important than others and skipping them is completely ok, just needs
730 to be mentioned in user documentation.
734 @item Is heap big enough?
735 @item Which charset is supported by console?
736 @item Does platform have disk driver?
737 @item Do you have network card support?
738 @item Are you able to retrieve datetime (with date)?
739 @item Are you able to set datetime (with date)?
740 @item Is serial supported?
741 @item Do you have direct disk support?
742 @item Do you have direct keyboard support?
743 @item Do you have USB support?
744 @item Do you support loading through network?
745 @item Do you support loading from disk?
746 @item Do you support chainloading?
747 @item Do you support network chainloading?
748 @item Does cpuid command supports checking all
749 CPU features that the user might want conditionalise on
750 (64-bit mode, hypervisor,...)
751 @item Do you support hints? How reliable are they?
752 @item Does platform have ACPI? If so do ``acpi'' and ``lsacpi'' modules work?
753 @item Do any of platform-specific operations mentioned in the relevant section of
754 user manual makes sense on your platform?
755 @item Does your platform support PCI? If so is there an appropriate driver for
757 @item Do you support badram?
761 @chapter Error Handling
763 Error handling in GRUB 2 is based on exception handling model. As C language
764 doesn't directly support exceptions, exception handling behavior is emulated
767 When exception is raised, function must return to calling function. If calling
768 function does not provide handling of the exception it must return back to its
769 calling function and so on, until exception is handled. If exception is not
770 handled before prompt is displayed, error message will be shown to user.
772 Exception information is stored on @code{grub_errno} global variable. If
773 @code{grub_errno} variable contains value @code{GRUB_ERR_NONE}, there is no active
774 exception and application can continue normal processing. When @code{grub_errno} has
775 other value, it is required that application code either handles this error or
776 returns instantly to caller. If function is with return type @code{grub_err_t} is
777 about to return @code{GRUB_ERR_NONE}, it should not set @code{grub_errno} to that
778 value. Only set @code{grub_errno} in cases where there is error situation.
780 Simple exception forwarder.
783 forwarding_example (void)
785 /* Call function that might cause exception. */
788 /* No special exception handler, just forward possible exceptions. */
789 if (grub_errno != GRUB_ERR_NONE)
794 /* All is OK, do more processing. */
796 /* Return OK signal, to caller. */
797 return GRUB_ERR_NONE;
801 Error reporting has two components, the actual error code (of type
802 @code{grub_err_t}) and textual message that will be displayed to user. List of
803 valid error codes is listed in header file @file{include/grub/err.h}. Textual
804 error message can contain any textual data. At time of writing, error message
805 can contain up to 256 characters (including terminating NUL). To ease error
806 reporting there is a helper function @code{grub_error} that allows easier
807 formatting of error messages and should be used instead of writing directly to
810 Example of error reporting.
815 return grub_error (GRUB_ERR_FILE_NOT_FOUND,
816 "Failed to read %s, tried %d times.",
822 If there is a special reason that error code does not need to be taken account,
823 @code{grub_errno} can be zeroed back to @code{GRUB_ERR_NONE}. In cases like this all
824 previous error codes should have been handled correctly. This makes sure that
825 there are no unhandled exceptions.
827 Example of zeroing @code{grub_errno}.
832 /* Try to probe device type 1. */
834 if (grub_errno == GRUB_ERR_NONE)
836 /* Device type 1 was found on system. */
838 return GRUB_ERR_NONE;
840 /* Zero out error code. */
841 grub_errno = GRUB_ERR_NONE;
843 /* No device type 1 found, try to probe device type 2. */
844 probe_for_device2 ();
845 if (grub_errno == GRUB_ERR_NONE)
847 /* Device type 2 was found on system. */
849 return GRUB_ERR_NONE;
851 /* Zero out error code. */
852 grub_errno = GRUB_ERR_NONE;
854 /* Return custom error message. */
855 return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No device type 1 or 2 found.");
859 Some times there is a need to continue processing even if there is a error
860 state in application. In situations like this, there is a needed to save old
861 error state and then call other functions that might fail. To aid in this,
862 there is a error stack implemented. Error state can be pushed to error stack
863 by calling function @code{grub_error_push ()}. When processing has been completed,
864 @code{grub_error_pop ()} can be used to pop error state from stack. Error stack
865 contains predefined amount of error stack items. Error stack is protected for
866 overflow and marks these situations so overflow error does not get unseen.
867 If there is no space available to store error message, it is simply discarded
868 and overflow will be marked as happened. When overflow happens, it most likely
869 will corrupt error stack consistency as for pushed error there is no matching
870 pop, but overflow message will be shown to inform user about the situation.
871 Overflow message will be shown at time when prompt is about to be drawn.
873 Example usage of error stack.
875 /* Save possible old error message. */
878 /* Do your stuff here. */
879 call_possibly_failing_function ();
881 if (grub_errno != GRUB_ERR_NONE)
883 /* Inform rest of the code that there is error (grub_errno
884 is set). There is no pop here as we want both error states
889 /* Restore old error state by popping previous item from stack. */
895 @c By Robert Millan and Carles Pina
896 If you have commit access, please setup CIA in your Bazaar
897 config so those in IRC receive notification of your commits.
899 In @file{~/.bazaar/bazaar.conf}, add "cia_send_revno = true".
900 Optionally, you can also add "cia_user = myusername" if you'd
901 like CIA service to use a specific account (for statistical purpose).
903 In the @file{.bzr/branch/branch.conf} of your checkout branch,
904 "set nickname = /path_to_this_branch" and "cia_project = GNU GRUB".
906 Additionally, please set cia_send_revno in the [DEFAULT] section
907 of your @file{~/.bazaar/bazaar.conf}. E.g.:
911 cia_send_revno = true
914 Remember to install cia-clients (Debian/Ubuntu package) to be able to use CIA.
916 Keep in mind Bazaar sends notifications for all commits to branches that have
917 this setting, regardless of whether they're bound branches (checkouts) or not.
918 So if you make local commits in a non-bound branch and it bothers you that
919 others can read them, do not use this setting.
921 @node BIOS port memory map
922 @chapter BIOS port memory map
923 @c By Yoshinori K Okuji
925 @multitable @columnfractions .15 .25 .5
926 @headitem Start @tab End @tab Usage
927 @item 0 @tab 0x1000 - 1 @tab BIOS and real mode interrupts
928 @item 0x07BE @tab 0x07FF @tab Partition table passed to another boot loader
929 @item ? @tab 0x2000 - 1 @tab Real mode stack
930 @item 0x7C00 @tab 0x7D00 - 1 @tab Boot sector
931 @item 0x8000 @tab ? @tab GRUB kernel
932 @item 0x68000 @tab 0x78000 - 1 @tab Disk buffer
933 @item ? @tab 0x80000 - 1 @tab Protected mode stack
934 @item 0x80000 @tab ? @tab Heap
935 @item ? @tab 0xA0000 - 1 @tab Extended BIOS Data Area
936 @item 0xA0000 @tab 0xC0000 - 1 @tab Video RAM
937 @item 0xC0000 @tab 0x100000 - 1 @tab BIOS
938 @item 0x100000 @tab ? @tab Heap and module code
941 @node Video Subsystem
942 @chapter Video Subsystem
943 @c By VesaJääskeläinen
944 This document contains specification for Video Subsystem for GRUB2.
945 Currently only the usage interface is described in this document.
946 Internal structure of how video drivers are registering and how video
947 driver manager works are not included here.
952 * Example usage of Video API::
958 @subsection grub_video_setup
964 grub_video_setup (unsigned int width, unsigned int height, unsigned int mode_type);
968 Driver will use information provided to it to select best possible video mode and switch to it. Supported values for @code{mode_type} are @code{GRUB_VIDEO_MODE_TYPE_INDEX_COLOR} for index color modes, @code{GRUB_VIDEO_MODE_TYPE_RGB} for direct RGB color modes and @code{GRUB_VIDEO_MODE_TYPE_DOUBLE_BUFFERED} for double buffering. When requesting RGB mode, highest bits per pixel mode will be selected. When requesting Index color mode, mode with highest number of colors will be selected. If all parameters are specified as zero, video adapter will try to figure out best possible mode and initialize it, platform specific differences are allowed here. If there is no mode matching request, error X will be returned. If there are no problems, function returns @code{GRUB_ERR_NONE}.
970 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.
974 @subsection grub_video_restore
980 grub_video_restore (void);
984 Video subsystem will deinitialize activated video driver to restore old state of video device. This can be used to switch back to text mode.
987 @subsection grub_video_get_info
993 grub_video_get_info (struct grub_video_mode_info *mode_info);
996 struct grub_video_mode_info
998 /* Width of the screen. */
1000 /* Height of the screen. */
1001 unsigned int height;
1002 /* Mode type bitmask. Contains information like is it Index color or
1004 unsigned int mode_type;
1005 /* Bits per pixel. */
1007 /* Bytes per pixel. */
1008 unsigned int bytes_per_pixel;
1009 /* Pitch of one scanline. How many bytes there are for scanline. */
1011 /* In index color mode, number of colors. In RGB mode this is 256. */
1012 unsigned int number_of_colors;
1013 /* Optimization hint how binary data is coded. */
1014 enum grub_video_blit_format blit_format;
1015 /* How many bits are reserved for red color. */
1016 unsigned int red_mask_size;
1017 /* What is location of red color bits. In Index Color mode, this is 0. */
1018 unsigned int red_field_pos;
1019 /* How many bits are reserved for green color. */
1020 unsigned int green_mask_size;
1021 /* What is location of green color bits. In Index Color mode, this is 0. */
1022 unsigned int green_field_pos;
1023 /* How many bits are reserved for blue color. */
1024 unsigned int blue_mask_size;
1025 /* What is location of blue color bits. In Index Color mode, this is 0. */
1026 unsigned int blue_field_pos;
1027 /* How many bits are reserved in color. */
1028 unsigned int reserved_mask_size;
1029 /* What is location of reserved color bits. In Index Color mode,
1031 unsigned int reserved_field_pos;
1036 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 @code{GRUB_ERR_BAD_DEVICE} is returned, otherwise @code{mode_info} is filled with valid information and @code{GRUB_ERR_NONE} is returned.
1039 @subsection grub_video_get_blit_format
1044 enum grub_video_blit_format
1045 grub_video_get_blit_format (struct grub_video_mode_info *mode_info);
1048 enum grub_video_blit_format
1050 /* Follow exactly field & mask information. */
1051 GRUB_VIDEO_BLIT_FORMAT_RGBA,
1052 /* Make optimization assumption. */
1053 GRUB_VIDEO_BLIT_FORMAT_R8G8B8A8,
1054 /* Follow exactly field & mask information. */
1055 GRUB_VIDEO_BLIT_FORMAT_RGB,
1056 /* Make optimization assumption. */
1057 GRUB_VIDEO_BLIT_FORMAT_R8G8B8,
1058 /* When needed, decode color or just use value as is. */
1059 GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR
1064 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 @code{grub_video_get_info} to query video color coding settings.
1067 @subsection grub_video_set_palette
1073 grub_video_set_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
1076 struct grub_video_palette_data
1078 grub_uint8_t r; /* Red color value (0-255). */
1079 grub_uint8_t g; /* Green color value (0-255). */
1080 grub_uint8_t b; /* Blue color value (0-255). */
1081 grub_uint8_t a; /* Reserved bits value (0-255). */
1086 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. @code{start} will tell what hardware color index (or emulated color index) will be set to according information in first indice of @code{palette_data}, after that both hardware color index and @code{palette_data} index will be incremented until @code{count} number of colors have been set.
1089 @subsection grub_video_get_palette
1095 grub_video_get_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
1098 struct grub_video_palette_data
1100 grub_uint8_t r; /* Red color value (0-255). */
1101 grub_uint8_t g; /* Green color value (0-255). */
1102 grub_uint8_t b; /* Blue color value (0-255). */
1103 grub_uint8_t a; /* Reserved bits value (0-255). */
1108 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. @code{start} will tell what hardware color index (or emulated color index) will be used as a source for first indice of @code{palette_data}, after that both hardware color index and @code{palette_data} index will be incremented until @code{count} number of colors have been read.
1111 @subsection grub_video_set_viewport
1117 grub_video_set_viewport (unsigned int x, unsigned int y, unsigned int width, unsigned int height);
1121 Used to specify viewport where draw commands are performed. When viewport is set, all draw commands coordinates relate to those specified by @code{x} and @code{y}. If draw commands try to draw over viewport, they are clipped. If developer requests larger than possible viewport, width and height will be clamped to fit screen. If @code{x} and @code{y} are out of bounds, all functions drawing to screen will not be displayed. In order to maximize viewport, use @code{grub_video_get_info} to query actual screen dimensions and provide that information to this function.
1124 @subsection grub_video_get_viewport
1130 grub_video_get_viewport (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height);
1134 Used to query current viewport dimensions. Software developer can use this to choose best way to render contents of the viewport.
1137 @subsection grub_video_map_color
1143 grub_video_map_color (grub_uint32_t color_name);
1147 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 @code{GRUB_COLOR_CONSOLE_BACKGROUND}, @code{GRUB_COLOR_CONSOLE_TEXT}. The actual color defines are not specified at this point.
1150 @subsection grub_video_map_rgb
1156 grub_video_map_rgb (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue);
1160 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.
1163 @subsection grub_video_map_rgba
1169 grub_video_map_rgba (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue, grub_uint8_t alpha);
1173 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.
1176 @subsection grub_video_unmap_color
1182 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);
1186 Unmap color value from @code{color} to color channels in @code{red}, @code{green}, @code{blue} and @code{alpha}. Values will be in range 0-255. Active rendering target will be used for color domain. In case alpha information is not available in rendering target, it is assumed to be opaque (having value 255).
1189 @subsection grub_video_fill_rect
1195 grub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height);
1199 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.
1201 Software developer should use either @code{grub_video_map_color}, @code{grub_video_map_rgb} or @code{grub_video_map_rgba} to map requested color to @code{color} parameter.
1204 @subsection grub_video_blit_glyph
1210 grub_video_blit_glyph (struct grub_font_glyph *glyph, grub_video_color_t color, int x, int y);
1213 struct grub_font_glyph @{
1219 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 @code{grub_video_map_rgb} or @code{grub_video_map_rgba} to map requested color to @code{color} parameter.
1222 @subsection grub_video_blit_bitmap
1228 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);
1231 struct grub_video_bitmap
1236 enum grub_video_blit_operators
1238 GRUB_VIDEO_BLIT_REPLACE,
1239 GRUB_VIDEO_BLIT_BLEND
1244 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 @code{oper} specifies should source pixel replace data in screen or blend with pixel alpha value.
1246 Software developer should use @code{grub_video_bitmap_create} or @code{grub_video_bitmap_load} to create or load bitmap data.
1249 @subsection grub_video_blit_render_target
1255 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);
1258 struct grub_video_render_target @{
1259 /* This is private data for video driver. Should not be accessed from elsewhere directly. */
1262 enum grub_video_blit_operators
1264 GRUB_VIDEO_BLIT_REPLACE,
1265 GRUB_VIDEO_BLIT_BLEND
1270 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 @code{oper} specifies should source pixel replace data in screen or blend with pixel alpha value.
1273 @subsection grub_video_scroll
1279 grub_video_scroll (grub_video_color_t color, int dx, int dy);
1283 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.
1286 @subsection grub_video_swap_buffers
1292 grub_video_swap_buffers (void);
1296 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.
1299 @subsection grub_video_create_render_target
1305 grub_video_create_render_target (struct grub_video_render_target **result, unsigned int width, unsigned int height, unsigned int mode_type);
1308 struct grub_video_render_target @{
1309 /* This is private data for video driver. Should not be accessed from elsewhere directly. */
1314 Driver will use information provided to it to create best fitting render target. @code{mode_type} will be used to guide on selecting what features are wanted for render target. Supported values for @code{mode_type} are @code{GRUB_VIDEO_MODE_TYPE_INDEX_COLOR} for index color modes, @code{GRUB_VIDEO_MODE_TYPE_RGB} for direct RGB color modes and @code{GRUB_VIDEO_MODE_TYPE_ALPHA} for alpha component.
1317 @subsection grub_video_delete_render_target
1323 grub_video_delete_render_target (struct grub_video_render_target *target);
1327 Used to delete previously created render target. If @code{target} contains @code{NULL} pointer, nothing will be done. If render target is correctly destroyed, GRUB_ERR_NONE is returned.
1330 @subsection grub_video_set_active_render_target
1336 grub_video_set_active_render_target (struct grub_video_render_target *target);
1340 Sets active render target. If this comand is successful all drawing commands will be done to specified @code{target}. There is also special values for target, @code{GRUB_VIDEO_RENDER_TARGET_DISPLAY} used to reference screen's front buffer, @code{GRUB_VIDEO_RENDER_TARGET_FRONT_BUFFER} used to reference screen's front buffer (alias for @code{GRUB_VIDEO_RENDER_TARGET_DISPLAY}) and @code{GRUB_VIDEO_RENDER_TARGET_BACK_BUFFER} used to reference back buffer (if double buffering is enabled). If render target is correclty switched GRUB_ERR_NONE is returned. In no any event shall there be non drawable active render target.
1343 @subsection grub_video_get_active_render_target
1349 grub_video_get_active_render_target (struct grub_video_render_target **target);
1353 Returns currently active render target. It returns value in @code{target} that can be subsequently issued back to @code{grub_video_set_active_render_target}.
1356 @node Example usage of Video API
1357 @section Example usage of Video API
1358 @subsection Example of screen setup
1361 /* Try to initialize video mode 1024 x 768 with direct RGB. */
1362 rc = grub_video_setup (1024, 768, GRUB_VIDEO_MODE_TYPE_RGB);
1363 if (rc != GRUB_ERR_NONE)
1365 /* Fall back to standard VGA Index Color mode. */
1366 rc = grub_video_setup (640, 480, GRUB_VIDEO_MODE_TYPE_INDEX);
1367 if (rc != GRUB_ERR_NONE)
1373 @subsection Example of setting up console viewport
1375 grub_uint32_t x, y, width, height;
1376 grub_video_color_t color;
1377 struct grub_font_glyph glyph;
1379 /* Query existing viewport. */
1380 grub_video_get_viewport (&x, &y, &width, &height);
1381 /* Fill background. */
1382 color = grub_video_map_color (GRUB_COLOR_BACKGROUND);
1383 grub_video_fill_rect (color, 0, 0, width, height);
1384 /* Setup console viewport. */
1385 grub_video_set_viewport (x + 10, y + 10, width - 20, height - 20);
1386 grub_video_get_viewport (&x, &y, &width, &height);
1387 color = grub_video_map_color (GRUB_COLOR_CONSOLE_BACKGROUND);
1388 grub_video_fill_rect (color, 0, 0, width, height);
1389 /* Draw text to viewport. */
1390 color = grub_video_map_color (GRUB_COLOR_CONSOLE_TEXT);
1391 grub_font_get_glyph ('X', &glyph);
1392 grub_video_blit_glyph (&glyph, color, 0, 0);
1398 @subsection grub_video_bitmap_create
1401 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)
1406 Creates a new bitmap with given dimensions and blitting format. Allocated bitmap data can then be modified freely and finally blitted with @code{grub_video_blit_bitmap} to rendering target.
1409 @subsection grub_video_bitmap_destroy
1413 grub_err_t grub_video_bitmap_destroy (struct grub_video_bitmap *bitmap);
1418 When bitmap is no longer needed, it can be freed from memory using this command. @code{bitmap} is previously allocated bitmap with @code{grub_video_bitmap_create} or loaded with @code{grub_video_bitmap_load}.
1421 @subsection grub_video_bitmap_load
1425 grub_err_t grub_video_bitmap_load (struct grub_video_bitmap **bitmap, const char *filename);
1430 Tries to load given bitmap (@code{filename}) using registered bitmap loaders. In case bitmap format is not recognized or supported error @code{GRUB_ERR_BAD_FILE_TYPE} is returned.
1433 @subsection grub_video_bitmap_get_width
1437 unsigned int grub_video_bitmap_get_width (struct grub_video_bitmap *bitmap);
1442 Returns bitmap width.
1445 @subsection grub_video_bitmap_get_height
1449 unsigned int grub_video_bitmap_get_height (struct grub_video_bitmap *bitmap);
1454 Return bitmap height.
1457 @subsection grub_video_bitmap_get_mode_info
1461 void grub_video_bitmap_get_mode_info (struct grub_video_bitmap *bitmap, struct grub_video_mode_info *mode_info);
1466 Returns bitmap format details in form of @code{grub_video_mode_info}.
1469 @subsection grub_video_bitmap_get_data
1473 void *grub_video_bitmap_get_data (struct grub_video_bitmap *bitmap);
1478 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.
1481 @node PFF2 Font File Format
1482 @chapter PFF2 Font File Format
1484 @c Author: Colin D. Bennett <colin@gibibit.com>
1485 @c Date: 8 January 2009
1495 @section Introduction
1497 The goal of this format is to provide a bitmap font format that is simple to
1498 use, compact, and cleanly supports Unicode.
1501 @subsection Goals of the GRUB Font Format
1504 @item Simple to read and use.
1505 Since GRUB will only be reading the font files,
1506 we are more concerned with making the code to read the font simple than we
1507 are with writing the font.
1509 @item Compact storage.
1510 The fonts will generally be stored in a small boot
1511 partition where GRUB is located, and this may be on a removable storage
1512 device such as a CD or USB flash drive where space is more limited than it
1513 is on most hard drives.
1516 GRUB should not have to deal with multiple character
1517 encodings. The font should always use Unicode character codes for simple
1518 internationalization.
1521 @subsection Why Another Font Format?
1523 There are many existing bitmap font formats that GRUB could use. However,
1524 there are aspects of these formats that may make them less than suitable for
1525 use in GRUB at this time:
1529 Inefficient storage; uses ASCII to describe properties and
1530 hexadecimal numbers in ASCII for the bitmap rows.
1532 Many format variations such as byte order and bitmap padding (rows
1533 padded to byte, word, etc.) would result in more complex code to
1534 handle the font format.
1537 @node File Structure
1538 @section File Structure
1540 A file @strong{section} consists of a 4-byte name, a 32-bit big-endian length (not
1541 including the name or length), and then @var{length} more section-type-specific
1544 The standard file extension for PFF2 font files is @file{.pf2}.
1547 @subsection Section Types
1551 @strong{File type ID} (ASCII string). This must be the first section in the file. It has length 4
1552 and the contents are the four bytes of the ASCII string @samp{PFF2}.
1555 @strong{Font name} (ASCII string). This is the full font name including family,
1556 weight, style, and point size. For instance, "Helvetica Bold Italic 14".
1559 @strong{Font family name} (ASCII string). For instance, "Helvetica". This should
1560 be included so that intelligent font substitution can take place.
1563 @strong{Font weight} (ASCII string). Valid values are @samp{bold} and @samp{normal}.
1564 This should be included so that intelligent font substitution can take
1568 @strong{Font slant} (ASCII string). Valid values are @samp{italic} and @samp{normal}.
1569 This should be included so that intelligent font substitution can take
1573 @strong{Font point size} (uint16be).
1576 @strong{Maximum character width in pixels} (uint16be).
1579 @strong{Maximum character height in pixels} (uint16be).
1582 @strong{Ascent in pixels} (uint16be). @xref{Font Metrics}, for details.
1585 @strong{Descent in pixels} (uint16be). @xref{Font Metrics}, for details.
1588 @strong{Character index.}
1589 The character index begins with a 32-bit big-endian unsigned integer
1590 indicating the total size of the section, not including this size value.
1591 For each character, there is an instance of the following entry structure:
1594 @item @strong{Unicode code point.} (32-bit big-endian integer.)
1596 @item @strong{Storage flags.} (byte.)
1601 If equal to 000 binary, then the character data is stored
1602 uncompressed beginning at the offset indicated by the character's
1603 @strong{offset} value.
1605 If equal to 001 binary, then the character data is stored within a
1606 compressed character definition block that begins at the offset
1607 within the file indicated by the character's @strong{offset} value.
1610 @item @strong{Offset.} (32-bit big-endian integer.)
1612 A marker that indicates the remainder of the file is data accessed via
1613 the character index (CHIX) section. When reading this font file, the rest
1614 of the file can be ignored when scanning the sections. The length should
1615 be set to -1 (0xFFFFFFFF).
1617 Supported data structures:
1619 Character definition
1620 Each character definition consists of:
1623 @item @strong{Width.}
1624 Width of the bitmap in pixels. The bitmap's extents
1625 represent the glyph's bounding box. @code{uint16be}.
1627 @item @strong{Height.}
1628 Height of the bitmap in pixels. The bitmap's extents
1629 represent the glyph's bounding box. @code{uint16be}.
1631 @item @strong{X offset.}
1632 The number of pixels to shift the bitmap by
1633 horizontally before drawing the character. @code{int16be}.
1635 @item @strong{Y offset.}
1636 The number of pixels to shift the bitmap by
1637 vertically before drawing the character. @code{int16be}.
1639 @item @strong{Device width.}
1640 The number of pixels to advance horizontally from
1641 this character's origin to the origin of the next character.
1644 @item @strong{Bitmap data.}
1645 This is encoded as a string of bits. It is
1646 organized as a row-major, top-down, left-to-right bitmap. The most
1647 significant bit of each byte is taken to be the leftmost or uppermost
1648 bit in the byte. For the sake of compact storage, rows are not padded
1649 to byte boundaries (i.e., a single byte may contain bits belonging to
1650 multiple rows). The last byte of the bitmap @strong{is} padded with zero
1651 bits in the bits positions to the right of the last used bit if the
1652 bitmap data does not fill the last byte.
1654 The length of the @strong{bitmap data} field is (@var{width} * @var{height} + 7) / 8
1655 using integer arithmetic, which is equivalent to ceil(@var{width} *
1656 @var{height} / 8) using real number arithmetic.
1658 It remains to be determined whether bitmap fonts usually make all
1659 glyph bitmaps the same height, or if smaller glyphs are stored with
1660 bitmaps having a lesser height. In the latter case, the baseline
1661 would have to be used to calculate the location the bitmap should be
1662 anchored at on screen.
1669 @section Font Metrics
1673 The distance from the baseline to the top of most characters.
1674 Note that in some cases characters may extend above the ascent.
1677 The distance from the baseline to the bottom of most characters. Note that
1678 in some cases characters may extend below the descent.
1681 The amount of space, in pixels, to leave between the descent of one line of
1682 text and the ascent of the next line. This metrics is not specified in the
1683 current file format; instead, the font rendering engine calculates a
1684 reasonable leading value based on the other font metrics.
1686 @item Horizonal leading.
1687 The amount of space, in pixels, to leave horizontally between the left and
1688 right edges of two adjacent glyphs. The @strong{device width} field determines
1689 the effective leading value that is used to render the font.
1692 @image{font_char_metrics,,,,png}
1694 An illustration of how the various font metrics apply to characters.
1698 @node Graphical Menu Software Design
1699 @chapter Graphical Menu Software Design
1701 @c By Colin D. Bennett <colin@gibibit.com>
1702 @c Date: 17 August 2008
1706 * Startup Sequence::
1708 * Command Line Window::
1711 @node Introduction_2
1712 @section Introduction
1714 The @samp{gfxmenu} module provides a graphical menu interface for GRUB 2. It
1715 functions as an alternative to the menu interface provided by the @samp{normal}
1716 module, which uses the grub terminal interface to display a menu on a
1717 character-oriented terminal.
1719 The graphical menu uses the GRUB video API, which is currently for the VESA
1720 BIOS extensions (VBE) 2.0+. This is supported on the i386-pc platform.
1721 However, the graphical menu itself does not depend on using VBE, so if another
1722 GRUB video driver were implemented, the @samp{gfxmenu} graphical menu would work
1723 on the new video driver as well.
1726 @node Startup Sequence
1727 @section Startup Sequence
1730 @item grub_enter_normal_mode [normal/main.c]
1731 @item grub_normal_execute [normal/main.c]
1732 @item read_config_file [normal/main.c]
1733 @item (When @file{gfxmenu.mod} is loaded with @command{insmod}, it will call @code{grub_menu_viewer_register()} to register itself.)
1734 @item GRUB_MOD_INIT (gfxmenu) [gfxmenu/gfxmenu.c]
1735 @item grub_menu_viewer_register [kern/menu_viewer.c]
1736 @item grub_menu_viewer_show_menu [kern/menu_viewer.c]
1737 @item get_current_menu_viewer() [kern/menu_viewer.c]
1738 @item show_menu() [gfxmenu/gfxmenu.c]
1739 @item grub_gfxmenu_model_new [gfxmenu/model.c]
1740 @item grub_gfxmenu_view_new [gfxmenu/view.c]
1741 @item set_graphics_mode [gfxmenu/view.c]
1742 @item grub_gfxmenu_view_load_theme [gfxmenu/theme_loader.c]
1746 @node GUI Components
1747 @section GUI Components
1749 The graphical menu implements a GUI component system that supports a
1750 container-based layout system. Components can be added to containers, and
1751 containers (which are a type of component) can then be added to other
1752 containers, to form a tree of components. Currently, the root component of
1753 this tree is a @samp{canvas} component, which allows manual layout of its child
1756 Components (non-container):
1762 @item circular_progress
1763 @item list (currently hard coded to be a boot menu list)
1774 The GUI component instances are created by the theme loader in
1775 @file{gfxmenu/theme_loader.c} when a theme is loaded. Theme files specify
1776 statements such as @samp{+vbox@{ +label @{ text="Hello" @} +label@{ text="World" @} @}}
1777 to add components to the component tree root. By nesting the component
1778 creation statements in the theme file, the instantiated components are nested
1781 When a component is added to a container, that new child is considered @strong{owned}
1782 by the container. Great care should be taken if the caller retains a
1783 reference to the child component, since it will be destroyed if its parent
1784 container is destroyed. A better choice instead of storing a pointer to the
1785 child component is to use the component ID to find the desired component.
1786 Component IDs do not have to be unique (it is often useful to have multiple
1787 components with an ID of "__timeout__", for instance).
1789 In order to access and use components in the component tree, there are two
1790 functions (defined in @file{gfxmenu/gui_util.c}) that are particularly useful:
1794 @item @code{grub_gui_find_by_id (root, id, callback, userdata)}:
1796 This function ecursively traverses the component tree rooted at @var{root}, and
1797 for every component that has an ID equal to @var{id}, calls the function pointed
1798 to by @var{callback} with the matching component and the void pointer @var{userdata}
1799 as arguments. The callback function can do whatever is desired to use the
1800 component passed in.
1802 @item @code{grub_gui_iterate_recursively (root, callback, userdata)}:
1804 This function calls the function pointed to by @var{callback} for every
1805 component that is a descendant of @var{root} in the component tree. When the
1806 callback function is called, the component and the void pointer @var{userdata}
1807 as arguments. The callback function can do whatever is desired to use the
1808 component passed in.
1811 @node Command Line Window
1812 @section Command Line Window
1814 The terminal window used to provide command line access within the graphical
1815 menu is managed by @file{gfxmenu/view.c}. The @samp{gfxterm} terminal is used, and
1816 it has been modified to allow rendering to an offscreen render target to allow
1817 it to be composed into the double buffering system that the graphical menu
1818 view uses. This is bad for performance, however, so it would probably be a
1819 good idea to make it possible to temporarily disable double buffering as long
1820 as the terminal window is visible. There are still unresolved problems that
1821 occur when commands are executed from the terminal window that change the
1822 graphics mode. It's possible that making @code{grub_video_restore()} return to
1823 the graphics mode that was in use before @code{grub_video_setup()} was called
1824 might fix some of the problems.
1827 @node Copying This Manual
1828 @appendix Copying This Manual
1831 * GNU Free Documentation License:: License for copying this manual.
1840 @c Currently, we use only the Concept Index.