#ifdef switch per kernel config options in definition of device driver
structure in header files could be problematic.
See my post in port-zaurus@ for details:
https://mail-index.netbsd.org/port-zaurus/2019/10/31/msg000079.html
Should be pulled up to netbsd-8 and netbsd-9.
- Introduce and use proper macros.
- Use not ambiguous variable names.
- Unify similar functions as possible as I can.
- G/C unused headers.
- Use #include <dev/rasops/foo.h> instead of "foo.h"
No particular functional changes intended.
Currently,
- offset of underline is fixed to 1-row from bottom of characters, and
- height of underline is fixed to 1.
Both are good for standard 8x16 fonts. However, it is too thin for
larger fonts, especially when used on display of high resolution.
Also, 1-row offset of underline is ugly for small fonts, e.g.,
spleen5x8.
Therefore, adjust offset and height as,
- no changes for standard 16-height fonts.
- scaling by font height for larger fonts.
- set offset to zero for fonts of height smaller than 16.
- remove ri_buf and friends.
- remove ri_stamp and frieds.
- introduce ri_ul, which will be used for scaling underline with font.
Also add hack for ri_ul; adjust its size to obsoleted member, ri_delta,
which was only used rasops routines internally. Now, size and offsets of
all members of struct rasops_info become same with netbsd-9, -8, and -7,
again. So we can safelly pull up fixes to any release branches!
rasops.h, it is not safe to use kmem_alloc(9) in rasops_init();
rasops routines can be used for early putchar, which means that
UVM is not fully initialized.
Should fix a problem reported by macallan:
http://mail-index.netbsd.org/tech-kern/2019/08/02/msg025327.html
Instead of using ri_buf, inline function rasops_memcpy32() is
introduced to fill 32bit data efficiently.
Instead of using ri_stamp (per device stamp), stamp_ri is
introduced to distinguish for which device stamp is calculated.
- Use static masks similar to that used in rasops_bitops.h,
rather than generating them on the fly.
- Use pointer for proper type to avoid unnecessary casts.
- When centering screen, locate effective base address of framebuffer to
both word and 24-bit color boundary.
- Consistently convert ri_devcmap to ``big endian'' if not RI_BSWAP.
Also, fix possible bug for 15/16-bpp with RI_BSWAP (not tested).
only when font width is 12.
We need to use different devcmap for that case, if we wish to share
codes for other depths/font widths as possible as we can.
XXX
What should we do for big endian? I have no big endian machines with
24bpp framebuffer...
rin