Re: [PATCH] Font antialiasing v2
On Fri, 2010-04-02 at 22:23 +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > - for (j = font_info->ranges[i * 2]; j <= font_info->ranges[i * 2 + 1]; > - j++) > - add_char (font_info, face, j); > + for (j = font_info->ranges[i * 2]; j <= font_info->ranges[i * 2 + > 1]; j++) > + add_char (font_info, face, j); > > Can you fix the style of your patch to avoid hunks like these? (Hint: > GNU indent) Most of sources related to font functionality contains awful mix of spaces and tabs. Should I fix this? Strictly use spaces everywhere? > - glyph_bitmap.mode_info.blit_format = GRUB_VIDEO_BLIT_FORMAT_1BIT_PACKED; > - glyph_bitmap.mode_info.bpp = 1; > - > - /* Really 1 bit per pixel. */ > - glyph_bitmap.mode_info.bytes_per_pixel = 0; > - > These bits need to be filled even if blit_format is set OK. > +#define FONT_FORMAT_STORAGE_PACK_MASK 0x0F > +#define FONT_FORMAT_STORAGE_PACKED 1 > +#define FONT_FORMAT_STORAGE_DEPTH_MASK 0xF0 > +#define FONT_FORMAT_STORAGE_1BIT 0 > +#define FONT_FORMAT_STORAGE_8BIT_GRAY 32 > Using entire byte for this is quite a waste. It's better to use 2 or 3 last > bit as STORAGE_FORMAT This byte is already wasted with packed/unpacked bit. 3 bits actually, others as reserved. And I used reserved ones. See http://grub.gibibit.com/New_font_format (PFF2 spec, CHIX, item 2). > Also I doubt usefulness of a font in which only some glyphs are anti-aliased. > Perhaps we could move antialiasing flags to file header and shave off few > bytes? Yes this makes sense. I.e. substitution glyph for unknown symbol have no AA. Also frames and other geometry can benefit from this. Anyway this byte is already wasted in original spec. Moreover I thinking about transparent gz or xz reader for font file. This will drastically reduce the size. > Another point is that although storage_flags are present since some time > trying to use antialised fonts in older grub will result in garbage. I prefer > to put PFF3 signature if any flag is used. It will also allow more freedom it > fields specification, Well, generally I agree. This will be more evident in case of troubles. > + fgcolor = grub_video_fb_map_rgba (src->mode_info->fg_red, > + src->mode_info->fg_green, > + src->mode_info->fg_blue, > + src->mode_info->fg_alpha); > background color isn't handled correctly (it's not always transparent) > + grub_uint8_t fa, a; Actually it always 0x. See grub_font_draw_glyph: there is only FG color in declaration. Moreover I don't think that bg color is useful because we handle alpha channel correctly for fg and mask itself, so anyone can blit glyph onto everything he want. Also filling rectangle with color below text and then rendering only fg mask will be way more fast. But if you insist we should fix grub_font_draw_glyph and all it's callers at first place. How exactly? > Please avoid mixing declarations and code OK. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot2 Suggestions
>>> 8) Any RAM that is not immediately usable by the OS should not be >>> reported as "usable RAM" in the memory map. An example of this is the >>> "ACPI reclaimable" area (which is RAM that isn't usable until the OS >>> has finished using the ACPI tables). RAM used to store the multi-boot >>> information, RAM used to store the "kernel" and RAM used to store any >>> modules should be treated in the same way. I suggest using "area type >>> 0xFFFE = RAM used for multi-boot information" and "area type >>> 0xFFFD = RAM used for kernel/modules". This makes it much easier >>> to write a kernel's early initialisation code, because it can use RAM >>> without worrying about trashing data that is needed by the kernel/OS >>> later. >>> >> kernel should know itself what it asked bootloader to do. MBI now is a >> single chunk. Further than that there are only elf section tag and >> module tags which refer to external memory. I think it should be easily >> trackable now. > > Unfortunately a lot of OSs are written by C programmers who do the > absolute minimum to setup paging in a small piece of startup code > written in assembly, before jumping to their "main()". This means they > allocate RAM for page tables, etc before they've parsed or checked > anything; usually by searching the memory map for the first "usable" > area and using the first pages of that area. > > Unfortunately I'm often the person that needs to explain to them that > "usable" doesn't mean usable; and that their code only works by > accident (and their initialisation code could overwrite things needed > by the OS later if it's booted by a different multi-boot compliant > boot loader; including future versions of GRUB and not excluding > non-GRUB boot loaders); and that the only memory they can safely use > before determining what is usable and what isn't is the space in their > ".bss", which usually happens to be linked to a virtual address (e.g. > above 0xC) and not the address it's actually loaded at.The > other alternative is for the initialisation code to copy everything > from the "usable" areas into their ".bss" so that they can assume that > "usable" means usable (but there's no maximum size for the multi-boot > information and no way to know how big "big enough" is, and this won't > work if there's any extra modules). > > Basically, regardless of how the OS handles the problem, the "small > piece of startup code written in assembly" ends up being an ugly mess. > > If multi-boot guaranteed that "usable" actually did mean usable then > the problem goes away. Alternatively you could rename it, so that > "type 1 = potentially usable maybe" so that beginners realise they're > screwed before they write their dodgy code... ;-) This does sound like there ought to be different codes for "usable - unused" vs "usable - valid". I think the original objection may have been to enumerating all the different kinds of "usable - valid" regions which could snowball into a very large number of IDs. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot2 Suggestions
This thread has the right name so I'll just reply here. 0) It should be specified in Multiboot 2 that Multiboot 1 can optionally be supported by boot loaders when a different magic number is used. 1) The boot loader should calibrate timers that need this. I don't know about other architectures, but in x86(-64) systems, these are the RDTSC and the LAPIC. Needless to say, this must also be done when such hardware is present. 2) I've seen this proposed before and turned down but it's my list of suggestions and I'm free to repeat it :) A language tag passed by the boot loader would be nice - that way Multiboot-compliant boot loaders could have a simple menu to select the language for any of the operating systems installed. It would make it easier for the user, who otherwise needs to know what to pass to cmdline. 3) On x86-64 systems, the boot loader should be able to boot in long mode. I remember talking to Vladimir on IRC about paging and he said he prefered to always have the simplest form of paging initialized by the boot loader -- disabled in the case of protected mode and identity-mapped in the case of long mode. I think that is fair. Regards, Bogdan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot2 Suggestions
Hi, 2010/4/3 Vladimir 'φ-coder/phcoder' Serbinenko : > Brendan Trotter wrote: >> 1) If GRUB was using a serial port as a console device (e.g. on a >> headless system) it'd be nice if the OS could continue using the same >> serial port with the same configuration instead of resetting the >> serial port, etc. A new tag (for 80x86, "8250/6550 compatible" serial >> ports) would include base I/O port, the serial line configuration >> (e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600), >> > The kernel can read data bits, stop bits, parity and divisor from > registers itself. I think it's more useful to supply a base frequency > since there are a lot of "almost compatible" cards which differ only in > base frequency. You're right. >> the IRQ number (if known/used by the boot loader) and the protocol >> being used (ASCII, VT100, etc). > I think it's more useful to supply directly usable strings termcap > strings rather than an abstract ID Here's an example termcap string: ca|concept100|c100|concept|c104|concept100-4p|HDS Concept-100:\ :al=3*\E^R:am:bl=^G:cd=16*\E^C:ce=16\E^U:cl=2*^L:cm=\Ea%+ %+ :\ :co#80:.cr=9^M:db:dc=16\E^A:dl=3*\E^B:do=^J:ei=\E\200:eo:im=\E^P:in:\ :ip=16*:is=\EU\Ef\E7\E5\E8\El\ENH\EK\E\200\Eo&\200\Eo\47\E:k1=\E5:\ :k2=\E6:k3=\E7:kb=^h:kd=\E<:ke=\Ex:kh=\E?:kl=\E>:kr=\E=:ks=\EX:\ :ku=\E;:le=^H:li#24:mb=\EC:me=\EN\200:mh=\EE:mi:mk=\EH:mp=\EI:\ :mr=\ED:nd=\E=:pb#9600:rp=0.2*\Er%.%+ :se=\Ed\Ee:sf=^J:so=\EE\ED:\ :.ta=8\t:te=\Ev\200\200\200\200\200\200\Ep\r\n:\ :ti=\EU\Ev 8p\Ep\r:ue=\Eg:ul:up=\E;:us=\EG:\ :vb=\Ek\200\200\200\200\200\200\200\200\200\200\200\200\200\200\EK:\ :ve=\Ew:vs=\EW:vt#8:xn:\ :bs:cr=^M:dC#9:dT#8:nl=^J:ta=^I:pt: Making sense out of arbitrary termcap strings isn't easy - it would add a large amount of mess to early OS initialisation code (which typically doesn't even have C library functions to rely on). A single integer saying "which protocol" is much easier to parse and use, especially as only a few standard protocols (e.g. VT100) would need to be supported. >> If the boot loader doesn't know which >> IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ >> number to 0x. >> >> Where the serial port has a different interface >> (e.g. if the serial port uses MMIO or if it's not "8250/6550 >> compatible") a different tag with different fields are used to >> describe it. > I think it's more useful to have an I/O selector since yeeloong serial > interface is basically the same, just attached differently An I/O selector (for "8250/6550 compatible") makes sense, and different tags for "not 8250/6550 compatible" serial ports. > I think we need following fields: > 1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O) For 32-bit MMIO you could use 64-bit MMIO with the high bits of the "address in I/O space" set to zero. > 2) IRQ type selector (0 = None, 1 = standard platform interrupt) > 3) 16-bit padding > 4) address in I/O space (up to 64-bits) > 5) Base frequency in Hz (32-bit) > 6) IRQ (32-bit or even 64-bit since it's not excluded some platforms would > use 64-bit IRQ ids, though I'm not aware of such). Looks good to me. >> "telnet+ethernet" > It would need network tag first Just an example of a different tag for a different type of console device. >> 2) The "OS image format" information should be expanded, so that the >> OS can tell the boot loader if it supports "8250/6550 compatible" >> serial ports (and which protocols), and any other console devices (for >> the same reason the "OS image format" already has flags, etc for >> video). >> > Console flags tag is for this Yes - the console flags tag needs to be expanded... >> 3) There should be an (optional?) "critical error notification method" >> tag that tells the OS which method/s it can/should use to tell the >> user it encountered a problem before it was able to setup it's console >> output. For example, can/should the OS return to the boot loader, or >> use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or >> something else. >> > Processing such a selector may prove as difficult as setting up a > console based on console tags. So I doubt its usefullness I currently use "PC speaker" as my "critical error notification method" - it's about 15 instructions that use I/O ports only and doesn't require memory allocations or anything else. I doubt setting keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on anything more than I/O ports. In comparison, my video setup code is around 64 KiB of code that starts with trying to get EDID information from the monitor, filtering a list of video modes (from VGA and/or VBE), allocating several MiB of RAM for video buffers and font data, scaling font data, etc. If there's a problem setting up the memory management it's all useless and I
