source: grub-pc/trunk/fuentes/docs/grub-dev.texi @ 22

Last change on this file since 22 was 22, checked in by mabarracus, 4 years ago

updated version and apply net.ifnames=0 into debian/rules

File size: 71.4 KB
Line 
1\input texinfo
2@c -*-texinfo-*-
3@c %**start of header
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.
8@syncodeindex fn cp
9@syncodeindex vr cp
10@syncodeindex ky cp
11@syncodeindex pg cp
12@syncodeindex tp cp
13@c %**end of header
14
15@footnotestyle separate
16@paragraphindent 3
17@finalout
18
19@copying
20This developer manual is for GNU GRUB (version @value{VERSION},
21@value{UPDATED}).
22
23Copyright @copyright{} 1999,2000,2001,2002,2004,2005,2006,2008,2009,2010,2011 Free Software Foundation, Inc.
24
25@quotation
26Permission is granted to copy, distribute and/or modify this document
27under the terms of the GNU Free Documentation License, Version 1.2 or
28any later version published by the Free Software Foundation; with no
29Invariant Sections.
30@end quotation
31@end copying
32
33@dircategory Kernel
34@direntry
35* grub-dev: (grub-dev).                 The GRand Unified Bootloader Dev
36@end direntry
37
38@setchapternewpage odd
39
40@titlepage
41@sp 10
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
47@author Colin Watson
48@author Robert Millan
49@author Carles Pina
50@c The following two commands start the copyright page.
51@page
52@vskip 0pt plus 1filll
53@insertcopying
54@end titlepage
55
56@c Output the table of contents at the beginning.
57@contents
58
59@finalout
60@headings double
61
62@ifnottex
63@node Top
64@top GNU GRUB developer manual
65
66This is the developer documentation of GNU GRUB, the GRand Unified Bootloader,
67a flexible and powerful boot loader program for a wide range of
68architectures.
69
70This edition documents version @value{VERSION}.
71
72@insertcopying
73@end ifnottex
74
75@menu
76* Getting the source code::
77* Coding style::
78* Finding your way around::
79* Contributing Changes::
80* Porting::
81* Error Handling::
82* Stack and heap size::
83* BIOS port memory map::
84* Video Subsystem::
85* PFF2 Font File Format::
86* Graphical Menu Software Design::
87* Copying This Manual::         Copying This Manual
88* Index::
89@end menu
90
91
92@node Getting the source code
93@chapter Getting the source code
94
95GRUB is maintained using the @uref{GIT revision
96control system}.  To fetch:
97
98@example
99git clone git://git.sv.gnu.org/grub.git
100@end example
101
102Web access is available under
103@example
104http://git.savannah.gnu.org/cgit/grub.git/
105@end example
106
107The branches available are:
108
109@table @samp
110@item master
111      Main developpement branch.
112@item grub-legacy
113      GRUB 0.97 codebase. Kept for reference and legal reasons
114@item multiboot
115      Multiboot specfication
116@item multiboot2
117      Multiboot2 specfication
118@item developper branches
119      Prefixed with developper name. Every developper of a team manages his own branches.
120      Developper branches do not need changelog entries.
121@end table
122
123Once you have used @kbd{git clone} to fetch an initial copy of a branch, you
124can use @kbd{git pull} to keep it up to date.  If you have modified your
125local version, you may need to resolve conflicts when pulling.
126
127@node Coding style
128@chapter Coding style
129@c By YoshinoriOkuji, VesaJääskeläinen and ColinBennett
130
131Basically we follow the @uref{http://www.gnu.org/prep/standards_toc.html, GNU Coding Standards}. We define additional conventions for GRUB here.
132
133@menu
134* Naming Conventions::
135* Functions::
136* Variables::
137* Types::
138* Macros::
139* Comments::
140* Multi-Line Comments::
141@end menu
142
143@node Naming Conventions
144@section Naming Conventions
145
146All 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.
147
148@node Functions
149@section Functions
150
151If 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.
152
153After 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).
154
155If a function is local, its name may not start with any prefix. It must start with a verb.
156
157@node Variables
158@section Variables
159
160The 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_.
161
162After 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).
163
164If 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.
165
166If a variable is local, you may choose any shorter name, as long as it wouldn't make code less readable (e.g. i).
167
168@node Types
169@section Types
170
171The 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_.
172
173The name must be suffixed with _t, to emphasize the fact that it is a type but not a variable or a function.
174
175@node Macros
176@section Macros
177
178If 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.
179
180@node Comments
181@section Comments
182
183All comments shall be C-style comments, of the form @samp{/* @dots{} */}.
184
185Comments 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.
186
187Acceptable:
188@example
189/* The page # that is the front buffer.  */
190int displayed_page;
191/* The page # that is the back buffer.  */
192int render_page;
193@end example
194
195Unacceptable:
196@example
197int displayed_page;           /* The page # that is the front buffer. */
198int render_page;              /* The page # that is the back buffer. */
199@end example
200
201@node Multi-Line Comments
202@section Multi-Line Comments
203
204Comments spanning multiple lines shall be formatted with all lines after the first aligned with the first line. 
205
206Asterisk characters should not be repeated a the start of each subsequent line.
207
208Acceptable:
209@example
210/* This is a comment
211   which spans multiple lines.
212   It is long.  */
213@end example
214
215Unacceptable:
216@example
217/*
218 * This is a comment
219 * which spans multiple lines.
220 * It is long. */
221@end example
222
223The opening @samp{/*} and closing @samp{*/} should be placed together on a line with text.
224
225@node Finding your way around
226@chapter Finding your way around
227
228Here is a brief map of the GRUB code base.
229
230GRUB uses Autoconf and Automake, with most of the Automake input generated
231by AutoGen.  The top-level build rules are in @file{configure.ac},
232@file{grub-core/Makefile.core.def}, and @file{Makefile.util.def}.  Each
233block in a @file{*.def} file represents a build target, and specifies the
234source files used to build it on various platforms.  The @file{*.def} files
235are processed into AutoGen input by @file{gentpl.py} (which you only need to
236look at if you are extending the build system).  If you are adding a new
237module which follows an existing pattern, such as a new command or a new
238filesystem implementation, it is usually easiest to grep
239@file{grub-core/Makefile.core.def} and @file{Makefile.util.def} for an
240existing example of that pattern to find out where it should be added.
241
242In general, code that may be run at boot time is in a subdirectory of
243@file{grub-core}, while code that is only run from within a full operating
244system is in a subdirectory of the top level.
245
246Low-level boot code, such as the MBR implementation on PC BIOS systems, is
247in the @file{grub-core/boot/} directory.
248
249The GRUB kernel is in @file{grub-core/kern/}.  This contains core facilities
250such as the device, disk, and file frameworks, environment variable
251handling, list processing, and so on.  The kernel should contain enough to
252get up to a rescue prompt.  Header files for kernel facilities, among
253others, are in @file{include/}.
254
255Terminal implementations are in @file{grub-core/term/}.
256
257Disk access code is spread across @file{grub-core/disk/} (for accessing the
258disk devices themselves), @file{grub-core/partmap/} (for interpreting
259partition table data), and @file{grub-core/fs/} (for accessing filesystems).
260Note that, with the odd specialised exception, GRUB only contains code to
261@emph{read} from filesystems and tries to avoid containing any code to
262@emph{write} to filesystems; this lets us confidently assure users that GRUB
263cannot be responsible for filesystem corruption.
264
265PCI and USB bus handling is in @file{grub-core/bus/}.
266
267Video handling code is in @file{grub-core/video/}.  The graphical menu
268system uses this heavily, but is in a separate directory,
269@file{grub-core/gfxmenu/}.
270
271Most commands are implemented by files in @file{grub-core/commands/}, with
272the following exceptions:
273
274@itemize
275@item
276A few core commands live in @file{grub-core/kern/corecmd.c}.
277
278@item
279Commands related to normal mode live under @file{grub-core/normal/}.
280
281@item
282Commands that load and boot kernels live under @file{grub-core/loader/}.
283
284@item
285The @samp{loopback} command is really a disk device, and so lives in
286@file{grub-core/disk/loopback.c}.
287
288@item
289The @samp{gettext} command lives under @file{grub-core/gettext/}.
290
291@item
292The @samp{loadfont} and @samp{lsfonts} commands live under
293@file{grub-core/font/}.
294
295@item
296The @samp{serial}, @samp{terminfo}, and @samp{background_image} commands
297live under @file{grub-core/term/}.
298
299@item
300The @samp{efiemu_*} commands live under @file{grub-core/efiemu/}.
301
302@item
303OS-dependent code should be under @file{grub-core/osdep/}
304
305@item
306Utility programs meant to be run from a full operating system
307(except OS-dependent code mentioned previously) are in @file{util/}.
308
309@end itemize
310
311There are a few other special-purpose exceptions; grep for them if they
312matter to you.
313
314@node Contributing Changes
315@chapter Contributing changes
316@c By YoshinoriOkuji, VesaJääskeläinen, ColinWatson
317
318Contributing changes to GRUB 2 is welcomed activity. However we have a
319bit of control what kind of changes will be accepted to GRUB 2.
320Therefore it is important to discuss your changes on grub-devel mailing list
321(see MailingLists). On this page there are some basic details on the
322development process and activities.
323
324First of all you should come up with the idea yourself what you want to
325contribute. If you do not have that beforehand you are advised to study this
326manual and try GRUB 2 out to see what you think is missing from there.
327
328Here are additional pointers:
329@itemize
330@item @url{https://savannah.gnu.org/task/?group=grub GRUB's Task Tracker}
331@item @url{https://savannah.gnu.org/bugs/?group=grub GRUB's Bug Tracker}
332@end itemize
333
334If you intended to make changes to GRUB Legacy (<=0.97) those are not accepted
335anymore.
336
337@menu
338* Getting started::
339* Typical Developer Experience::
340* When you are approved for write access to project's files::
341@end menu
342
343@node Getting started
344@section Getting started
345
346@itemize
347@item Always use latest GRUB 2 source code. So get that first.
348
349For 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 GIT repository.
350
351Please check Savannah's GRUB project page for details how to get newest git:
352@uref{https://savannah.gnu.org/git/?group=grub, GRUB 2 git Repository}
353
354@item Compile it and try it out.
355
356It is always good idea to first see that things work somehow and after that
357to start to implement new features or develop fixes to bugs.
358
359@item Study the code.
360
361There are sometimes odd ways to do things in GRUB 2 code base.
362This is mainly related to limited environment where GRUB 2 is being executed.
363You usually do not need to understand it all so it is better to only try to
364look at places that relates to your work. Please do not hesitate to ask for
365help if there is something that you do not understand.
366
367@item Develop a new feature.
368
369Now that you know what to do and how it should work in GRUB 2 code base, please
370be free to develop it. If you have not so far announced your idea on grub-devel
371mailing list, please do it now. This is to make sure you are not wasting your
372time working on the solution that will not be integrated to GRUB 2 code base.
373
374You might want to study our coding style before starting development so you
375do not need to change much of the code when your patch is being reviewed.
376(see @ref{Coding style})
377
378For every accepted patch there has to exist a ChangeLog entry. Our ChangeLog
379consist of changes within source code and are not describing about what the
380change logically does. Please see examples from previous entries.
381
382Also remember that GRUB 2 is licensed under GPLv3 license and that usually
383means that you are not allowed to copy pieces of code from other projects.
384Even if the source project's license would be compatible with GPLv3, please
385discuss it beforehand on grub-devel mailing list.
386
387@item Test your change.
388
389Test that your change works properly. Try it out a couple of times, preferably on different systems, and try to find problems with it.
390
391@item Publish your change.
392
393When you are happy with your change, first make sure it is compilable with
394latest development version of GRUB 2. After that please send a patch to
395grub-devel for review. Please describe in your email why you made the change,
396what it changes and so on. Please be prepared to receive even discouraging
397comments about your patch. There is usually at least something that needs
398to be improved in every patch.
399
400Please use unified diff to make your patch (good match of arguments for diff is @samp{-pruN}).
401
402@item Respond to received feedback.
403
404If you are asked to modify your patch, please do that and resubmit it for
405review. If your change is large you are required to submit a copyright
406agreement to FSF. Please keep in mind that if you are asked to submit
407for copyright agreement, process can take some time and is mandatory
408in order to get your changes integrated.
409
410If you are not on grub-devel to respond to questions, most likely your patch
411will not be accepted. Also if problems arise from your changes later on,
412it would be preferable that you also fix the problem. So stay around
413for a while.
414
415@item Your patch is accepted.
416
417Good 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.
418
419Now you are welcome to do further improvements :)
420@end itemize
421
422@node Typical Developer Experience
423@section Typical Developer Experience
424
425The typical experience for a developer in this project is the following:
426
427@enumerate
428@item You find yourself wanting to do something (e.g. fixing a bug).
429@item You show some result in the mailing list or the IRC.
430@item You are getting to be known to other developers.
431@item You accumulate significant amount of contribution, so copyright assignment is processed.
432@item You are free to check in your changes on your own, legally speaking.
433@end enumerate
434
435At this point, it is rather annoying that you ought to ask somebody else every
436change to be checked in. For efficiency, it is far better, if you can commit
437it yourself. Therefore, our policy is to give you the write permission to our
438official repository, once you have shown your skill and will,
439and the FSF clerks have dealt with your copyright assignment.
440
441@node When you are approved for write access to project's files
442@section When you are approved for write access to project's files
443
444As you might know, GRUB is hosted on
445@url{https://savannah.gnu.org/projects/grub Savannah}, thus the membership
446is managed by Savannah. This means that, if you want to be a member of this
447project:
448
449@enumerate
450@item You need to create your own account on Savannah.
451@item You can submit ``Request for Inclusion'' from ``My Groups'' on Savannah.
452@end enumerate
453
454Then, one of the admins can approve your request, and you will be a member.
455If you don't want to use the Savannah interface to submit a request, you can
456simply notify the admins by email or something else, alternatively. But you
457still need to create an account beforehand.
458
459NOTE: we sometimes receive a ``Request for Inclusion'' from an unknown person.
460In this case, the request would be just discarded, since it is too dangerous
461to allow a stranger to be a member, which automatically gives him a commit
462right to the repository, both for a legal reason and for a technical reason.
463
464If your intention is to just get started, please do not submit a inclusion
465request. Instead, please subscribe to the mailing list, and communicate first
466(e.g. sending a patch, asking a question, commenting on another message...).
467
468@node Porting
469@chapter Porting
470
471GRUB2 is designed to be easily portable accross platforms. But because of the
472nature of bootloader every new port must be done separately. Here is how I did
473MIPS (loongson and ARC) and Xen ports. Note than this is more of suggestions,
474not absolute truth.
475
476First of all grab any architecture specifications you can find in public
477(please avoid NDA).
478
479First stage is ``Hello world''. I've done it outside of GRUB for simplicity.
480Your task is to have a small program which is loadable as bootloader and
481clearly shows its presence to you. If you have easily accessible console
482you can just print a message. If you have a mapped framebuffer you know address
483of, you can draw a square. If you have a debug facility, just hanging without
484crashing might be enough. For the first stage you can choose to load the
485bootloader across the network since format for network image is often easier
486than for local boot and it skips the need of small intermediary stages and
487nvram handling. Additionally you can often have a good idea of the needed
488format by running ``file'' on any netbootable executable for given platform.
489
490This program should probably have 2 parts: an assembler and C one. Assembler one
491handles BSS cleaning and other needed setup (on some platforms you may need
492to switch modes or copy the executable to its definitive position). So your code
493may look like (x86 assembly for illustration purposes)
494
495@example
496        .globl _start
497_start:
498        movl    $_bss_start, %edi
499        movl    $_end, %ecx
500        subl    %edi, %ecx
501        xorl    %eax, %eax
502        cld
503        rep
504        stosb
505        call main
506@end example
507
508@example
509
510static const char msg[] = "Hello, world";
511
512void
513putchar (int c)
514@{
515  ...
516@}
517
518void
519main (void)
520@{
521  const char *ptr = msg;
522  while (*ptr)
523    putchar (*ptr++);
524  while (1);
525@}
526@end example
527
528Sometimes you need a third file: assembly stubs for ABI-compatibility.
529
530Once this file is functional it's time to move it into GRUB2. The startup
531assembly file goes to grub-core/kern/$cpu/$platform/startup.S. You should also
532include grub/symbol.h and replace call to entry point with call to
533EXT_C(grub_main). The C file goes to grub-core/kern/$cpu/$platform/init.c
534and its entry point is renamed to void grub_machine_init (void). Keep final
535infinite loop for now. Stubs file if any goes to
536grub-core/kern/$cpu/$platform/callwrap.S. Sometimes either $cpu or $platform
537is dropped if file is used on several cpus respectivelyplatforms.
538Check those locations if they already have what you're looking for.
539
540Then modify in configure.ac the following parts:
541
542CPU names:
543
544@example
545case "$target_cpu" in
546  i[[3456]]86)  target_cpu=i386 ;;
547  amd64)        target_cpu=x86_64 ;;
548  sparc)        target_cpu=sparc64 ;;
549  s390x)        target_cpu=s390 ;;
550  ...
551esac
552@end example
553
554Sometimes CPU have additional architecture names which don't influence booting.
555You might want to have some canonical name to avoid having bunch of identical
556platforms with different names.
557
558NOTE: it doesn't influence compile optimisations which depend solely on
559chosen compiler and compile options.
560
561@example
562if test "x$with_platform" = x; then
563  case "$target_cpu"-"$target_vendor" in
564    i386-apple) platform=efi ;;
565    i386-*) platform=pc ;;
566    x86_64-apple) platform=efi ;;
567    x86_64-*) platform=pc ;;
568    powerpc-*) platform=ieee1275 ;;
569    ...
570  esac
571else
572  ...
573fi
574@end example
575
576This part deals with guessing the platform from CPU and vendor. Sometimes you
577need to use 32-bit mode for booting even if OS runs in 64-bit one. If so add
578your platform to:
579
580@example
581case "$target_cpu"-"$platform" in
582  x86_64-efi) ;;
583  x86_64-emu) ;;
584  x86_64-*) target_cpu=i386 ;;
585  powerpc64-ieee1275) target_cpu=powerpc ;;
586esac
587@end example
588
589Add your platform to the list of supported ones:
590
591@example
592case "$target_cpu"-"$platform" in
593  i386-efi) ;;
594  x86_64-efi) ;;
595  i386-pc) ;;
596  i386-multiboot) ;;
597  i386-coreboot) ;;
598  ...
599esac
600@end example
601
602If explicit -m32 or -m64 is needed add it to:
603
604@example
605case "$target_cpu" in
606  i386 | powerpc) target_m32=1 ;;
607  x86_64 | sparc64) target_m64=1 ;;
608esac
609@end example
610
611Finally you need to add a conditional to the following block:
612
613@example
614AM_CONDITIONAL([COND_mips_arc], [test x$target_cpu = xmips -a x$platform = xarc])
615AM_CONDITIONAL([COND_sparc64_ieee1275], [test x$target_cpu = xsparc64 -a x$platform = xieee1275])
616AM_CONDITIONAL([COND_powerpc_ieee1275], [test x$target_cpu = xpowerpc -a x$platform = xieee1275])
617@end example
618
619Next stop is gentpl.py. You need to add your platform to the list of supported
620ones (sorry that this list is duplicated):
621
622@example
623GRUB_PLATFORMS = [ "emu", "i386_pc", "i386_efi", "i386_qemu", "i386_coreboot",
624                   "i386_multiboot", "i386_ieee1275", "x86_64_efi",
625                   "mips_loongson", "sparc64_ieee1275",
626                   "powerpc_ieee1275", "mips_arc", "ia64_efi",
627                   "mips_qemu_mips", "s390_mainframe" ]
628@end example
629
630You may also want already to add new platform to one or several of available
631groups. In particular we always have a group for each CPU even when only
632one platform for given CPU is available.
633
634Then comes grub-core/Makefile.core.def. In the block ``kernel'' you'll need
635to define ldflags for your platform ($cpu_$platform_ldflags). You also need to
636declare startup asm file ($cpu_$platform_startup) as well as any other files
637(e.g. init.c and callwrap.S) (e.g. $cpu_$platform = kern/$cpu/$platform/init.c).
638At this stage you will also need to add dummy dl.c and cache.S with functions
639grub_err_t grub_arch_dl_check_header (void *ehdr), grub_err_t
640grub_arch_dl_relocate_symbols (grub_dl_t mod, void *ehdr) (dl.c) and
641void grub_arch_sync_caches (void *address, grub_size_t len) (cache.S). They
642won't be used for now.
643
644You will need to create directory include/$cpu/$platform and a file
645include/$cpu/types.h. The later folowing this template:
646
647@example
648#ifndef GRUB_TYPES_CPU_HEADER
649#define GRUB_TYPES_CPU_HEADER   1
650
651/* The size of void *.  */
652#define GRUB_TARGET_SIZEOF_VOID_P       4
653
654/* The size of long.  */
655#define GRUB_TARGET_SIZEOF_LONG         4
656
657/* mycpu is big-endian.  */
658#define GRUB_TARGET_WORDS_BIGENDIAN     1
659/* Alternatively: mycpu is little-endian.  */
660#undef GRUB_TARGET_WORDS_BIGENDIAN
661
662#endif /* ! GRUB_TYPES_CPU_HEADER */
663@end example
664
665You will also need to add a dummy file to datetime and setjmp modules to
666avoid any of it having no files. It can be just completely empty at this stage.
667
668You'll need to make grub-mkimage.c (util/grub_mkimage.c) aware of the needed
669format. For most commonly used formats like ELF, PE, aout or raw the support
670is already present and you'll need to make it follow the existant code paths
671for your platform adding adjustments if necessary. When done compile:
672
673@example
674./autogen.sh
675./configure --target=$cpu --with-platform=$platform TARGET_CC=.. OBJCOPY=... STRIP=...
676make > /dev/null
677@end example
678
679And create image
680
681@example
682./grub-mkimage -d grub-core -O $format_id -o test.img
683@end example
684
685And it's time to test your test.img.
686
687If it works next stage is to have heap, console and timer.
688
689To have the heap working you need to determine which regions are suitable for
690heap usage, allocate them from firmware and map (if applicable). Then call
691grub_mm_init_region (vois *start, grub_size_t s) for every of this region.
692As a shortcut for early port you can allocate right after _end or have
693a big static array for heap. If you do you'll probably need to come back to
694this later. As for output console you should distinguish between an array of
695text, terminfo or graphics-based console. Many of real-world examples don't
696fit perfectly into any of these categories but one of the models is easier
697to be used as base. In second and third case you should add your platform to
698terminfokernel respectively videoinkernel group. A good example of array of
699text is i386-pc (kern/i386/pc/init.c and term/i386/pc/console.c).
700Of terminfo is ieee1275 (kern/ieee1275/init.c and term/ieee1275/console.c).
701Of video is loongson (kern/mips/loongson/init.c). Note that terminfo has
702to be inited in 2 stages: one before (to get at least rudimentary console
703as early as possible) and another after the heap (to get full-featured console).
704For the input there are string of keys, terminfo and direct hardware. For string
705of keys look at i386-pc (same files), for termino ieee1275 (same files) and for
706hardware loongson (kern/mips/loongson/init.c and term/at_keyboard.c).
707
708For the timer you'll need to call grub_install_get_time_ms (...) with as sole
709argument a function returning a grub_uint64_t of a number of milliseconds
710elapsed since arbitrary point in the past.
711
712Once these steps accomplished you can remove the inifinite loop and you should
713be able to get to the minimal console. Next step is to have module loading
714working. For this you'll need to fill kern/$cpu/dl.c and kern/$cpu/cache.S
715with real handling of relocations and respectively the real sync of I and D
716caches. Also you'll need to decide where in the image to store the modules.
717Usual way is to have it concatenated at the end. In this case you'll need to
718modify startup.S to copy modules out of bss to let's say ALIGN_UP (_end, 8)
719before cleaning out bss. You'll probably find useful to add total_module_size
720field to startup.S. In init.c you need to set grub_modbase to the address
721where modules can be found. You may need grub_modules_get_end () to avoid
722declaring the space occupied by modules as usable for heap. You can test modules
723with:
724
725@example
726./grub-mkimage -d grub-core -O $format_id -o test.img hello
727@end example
728
729and then running ``hello'' in the shell.
730
731Once this works, you should think of implementing disk access. Look around
732disk/ for examples.
733
734Then, very importantly, you probably need to implement the actual loader
735(examples available in loader/)
736
737Last step to have minimally usable port is to add support to grub-install to
738put GRUB in a place where firmware or platform will pick it up.
739
740Next steps are: filling datetime.c, setjmp.S, network (net/drivers),
741video (video/), halt (lib/), reboot (lib/).
742
743Please add your platform to Platform limitations and Supported kernels chapter
744in user documentation and mention any steps you skipped which result in reduced
745features or performance. Here is the quick checklist of features. Some of them
746are less important than others and skipping them is completely ok, just needs
747to be mentioned in user documentation.
748
749Checklist:
750@itemize
751@item Is heap big enough?
752@item Which charset is supported by console?
753@item Does platform have disk driver?
754@item Do you have network card support?
755@item Are you able to retrieve datetime (with date)?
756@item Are you able to set datetime (with date)?
757@item Is serial supported?
758@item Do you have direct disk support?
759@item Do you have direct keyboard support?
760@item Do you have USB support?
761@item Do you support loading through network?
762@item Do you support loading from disk?
763@item Do you support chainloading?
764@item Do you support network chainloading?
765@item Does cpuid command supports checking all
766CPU features that the user might want conditionalise on
767(64-bit mode, hypervisor,...)
768@item Do you support hints? How reliable are they?
769@item Does platform have ACPI? If so do ``acpi'' and ``lsacpi'' modules work?
770@item Do any of platform-specific operations mentioned in the relevant section of
771user manual makes sense on your platform?
772@item Does your platform support PCI? If so is there an appropriate driver for
773GRUB?
774@item Do you support badram?
775@end itemize
776
777@node Error Handling
778@chapter Error Handling
779
780Error handling in GRUB 2 is based on exception handling model. As C language
781doesn't directly support exceptions, exception handling behavior is emulated
782in software.
783
784When exception is raised, function must return to calling function. If calling
785function does not provide handling of the exception it must return back to its
786calling function and so on, until exception is handled. If exception is not
787handled before prompt is displayed, error message will be shown to user.
788
789Exception information is stored on @code{grub_errno} global variable. If
790@code{grub_errno} variable contains value @code{GRUB_ERR_NONE}, there is no active
791exception and application can continue normal processing. When @code{grub_errno} has
792other value, it is required that application code either handles this error or
793returns instantly to caller. If function is with return type @code{grub_err_t} is
794about to return @code{GRUB_ERR_NONE}, it should not set @code{grub_errno} to that
795value. Only set @code{grub_errno} in cases where there is error situation.
796
797Simple exception forwarder.
798@example
799grub_err_t
800forwarding_example (void)
801@{
802  /* Call function that might cause exception.  */
803  foobar ();
804
805  /* No special exception handler, just forward possible exceptions.  */
806  if (grub_errno != GRUB_ERR_NONE)
807    @{
808      return grub_errno;
809    @}
810
811  /* All is OK, do more processing.  */
812
813  /* Return OK signal, to caller.  */
814  return GRUB_ERR_NONE;
815@}
816@end example
817
818Error reporting has two components, the actual error code (of type
819@code{grub_err_t}) and textual message that will be displayed to user. List of
820valid error codes is listed in header file @file{include/grub/err.h}. Textual
821error message can contain any textual data. At time of writing, error message
822can contain up to 256 characters (including terminating NUL). To ease error
823reporting there is a helper function @code{grub_error} that allows easier
824formatting of error messages and should be used instead of writing directly to
825global variables.
826
827Example of error reporting.
828@example
829grub_err_t
830failing_example ()
831@{
832  return grub_error (GRUB_ERR_FILE_NOT_FOUND,
833                     "Failed to read %s, tried %d times.",
834                     "test.txt",
835                     10);
836@}
837@end example
838
839If there is a special reason that error code does not need to be taken account,
840@code{grub_errno} can be zeroed back to @code{GRUB_ERR_NONE}. In cases like this all
841previous error codes should have been handled correctly. This makes sure that
842there are no unhandled exceptions.
843
844Example of zeroing @code{grub_errno}.
845@example
846grub_err_t
847probe_example ()
848@{
849  /* Try to probe device type 1.  */
850  probe_for_device ();
851  if (grub_errno == GRUB_ERR_NONE)
852    @{
853      /* Device type 1 was found on system.  */
854      register_device ();
855      return GRUB_ERR_NONE;
856    @}
857  /* Zero out error code.  */
858  grub_errno = GRUB_ERR_NONE;
859
860  /* No device type 1 found, try to probe device type 2.  */
861  probe_for_device2 ();
862  if (grub_errno == GRUB_ERR_NONE)
863    @{
864      /* Device type 2 was found on system.  */
865      register_device2 ();
866      return GRUB_ERR_NONE;
867    @}
868  /* Zero out error code.  */
869  grub_errno = GRUB_ERR_NONE;
870
871  /* Return custom error message.  */
872  return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No device type 1 or 2 found.");
873@}
874@end example
875
876Some times there is a need to continue processing even if there is a error
877state in application. In situations like this, there is a needed to save old
878error state and then call other functions that might fail. To aid in this,
879there is a error stack implemented. Error state can be pushed to error stack
880by calling function @code{grub_error_push ()}. When processing has been completed,
881@code{grub_error_pop ()} can be used to pop error state from stack. Error stack
882contains predefined amount of error stack items. Error stack is protected for
883overflow and marks these situations so overflow error does not get unseen.
884If there is no space available to store error message, it is simply discarded
885and overflow will be marked as happened. When overflow happens, it most likely
886will corrupt error stack consistency as for pushed error there is no matching
887pop, but overflow message will be shown to inform user about the situation.
888Overflow message will be shown at time when prompt is about to be drawn.
889
890Example usage of error stack.
891@example
892/* Save possible old error message.  */
893grub_error_push ();
894
895/* Do your stuff here.  */
896call_possibly_failing_function ();
897
898if (grub_errno != GRUB_ERR_NONE)
899  @{
900    /* Inform rest of the code that there is error (grub_errno
901       is set). There is no pop here as we want both error states
902       to be displayed.  */
903    return;
904  @}
905
906/* Restore old error state by popping previous item from stack. */
907grub_error_pop ();
908@end example
909
910@node Stack and heap size
911@chapter Stack and heap size
912
913On emu stack and heap are just normal host OS stack and heap. Stack is typically
9148 MiB although it's OS-dependent.
915
916On i386-pc, i386-coreboot, i386-qemu and i386-multiboot the stack is 60KiB.
917All available space between 1MiB and 4GiB marks is part of heap.
918
919On *-xen stack is 4MiB. If compiled for x86-64 with GCC 4.4 or later adressable
920space is unlimited. When compiled for x86-64 with older GCC version adressable
921space is limited to 2GiB. When compiling for i386 adressable space is limited
922to 4GiB. All adressable pages except the ones for stack, GRUB binary, special
923pages and page table are in the heap.
924
925On *-efi GRUB uses same stack as EFI. If compiled for x86-64 with GCC 4.4 or
926later adressable space is unlimited. When compiled for x86-64 with older GCC
927version adressable space is limited to 2GiB. For all other platforms adressable
928space is limited to 4GiB. GRUB allocates pages from EFI for its heap, at most
9291.6 GiB.
930
931On i386-ieee1275 and powerpc-ieee1275 GRUB uses same stack as IEEE1275.
932It allocates at most 32MiB for its heap.
933
934On sparc64-ieee1275 stack is 256KiB and heap is 2MiB.
935
936On mips(el)-qemu_mips and mipsel-loongson stack is 2MiB (everything below
937GRUB image) and everything above GRUB image (from 2MiB + kernel size)
938until 256MiB is part of heap.
939
940On mips-arc stack is 2MiB (everything below GRUB image) and everything above
941GRUB image(from 2MiB + kernel size) until 128MiB is part of heap.
942
943On mipsel-arc stack is 2MiB (everything below GRUB image which is not part
944of ARC) and everything above GRUB image (from 7MiB + kernel size)
945until 256MiB is part of heap.
946
947On arm-uboot stack is 256KiB and heap is 2MiB.
948
949In short:
950
951@multitable @columnfractions .15 .25 .5
952@headitem Platform @tab Stack @tab Heap
953@item emu                     @tab 8 MiB   @tab ?
954@item i386-pc                 @tab 60 KiB  @tab < 4 GiB
955@item i386-coreboot           @tab 60 KiB  @tab < 4 GiB
956@item i386-multiboot          @tab 60 KiB  @tab < 4 GiB
957@item i386-qemu               @tab 60 KiB  @tab < 4 GiB
958@item *-efi                   @tab ?       @tab < 1.6 GiB
959@item i386-ieee1275           @tab ?       @tab < 32 MiB
960@item powerpc-ieee1275        @tab ?       @tab < 32 MiB
961@item sparc64-ieee1275        @tab 256KiB  @tab 2 MiB
962@item arm-uboot               @tab 256KiB  @tab 2 MiB
963@item mips(el)-qemu_mips      @tab 2MiB    @tab 253 MiB
964@item mipsel-loongson         @tab 2MiB    @tab 253 MiB
965@item mips-arc                @tab 2MiB    @tab 125 MiB
966@item mipsel-arc              @tab 2MiB    @tab 248 MiB
967@item x86_64-xen (GCC >= 4.4) @tab 4MiB    @tab unlimited
968@item x86_64-xen (GCC < 4.4)  @tab 4MiB    @tab < 2GiB
969@item i386-xen                @tab 4MiB    @tab < 4GiB
970@end multitable
971
972
973@node BIOS port memory map
974@chapter BIOS port memory map
975@c By Yoshinori K Okuji
976
977@multitable @columnfractions .15 .25 .5
978@headitem Start @tab End @tab Usage
979@item 0        @tab 0x1000 - 1   @tab BIOS and real mode interrupts
980@item 0x07BE   @tab 0x07FF       @tab Partition table passed to another boot loader
981@item ?        @tab 0x2000 - 1   @tab Real mode stack
982@item 0x7C00   @tab 0x7D00 - 1   @tab Boot sector
983@item 0x8000   @tab ?            @tab GRUB kernel
984@item 0x68000  @tab 0x71000 - 1  @tab Disk buffer
985@item ?        @tab 0x80000 - 1  @tab Protected mode stack
986@item ?        @tab 0xA0000 - 1  @tab Extended BIOS Data Area
987@item 0xA0000  @tab 0xC0000 - 1  @tab Video RAM
988@item 0xC0000  @tab 0x100000 - 1 @tab BIOS
989@item 0x100000 @tab ?            @tab Heap and module code
990@end multitable
991
992@node Video Subsystem
993@chapter Video Subsystem
994@c By VesaJääskeläinen
995This document contains specification for Video Subsystem for GRUB2.
996Currently only the usage interface is described in this document.
997Internal structure of how video drivers are registering and how video
998driver manager works are not included here.
999
1000@menu
1001* Video API::
1002* Example usage of Video API::
1003* Bitmap API::
1004@end menu
1005
1006@node Video API
1007@section Video API
1008
1009@subsection grub_video_setup
1010
1011@itemize
1012@item Prototype:
1013@example
1014grub_err_t
1015grub_video_setup (unsigned int width, unsigned int height, unsigned int mode_type);
1016@end example
1017@item Description:
1018
1019Driver 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}.
1020
1021This 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.
1022
1023@end itemize
1024
1025@subsection grub_video_restore
1026@itemize
1027@item Prototype:
1028
1029@example
1030grub_err_t
1031grub_video_restore (void);
1032@end example
1033@item Description:
1034
1035Video subsystem will deinitialize activated video driver to restore old state of video device. This can be used to switch back to text mode.
1036@end itemize
1037
1038@subsection grub_video_get_info
1039@itemize
1040@item Prototype:
1041
1042@example
1043grub_err_t
1044grub_video_get_info (struct grub_video_mode_info *mode_info);
1045@end example
1046@example
1047struct grub_video_mode_info
1048@{
1049  /* Width of the screen.  */
1050  unsigned int width;
1051  /* Height of the screen.  */
1052  unsigned int height;
1053  /* Mode type bitmask.  Contains information like is it Index color or
1054     RGB mode.  */
1055  unsigned int mode_type;
1056  /* Bits per pixel.  */
1057  unsigned int bpp;
1058  /* Bytes per pixel.  */
1059  unsigned int bytes_per_pixel;
1060  /* Pitch of one scanline.  How many bytes there are for scanline.  */
1061  unsigned int pitch;
1062  /* In index color mode, number of colors.  In RGB mode this is 256.  */
1063  unsigned int number_of_colors;
1064  /* Optimization hint how binary data is coded.  */
1065  enum grub_video_blit_format blit_format;
1066  /* How many bits are reserved for red color.  */
1067  unsigned int red_mask_size;
1068  /* What is location of red color bits.  In Index Color mode, this is 0.  */
1069  unsigned int red_field_pos;
1070  /* How many bits are reserved for green color.  */
1071  unsigned int green_mask_size;
1072  /* What is location of green color bits.  In Index Color mode, this is 0.  */
1073  unsigned int green_field_pos;
1074  /* How many bits are reserved for blue color.  */
1075  unsigned int blue_mask_size;
1076  /* What is location of blue color bits.  In Index Color mode, this is 0.  */
1077  unsigned int blue_field_pos;
1078  /* How many bits are reserved in color.  */
1079  unsigned int reserved_mask_size;
1080  /* What is location of reserved color bits.  In Index Color mode,
1081     this is 0.  */
1082  unsigned int reserved_field_pos;
1083@};
1084@end example
1085@item Description:
1086
1087Software 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.
1088@end itemize
1089
1090@subsection grub_video_get_blit_format
1091@itemize
1092@item Prototype:
1093
1094@example
1095enum grub_video_blit_format
1096grub_video_get_blit_format (struct grub_video_mode_info *mode_info);
1097@end example
1098@example
1099enum grub_video_blit_format
1100  @{
1101    /* Follow exactly field & mask information.  */
1102    GRUB_VIDEO_BLIT_FORMAT_RGBA,
1103    /* Make optimization assumption.  */
1104    GRUB_VIDEO_BLIT_FORMAT_R8G8B8A8,
1105    /* Follow exactly field & mask information.  */
1106    GRUB_VIDEO_BLIT_FORMAT_RGB,
1107    /* Make optimization assumption.  */
1108    GRUB_VIDEO_BLIT_FORMAT_R8G8B8,
1109    /* When needed, decode color or just use value as is.  */
1110    GRUB_VIDEO_BLIT_FORMAT_INDEXCOLOR
1111  @};
1112@end example
1113@item Description:
1114
1115Used 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.
1116@end itemize
1117
1118@subsection grub_video_set_palette
1119@itemize
1120@item Prototype:
1121
1122@example
1123grub_err_t
1124grub_video_set_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
1125@end example
1126@example
1127struct grub_video_palette_data
1128@{
1129    grub_uint8_t r; /* Red color value (0-255). */
1130    grub_uint8_t g; /* Green color value (0-255). */
1131    grub_uint8_t b; /* Blue color value (0-255). */
1132    grub_uint8_t a; /* Reserved bits value (0-255). */
1133@};
1134@end example
1135@item Description:
1136
1137Used 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.
1138@end itemize
1139
1140@subsection grub_video_get_palette
1141@itemize
1142@item Prototype:
1143
1144@example
1145grub_err_t
1146grub_video_get_palette (unsigned int start, unsigned int count, struct grub_video_palette_data *palette_data);
1147@end example
1148@example
1149struct grub_video_palette_data
1150@{
1151    grub_uint8_t r; /* Red color value (0-255). */
1152    grub_uint8_t g; /* Green color value (0-255). */
1153    grub_uint8_t b; /* Blue color value (0-255). */
1154    grub_uint8_t a; /* Reserved bits value (0-255). */
1155@};
1156@end example
1157@item Description:
1158
1159Used 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.
1160@end itemize
1161
1162@subsection grub_video_set_area_status
1163@itemize
1164
1165@item Prototype:
1166@example
1167grub_err_t
1168grub_video_set_area_status (grub_video_area_status_t area_status);
1169@end example
1170@example
1171enum grub_video_area_status_t
1172  @{
1173    GRUB_VIDEO_AREA_DISABLED,
1174    GRUB_VIDEO_AREA_ENABLED
1175  @};
1176@end example
1177
1178@item Description:
1179
1180Used to set area drawing mode for redrawing the specified region. Draw commands
1181are performed in the intersection of the viewport and the region called area.
1182Coordinates remain related to the viewport. If draw commands try to draw over
1183the area, they are clipped.
1184Set status to DISABLED if you need to draw everything.
1185Set status to ENABLED and region to the desired rectangle to redraw everything
1186inside the region leaving everything else intact.
1187Should be used for redrawing of active elements.
1188@end itemize
1189
1190@subsection grub_video_get_area_status
1191@itemize
1192
1193@item Prototype:
1194@example
1195grub_err_r
1196grub_video_get_area_status (grub_video_area_status_t *area_status);
1197@end example
1198
1199@item Description:
1200Used to query the area status.
1201@end itemize
1202
1203@subsection grub_video_set_viewport
1204@itemize
1205@item Prototype:
1206
1207@example
1208grub_err_t
1209grub_video_set_viewport (unsigned int x, unsigned int y, unsigned int width, unsigned int height);
1210@end example
1211@item Description:
1212
1213Used 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.
1214@end itemize
1215
1216@subsection grub_video_get_viewport
1217@itemize
1218@item Prototype:
1219
1220@example
1221grub_err_t
1222grub_video_get_viewport (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height);
1223@end example
1224@item Description:
1225
1226Used to query current viewport dimensions. Software developer can use this to choose best way to render contents of the viewport.
1227@end itemize
1228
1229@subsection grub_video_set_region
1230@itemize
1231@item Prototype:
1232
1233@example
1234grub_err_t
1235grub_video_set_region (unsigned int x, unsigned int y, unsigned int width, unsigned int height);
1236@end example
1237@item Description:
1238
1239Used to specify the region of the screen which should be redrawn. Use absolute
1240values. When the region is set and area status is ENABLE all draw commands will
1241be performed inside the interseption of region and viewport named area.
1242If draw commands try to draw over viewport, they are clipped. If developer
1243requests larger than possible region, width and height will be clamped to fit
1244screen. Should be used for redrawing of active elements.
1245@end itemize
1246
1247@subsection grub_video_get_region
1248@itemize
1249@item Prototype:
1250
1251@example
1252grub_err_t
1253grub_video_get_region (unsigned int *x, unsigned int *y, unsigned int *width, unsigned int *height);
1254@end example
1255@item Description:
1256
1257Used to query current region dimensions.
1258@end itemize
1259
1260@subsection grub_video_map_color
1261@itemize
1262@item Prototype:
1263
1264@example
1265grub_video_color_t
1266grub_video_map_color (grub_uint32_t color_name);
1267@end example
1268@item Description:
1269
1270Map 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.
1271@end itemize
1272
1273@subsection grub_video_map_rgb
1274@itemize
1275@item Prototype:
1276
1277@example
1278grub_video_color_t
1279grub_video_map_rgb (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue);
1280@end example
1281@item Description:
1282
1283Map 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.
1284@end itemize
1285
1286@subsection grub_video_map_rgba
1287@itemize
1288@item Prototype:
1289
1290@example
1291grub_video_color_t
1292grub_video_map_rgba (grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue, grub_uint8_t alpha);
1293@end example
1294@item Description:
1295
1296Map 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.
1297@end itemize
1298
1299@subsection grub_video_unmap_color
1300@itemize
1301@item Prototype:
1302
1303@example
1304grub_err_t
1305grub_video_unmap_color (grub_video_color_t color, grub_uint8_t *red, grub_uint8_t *green, grub_uint8_t *blue, grub_uint8_t *alpha);
1306@end example
1307@item Description:
1308
1309Unmap 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).
1310@end itemize
1311
1312@subsection grub_video_fill_rect
1313@itemize
1314@item Prototype:
1315
1316@example
1317grub_err_t
1318grub_video_fill_rect (grub_video_color_t color, int x, int y, unsigned int width, unsigned int height);
1319@end example
1320@item Description:
1321
1322Fill 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.
1323
1324Software 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.
1325@end itemize
1326
1327@subsection grub_video_blit_glyph
1328@itemize
1329@item Prototype:
1330
1331@example
1332grub_err_t
1333grub_video_blit_glyph (struct grub_font_glyph *glyph, grub_video_color_t color, int x, int y);
1334@end example
1335@example
1336struct grub_font_glyph @{
1337    /* TBD. */
1338@};
1339@end example
1340@item Description:
1341
1342Used 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.
1343@end itemize
1344
1345@subsection grub_video_blit_bitmap
1346@itemize
1347@item Prototype:
1348
1349@example
1350grub_err_t
1351grub_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);
1352@end example
1353@example
1354struct grub_video_bitmap
1355@{
1356    /* TBD. */
1357@};
1358
1359enum grub_video_blit_operators
1360  @{
1361    GRUB_VIDEO_BLIT_REPLACE,
1362    GRUB_VIDEO_BLIT_BLEND
1363  @};
1364@end example
1365@item Description:
1366
1367Used 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.
1368
1369Software developer should use @code{grub_video_bitmap_create} or @code{grub_video_bitmap_load} to create or load bitmap data.
1370@end itemize
1371
1372@subsection grub_video_blit_render_target
1373@itemize
1374@item Prototype:
1375
1376@example
1377grub_err_t
1378grub_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);
1379@end example
1380@example
1381struct grub_video_render_target @{
1382    /* This is private data for video driver. Should not be accessed from elsewhere directly.  */
1383@};
1384
1385enum grub_video_blit_operators
1386  @{
1387    GRUB_VIDEO_BLIT_REPLACE,
1388    GRUB_VIDEO_BLIT_BLEND
1389  @};
1390@end example
1391@item Description:
1392
1393Used 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.
1394@end itemize
1395
1396@subsection grub_video_scroll
1397@itemize
1398@item Prototype:
1399
1400@example
1401grub_err_t
1402grub_video_scroll (grub_video_color_t color, int dx, int dy);
1403@end example
1404@item Description:
1405
1406Used 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.
1407@end itemize
1408
1409@subsection grub_video_swap_buffers
1410@itemize
1411@item Prototype:
1412
1413@example
1414grub_err_t
1415grub_video_swap_buffers (void);
1416@end example
1417@item Description:
1418
1419If 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.
1420@end itemize
1421
1422@subsection grub_video_create_render_target
1423@itemize
1424@item Prototype:
1425
1426@example
1427grub_err_t
1428grub_video_create_render_target (struct grub_video_render_target **result, unsigned int width, unsigned int height, unsigned int mode_type);
1429@end example
1430@example
1431struct grub_video_render_target @{
1432    /* This is private data for video driver. Should not be accessed from elsewhere directly.  */
1433@};
1434@end example
1435@item Description:
1436
1437Driver 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.
1438@end itemize
1439
1440@subsection grub_video_delete_render_target
1441@itemize
1442@item Prototype:
1443
1444@example
1445grub_err_t
1446grub_video_delete_render_target (struct grub_video_render_target *target);
1447@end example
1448@item Description:
1449
1450Used 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.
1451@end itemize
1452
1453@subsection grub_video_set_active_render_target
1454@itemize
1455@item Prototype:
1456
1457@example
1458grub_err_t
1459grub_video_set_active_render_target (struct grub_video_render_target *target);
1460@end example
1461@item Description:
1462
1463Sets 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.
1464
1465@end itemize
1466@subsection grub_video_get_active_render_target
1467@itemize
1468@item Prototype:
1469
1470@example
1471grub_err_t
1472grub_video_get_active_render_target (struct grub_video_render_target **target);
1473@end example
1474@item Description:
1475
1476Returns currently active render target. It returns value in @code{target} that can be subsequently issued back to @code{grub_video_set_active_render_target}.
1477@end itemize
1478
1479@node Example usage of Video API
1480@section Example usage of Video API
1481@subsection Example of screen setup
1482@example
1483grub_err_t rc;
1484/* Try to initialize video mode 1024 x 768 with direct RGB.  */
1485rc = grub_video_setup (1024, 768, GRUB_VIDEO_MODE_TYPE_RGB);
1486if (rc != GRUB_ERR_NONE)
1487@{
1488  /* Fall back to standard VGA Index Color mode.  */
1489  rc = grub_video_setup (640, 480, GRUB_VIDEO_MODE_TYPE_INDEX);
1490  if (rc != GRUB_ERR_NONE)
1491  @{
1492  /* Handle error.  */
1493  @}
1494@}
1495@end example
1496@subsection Example of setting up console viewport
1497@example
1498grub_uint32_t x, y, width, height;
1499grub_video_color_t color;
1500struct grub_font_glyph glyph;
1501grub_err_t rc;
1502/* Query existing viewport.  */
1503grub_video_get_viewport (&x, &y, &width, &height);
1504/* Fill background.  */
1505color = grub_video_map_color (GRUB_COLOR_BACKGROUND);
1506grub_video_fill_rect (color, 0, 0, width, height);
1507/* Setup console viewport.  */
1508grub_video_set_viewport (x + 10, y + 10, width - 20, height - 20);
1509grub_video_get_viewport (&x, &y, &width, &height);
1510color = grub_video_map_color (GRUB_COLOR_CONSOLE_BACKGROUND);
1511grub_video_fill_rect (color, 0, 0, width, height);
1512/* Draw text to viewport.  */
1513color = grub_video_map_color (GRUB_COLOR_CONSOLE_TEXT);
1514grub_font_get_glyph ('X', &glyph);
1515grub_video_blit_glyph (&glyph, color, 0, 0);
1516@end example
1517
1518@node Bitmap API
1519@section Bitmap API
1520@subsection grub_video_bitmap_create
1521@itemize
1522@item Prototype:
1523@example
1524grub_err_t grub_video_bitmap_create (struct grub_video_bitmap **bitmap, unsigned int width, unsigned int height, enum grub_video_blit_format blit_format)
1525@end example
1526
1527@item Description:
1528
1529Creates 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.
1530@end itemize
1531
1532@subsection grub_video_bitmap_destroy
1533@itemize
1534@item Prototype:
1535@example
1536grub_err_t grub_video_bitmap_destroy (struct grub_video_bitmap *bitmap);
1537@end example
1538
1539@item Description:
1540
1541When 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}.
1542@end itemize
1543
1544@subsection grub_video_bitmap_load
1545@itemize
1546@item Prototype:
1547@example
1548grub_err_t grub_video_bitmap_load (struct grub_video_bitmap **bitmap, const char *filename);
1549@end example
1550
1551@item Description:
1552
1553Tries 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.
1554@end itemize
1555
1556@subsection grub_video_bitmap_get_width
1557@itemize
1558@item Prototype:
1559@example
1560unsigned int grub_video_bitmap_get_width (struct grub_video_bitmap *bitmap);
1561@end example
1562
1563@item Description:
1564
1565Returns bitmap width.
1566@end itemize
1567
1568@subsection grub_video_bitmap_get_height
1569@itemize
1570@item Prototype:
1571@example
1572unsigned int grub_video_bitmap_get_height (struct grub_video_bitmap *bitmap);
1573@end example
1574
1575@item Description:
1576
1577Return bitmap height.
1578@end itemize
1579
1580@subsection grub_video_bitmap_get_mode_info
1581@itemize
1582@item Prototype:
1583@example
1584void grub_video_bitmap_get_mode_info (struct grub_video_bitmap *bitmap, struct grub_video_mode_info *mode_info);
1585@end example
1586
1587@item Description:
1588
1589Returns bitmap format details in form of @code{grub_video_mode_info}.
1590@end itemize
1591
1592@subsection grub_video_bitmap_get_data
1593@itemize
1594@item Prototype:
1595@example
1596void *grub_video_bitmap_get_data (struct grub_video_bitmap *bitmap);
1597@end example
1598
1599@item Description:
1600
1601Return 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.
1602@end itemize
1603
1604@node PFF2 Font File Format
1605@chapter PFF2 Font File Format
1606
1607@c Author: Colin D. Bennett <colin@gibibit.com>
1608@c Date: 8 January 2009
1609
1610@menu
1611* Introduction::
1612* File Structure::
1613* Font Metrics::
1614@end menu
1615
1616
1617@node Introduction
1618@section Introduction
1619
1620The goal of this format is to provide a bitmap font format that is simple to
1621use, compact, and cleanly supports Unicode.
1622
1623
1624@subsection Goals of the GRUB Font Format
1625
1626@itemize
1627@item Simple to read and use.
1628Since GRUB will only be reading the font files,
1629we are more concerned with making the code to read the font simple than we
1630are with writing the font.
1631
1632@item Compact storage.
1633The fonts will generally be stored in a small boot
1634partition where GRUB is located, and this may be on a removable storage
1635device such as a CD or USB flash drive where space is more limited than it
1636is on most hard drives.
1637
1638@item Unicode.
1639GRUB should not have to deal with multiple character
1640encodings.  The font should always use Unicode character codes for simple
1641internationalization.
1642@end itemize
1643
1644@subsection Why Another Font Format?
1645
1646There are many existing bitmap font formats that GRUB could use.  However,
1647there are aspects of these formats that may make them less than suitable for
1648use in GRUB at this time:
1649
1650@table @samp
1651@item BDF
1652Inefficient storage; uses ASCII to describe properties and
1653hexadecimal numbers in ASCII for the bitmap rows.
1654@item PCF 
1655Many format variations such as byte order and bitmap padding (rows
1656padded to byte, word, etc.) would result in more complex code to
1657handle the font format.
1658@end table
1659
1660@node File Structure
1661@section File Structure
1662
1663A file @strong{section} consists of a 4-byte name, a 32-bit big-endian length (not
1664including the name or length), and then @var{length} more section-type-specific
1665bytes.
1666
1667The standard file extension for PFF2 font files is @file{.pf2}.
1668
1669
1670@subsection Section Types
1671
1672@table @samp
1673@item FILE
1674@strong{File type ID} (ASCII string).  This must be the first section in the file.  It has length 4
1675and the contents are the four bytes of the ASCII string @samp{PFF2}.
1676
1677@item NAME
1678@strong{Font name} (ASCII string).  This is the full font name including family,
1679weight, style, and point size.  For instance, "Helvetica Bold Italic 14".
1680
1681@item FAMI
1682@strong{Font family name} (ASCII string).  For instance, "Helvetica".  This should
1683be included so that intelligent font substitution can take place.
1684
1685@item WEIG
1686@strong{Font weight} (ASCII string).  Valid values are @samp{bold} and @samp{normal}.
1687This should be included so that intelligent font substitution can take
1688place.
1689
1690@item SLAN
1691@strong{Font slant} (ASCII string).  Valid values are @samp{italic} and @samp{normal}.
1692This should be included so that intelligent font substitution can take
1693place.
1694
1695@item PTSZ
1696@strong{Font point size} (uint16be).
1697
1698@item MAXW
1699@strong{Maximum character width in pixels} (uint16be).
1700
1701@item MAXH
1702@strong{Maximum character height in pixels} (uint16be).
1703
1704@item ASCE
1705@strong{Ascent in pixels} (uint16be).  @xref{Font Metrics}, for details.
1706
1707@item DESC
1708@strong{Descent in pixels} (uint16be).  @xref{Font Metrics}, for details.
1709
1710@item CHIX
1711@strong{Character index.}
1712The character index begins with a 32-bit big-endian unsigned integer
1713indicating the total size of the section, not including this size value.
1714For each character, there is an instance of the following entry structure:
1715
1716@itemize
1717@item @strong{Unicode code point.} (32-bit big-endian integer.)
1718
1719@item @strong{Storage flags.} (byte.)
1720       
1721@itemize
1722@item Bits 2..0:
1723
1724If equal to 000 binary, then the character data is stored
1725uncompressed beginning at the offset indicated by the character's
1726@strong{offset} value.
1727
1728If equal to 001 binary, then the character data is stored within a
1729compressed character definition block that begins at the offset
1730within the file indicated by the character's @strong{offset} value.
1731@end itemize
1732
1733@item @strong{Offset.} (32-bit big-endian integer.)
1734
1735A marker that indicates the remainder of the file is data accessed via
1736the character index (CHIX) section.  When reading this font file, the rest
1737of the file can be ignored when scanning the sections.  The length should
1738be set to -1 (0xFFFFFFFF).
1739
1740Supported data structures:
1741
1742Character definition
1743Each character definition consists of:
1744
1745@itemize
1746@item @strong{Width.}
1747Width of the bitmap in pixels.  The bitmap's extents
1748represent the glyph's bounding box.  @code{uint16be}.
1749
1750@item @strong{Height.}
1751Height of the bitmap in pixels.  The bitmap's extents
1752represent the glyph's bounding box.  @code{uint16be}.
1753
1754@item @strong{X offset.}
1755The number of pixels to shift the bitmap by
1756horizontally before drawing the character. @code{int16be}.
1757
1758@item @strong{Y offset.}
1759The number of pixels to shift the bitmap by
1760vertically before drawing the character. @code{int16be}.
1761
1762@item @strong{Device width.}
1763The number of pixels to advance horizontally from
1764this character's origin to the origin of the next character.
1765@code{int16be}.
1766
1767@item @strong{Bitmap data.}
1768This is encoded as a string of bits.  It is
1769organized as a row-major, top-down, left-to-right bitmap.  The most
1770significant bit of each byte is taken to be the leftmost or uppermost
1771bit in the byte.  For the sake of compact storage, rows are not padded
1772to byte boundaries (i.e., a single byte may contain bits belonging to
1773multiple rows).  The last byte of the bitmap @strong{is} padded with zero
1774bits in the bits positions to the right of the last used bit if the
1775bitmap data does not fill the last byte. 
1776         
1777The length of the @strong{bitmap data} field is (@var{width} * @var{height} + 7) / 8
1778using integer arithmetic, which is equivalent to ceil(@var{width} *
1779@var{height} / 8) using real number arithmetic.
1780
1781It remains to be determined whether bitmap fonts usually make all
1782glyph bitmaps the same height, or if smaller glyphs are stored with
1783bitmaps having a lesser height.  In the latter case, the baseline
1784would have to be used to calculate the location the bitmap should be
1785anchored at on screen.
1786@end itemize
1787
1788@end itemize
1789@end table
1790
1791@node Font Metrics
1792@section Font Metrics
1793
1794@itemize
1795@item Ascent.
1796The distance from the baseline to the top of most characters.
1797Note that in some cases characters may extend above the ascent.
1798
1799@item Descent.
1800The distance from the baseline to the bottom of most characters.  Note that
1801in some cases characters may extend below the descent.
1802 
1803@item Leading.
1804The amount of space, in pixels, to leave between the descent of one line of
1805text and the ascent of the next line.  This metrics is not specified in the
1806current file format; instead, the font rendering engine calculates a
1807reasonable leading value based on the other font metrics.
1808
1809@item Horizonal leading.
1810The amount of space, in pixels, to leave horizontally between the left and
1811right edges of two adjacent glyphs.  The @strong{device width} field determines
1812the effective leading value that is used to render the font.
1813
1814@end itemize
1815@ifnottex
1816@image{font_char_metrics,,,,.png}
1817@end ifnottex
1818   
1819An illustration of how the various font metrics apply to characters.
1820
1821
1822
1823@node Graphical Menu Software Design
1824@chapter Graphical Menu Software Design
1825
1826@c By Colin D. Bennett <colin@gibibit.com>
1827@c Date: 17 August 2008
1828
1829@menu
1830* Introduction_2::
1831* Startup Sequence::
1832* GUI Components::
1833* Command Line Window::
1834@end menu
1835
1836@node Introduction_2
1837@section Introduction
1838
1839The @samp{gfxmenu} module provides a graphical menu interface for GRUB 2.  It
1840functions as an alternative to the menu interface provided by the @samp{normal}
1841module, which uses the grub terminal interface to display a menu on a
1842character-oriented terminal.
1843
1844The graphical menu uses the GRUB video API, which is currently for the VESA
1845BIOS extensions (VBE) 2.0+.  This is supported on the i386-pc platform.
1846However, the graphical menu itself does not depend on using VBE, so if another
1847GRUB video driver were implemented, the @samp{gfxmenu} graphical menu would work
1848on the new video driver as well.
1849
1850
1851@node Startup Sequence
1852@section Startup Sequence
1853
1854@itemize
1855@item grub_enter_normal_mode [normal/main.c]
1856@item grub_normal_execute [normal/main.c]
1857@item read_config_file [normal/main.c]
1858@item (When @file{gfxmenu.mod} is loaded with @command{insmod}, it will call @code{grub_menu_viewer_register()} to register itself.)
1859@item GRUB_MOD_INIT (gfxmenu) [gfxmenu/gfxmenu.c]
1860@item grub_menu_viewer_register [kern/menu_viewer.c]
1861@item grub_menu_viewer_show_menu [kern/menu_viewer.c]
1862@item get_current_menu_viewer() [kern/menu_viewer.c]
1863@item show_menu() [gfxmenu/gfxmenu.c]
1864@item grub_gfxmenu_model_new [gfxmenu/model.c]
1865@item grub_gfxmenu_view_new [gfxmenu/view.c]
1866@item set_graphics_mode [gfxmenu/view.c]
1867@item grub_gfxmenu_view_load_theme [gfxmenu/theme_loader.c]
1868@end itemize
1869
1870
1871@node GUI Components
1872@section GUI Components
1873
1874The graphical menu implements a GUI component system that supports a
1875container-based layout system.  Components can be added to containers, and
1876containers (which are a type of component) can then be added to other
1877containers, to form a tree of components.  Currently, the root component of
1878this tree is a @samp{canvas} component, which allows manual layout of its child
1879components.
1880
1881Components (non-container):
1882
1883@itemize
1884@item label
1885@item image
1886@item progress_bar
1887@item circular_progress
1888@item list (currently hard coded to be a boot menu list)
1889@end itemize
1890
1891Containers:
1892
1893@itemize
1894@item canvas
1895@item hbox
1896@item vbox
1897@end itemize
1898
1899The GUI component instances are created by the theme loader in
1900@file{gfxmenu/theme_loader.c} when a theme is loaded.  Theme files specify
1901statements such as @samp{+vbox@{ +label @{ text="Hello" @} +label@{ text="World" @} @}}
1902to add components to the component tree root.  By nesting the component
1903creation statements in the theme file, the instantiated components are nested
1904the same way.
1905
1906When a component is added to a container, that new child is considered @strong{owned}
1907by the container.  Great care should be taken if the caller retains a
1908reference to the child component, since it will be destroyed if its parent
1909container is destroyed.  A better choice instead of storing a pointer to the
1910child component is to use the component ID to find the desired component.
1911Component IDs do not have to be unique (it is often useful to have multiple
1912components with an ID of "__timeout__", for instance).
1913
1914In order to access and use components in the component tree, there are two
1915functions (defined in @file{gfxmenu/gui_util.c}) that are particularly useful:
1916
1917@itemize
1918
1919@item @code{grub_gui_find_by_id (root, id, callback, userdata)}:
1920
1921This function ecursively traverses the component tree rooted at @var{root}, and
1922for every component that has an ID equal to @var{id}, calls the function pointed
1923to by @var{callback} with the matching component and the void pointer @var{userdata}
1924as arguments.  The callback function can do whatever is desired to use the
1925component passed in.
1926
1927@item @code{grub_gui_iterate_recursively (root, callback, userdata)}:
1928
1929This function calls the function pointed to by @var{callback} for every
1930component that is a descendant of @var{root} in the component tree.  When the
1931callback function is called, the component and the void pointer @var{userdata}
1932as arguments.  The callback function can do whatever is desired to use the
1933component passed in.
1934@end itemize
1935
1936@node Command Line Window
1937@section Command Line Window
1938
1939The terminal window used to provide command line access within the graphical
1940menu is managed by @file{gfxmenu/view.c}.  The @samp{gfxterm} terminal is used, and
1941it has been modified to allow rendering to an offscreen render target to allow
1942it to be composed into the double buffering system that the graphical menu
1943view uses.  This is bad for performance, however, so it would probably be a
1944good idea to make it possible to temporarily disable double buffering as long
1945as the terminal window is visible.  There are still unresolved problems that
1946occur when commands are executed from the terminal window that change the
1947graphics mode.  It's possible that making @code{grub_video_restore()} return to
1948the graphics mode that was in use before @code{grub_video_setup()} was called
1949might fix some of the problems.
1950
1951
1952@node Copying This Manual
1953@appendix Copying This Manual
1954
1955@menu
1956* GNU Free Documentation License::  License for copying this manual.
1957@end menu
1958
1959@include fdl.texi
1960
1961
1962@node Index
1963@unnumbered Index
1964
1965@c Currently, we use only the Concept Index.
1966@printindex cp
1967
1968@bye
Note: See TracBrowser for help on using the repository browser.