vesafb - Generic graphic framebuffer driver

부팅 시 BIOS가 만드는 선형 framebuffer

`vesafb`는 Intel 시스템의 범용 그래픽 framebuffer 드라이버입니다. 부팅 때 BIOS로 graphics mode를 켜고 m68k 등 다른 port처럼 이를 `/dev/fb0` framebuffer로 사용합니다.

text mode와 graphics mode 가운데 무엇을 쓸지 부팅 때 결정합니다. protected mode에서는 BIOS call을 할 수 없고 real mode에서만 가능하므로 나중에 mode를 바꿀 수 없습니다. linear framebuffer가 필요하므로 VESA BIOS Extensions 2.0이 필수입니다.

장점은 1024x768에서 128열 x 48행 같은 큰 console을 작은 글꼴 없이 쓸 수 있고, `/dev/fb0` 위에서 `XF68_FBDev`를 실행해 모든 VBE 2.0 compliant 보드에서 비가속 X11을 사용할 수 있으며 boot logo도 표시할 수 있다는 점입니다. 단점은 graphics mode가 text mode보다 느리다는 것입니다.

===========================================
vesafb - Generic graphic framebuffer driver
===========================================

This is a generic driver for a graphic framebuffer on intel boxes.

The idea is simple:  Turn on graphics mode at boot time with the help
of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
(and other) ports do.

This means we decide at boot time whenever we want to run in text or
graphics mode.  Switching mode later on (in protected mode) is
impossible; BIOS calls work in real mode only.  VESA BIOS Extensions
Version 2.0 are required, because we need a linear frame buffer.

Advantages:

 * It provides a nice large console (128 cols + 48 lines with 1024x768)
   without using tiny, unreadable fonts.
 * You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11
   support for every VBE 2.0 compliant graphics board).
 * Most important: boot logo :-)

Disadvantages:

 * graphic mode is slower than text mode...

VESA와 Linux kernel mode 번호

mode 전환은 `vga=...` 부팅 매개변수로 하며 자세한 내용은 `Documentation/admin-guide/svga.rst`를 참고합니다. text mode용 `vgacon`과 graphics mode용 `vesafb`를 모두 내장하고 지정 mode가 text인지 graphics인지에 따라 console을 맡깁니다.

graphics mode는 `vga=ask`로 부팅해 Enter를 눌렀을 때 나오는 목록에는 없습니다. 640x480, 800x600, 1024x768, 1280x1024 각각의 VESA mode는 256색에서 `0x101/103/105/107`, 32k색에서 `0x110/113/116/119`, 64k색에서 `0x111/114/117/11A`, 16M색에서 `0x112/115/118/11B`입니다.

Linux kernel mode number는 `Linux_kernel_mode_number = VESA_mode_number + 0x200`으로 계산합니다. 따라서 같은 표는 256색 `0x301/303/305/307`, 32k색 `0x310/313/316/319`, 64k색 `0x311/314/317/31A`, 16M색 `0x312/315/318/31B`가 됩니다.

`lilo.conf`에 `vga=ask`를 넣고 LILO를 다시 실행한 뒤 prompt에서 원하는 mode를 입력합니다. 1024x768x256은 `305`입니다. 실패한다면 BIOS가 linear framebuffer나 해당 mode를 지원하지 않는 경우입니다. 보드가 지원해도 BIOS가 지원하지 않을 수 있고 VBE 1.2는 충분하지 않습니다. 실패 시 `bad mode number`가 나옵니다.

LILO는 원칙적으로 16진수를 처리하지 못하므로 `vga=mode-number` 직접 부팅에는 10진수로 바꿔야 합니다. 일부 최신 LILO는 `0x` 접두사를 붙인 16진수도 처리합니다.

How to use it?
==============

Switching modes is done using the vga=... boot parameter.  Read
Documentation/admin-guide/svga.rst for details.

You should compile in both vgacon (for text mode) and vesafb (for
graphics mode). Which of them takes over the console depends on
whenever the specified mode is text or graphics.

The graphic modes are NOT in the list which you get if you boot with
vga=ask and hit return. The mode you wish to use is derived from the
VESA mode number. Here are those VESA mode numbers:

====== =======  =======  ======== =========
colors 640x480  800x600  1024x768 1280x1024
====== =======  =======  ======== =========
256    0x101    0x103    0x105    0x107
32k    0x110    0x113    0x116    0x119
64k    0x111    0x114    0x117    0x11A
16M    0x112    0x115    0x118    0x11B
====== =======  =======  ======== =========


The video mode number of the Linux kernel is the VESA mode number plus
0x200:

 Linux_kernel_mode_number = VESA_mode_number + 0x200

So the table for the Kernel mode numbers are:

====== =======  =======  ======== =========
colors 640x480  800x600  1024x768 1280x1024
====== =======  =======  ======== =========
256    0x301    0x303    0x305    0x307
32k    0x310    0x313    0x316    0x319
64k    0x311    0x314    0x317    0x31A
16M    0x312    0x315    0x318    0x31B
====== =======  =======  ======== =========

To enable one of those modes you have to specify "vga=ask" in the
lilo.conf file and rerun LILO. Then you can type in the desired
mode at the "vga=ask" prompt. For example if you like to use
1024x768x256 colors you have to say "305" at this prompt.

If this does not work, this might be because your BIOS does not support
linear framebuffers or because it does not support this mode at all.
Even if your board does, it might be the BIOS which does not.  VESA BIOS
Extensions v2.0 are required, 1.2 is NOT sufficient.  You will get a
"bad mode number" message if something goes wrong.

1. Note: LILO cannot handle hex, for booting directly with
   "vga=mode-number" you have to transform the numbers to decimal.
2. Note: Some newer versions of LILO appear to work with those hex values,
   if you set the 0x in front of the numbers.

X11 mode 복원과 refresh rate

`XF68_FBDev`는 정상 동작하지만 비가속입니다. `XF86_SVGA` 같은 다른 가속 X server의 동작 여부는 server와 그래픽 보드 조합에 달려 있습니다.

X server는 video mode를 올바르게 복원해야 합니다. 그렇지 않으면 console이 깨지고 `vesafb`는 이를 복구할 수 없습니다.

Linux 부팅 뒤에는 `vesafb` video mode나 timing을 바꿀 수 없습니다. 기본 60 Hz가 마음에 들지 않으면 그래픽 보드용 DOS tool을 구성해 `loadlin`으로 Linux를 부팅하거나, `vesafb` 대신 `matroxfb`·`atyfb` 같은 native driver를 쓰거나 새 드라이버를 작성해야 합니다.

VBE 3.0도 refresh 설정에 사용할 가능성이 있지만 원문 작성자는 지원 보드와 사양이 없어 시험하지 못했습니다.

X11
===

XF68_FBDev should work just fine, but it is non-accelerated.  Running
another (accelerated) X-Server like XF86_SVGA might or might not work.
It depends on X-Server and graphics board.

The X-Server must restore the video mode correctly, else you end up
with a broken console (and vesafb cannot do anything about this).


Refresh rates
=============

There is no way to change the vesafb video mode and/or timings after
booting linux.  If you are not happy with the 60 Hz refresh rate, you
have these options:

 * configure and load the DOS-Tools for the graphics board (if
   available) and boot linux with loadlin.
 * use a native driver (matroxfb/atyfb) instead if vesafb.  If none
   is available, write a new one!
 * VBE 3.0 might work too.  I have neither a gfx board with VBE 3.0
   support nor the specs, so I have not checked this yet.

protected-mode scrolling 옵션

VESA BIOS는 일부 매개변수를 바꾸는 protected-mode interface를 제공합니다. `vesafb`는 이를 palette 변경과 display panning에 사용할 수 있지만 일부 BIOS에서 동작하지 않아 기본으로 꺼져 있습니다.

커널 명령행은 `video=vesafb:option` 형식이고 여러 옵션은 `video=vesafb:ypan,inverse`처럼 쉼표로 구분합니다. `inverse`는 inverse color map을 사용합니다.

`ypan`은 visible screen을 video memory의 창으로 보고 시작 위치를 바꿔 console을 scroll합니다. full-screen scrolling은 data copy가 없어 빠르지만 화면 일부만 scroll하면 boot logo flicker 같은 보기 흉한 깜박임이 생깁니다.

`ywrap`은 `ypan`과 같지만 video memory 끝에 닿으면 맨 위부터 다시 읽는 wraparound를 보드가 지원한다고 가정하며 더 빠릅니다. `redraw`는 영향 영역을 다시 그리는 안전하지만 느린 기본값입니다.

Configuration
=============

The VESA BIOS provides protected mode interface for changing
some parameters.  vesafb can use it for palette changes and
to pan the display.  It is turned off by default because it
seems not to work with some BIOS versions, but there are options
to turn it on.

You can pass options to vesafb using "video=vesafb:option" on
the kernel command line.  Multiple options should be separated
by comma, like this: "video=vesafb:ypan,inverse"

Accepted options:

inverse        use inverse color map

========= ======================================================================
ypan          enable display panning using the VESA protected mode
          interface.  The visible screen is just a window of the
          video memory, console scrolling is done by changing the
          start of the window.

          pro:

                * scrolling (fullscreen) is fast, because there is
                  no need to copy around data.

          kontra:

                * scrolling only parts of the screen causes some
                  ugly flicker effects (boot logo flickers for
                  example).

ywrap          Same as ypan, but assumes your gfx board can wrap-around
          the video memory (i.e. starts reading from top if it
          reaches the end of video memory).  Faster than ypan.

redraw          Scroll by redrawing the affected part of the screen, this
          is the safe (and slow) default.

palette·MTRR·video RAM override

`vgapal`은 palette 변경에 표준 VGA register를 사용하며 기본값입니다. `pmipal`은 protected-mode interface를 사용합니다.

`mtrr:n`은 vesafb framebuffer의 memory type range register를 설정합니다. 0은 비활성화로 `nomtrr`와 같고 기본값입니다. 1은 uncachable, 2는 write-back, 3은 write-combining, 4는 write-through입니다.

dmesg에 `mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining` 같은 메시지가 나오면 기존 type과 같은 값을 선택합니다. 이 예에서는 `mtrr:2`입니다. `nomtrr`는 MTRR을 끕니다.

`vremap:n`은 video RAM n MiB를 remap합니다. 0이거나 생략하면 video mode에 맞춰 remap합니다. 이 동작은 Antonino Daplas의 2.5.66 patch/idea를 바탕으로, kernel 계산보다 많은 framebuffer memory를 할당할 수 있도록 `[email protected]`가 2.4에 override 가능하게 역적용했습니다.

`vtotal:n`은 Video BIOS가 총 video RAM을 잘못 판단할 때 MiB 단위로 덮어씁니다. 원저자는 Gerd Knorr이고 Nico Schmoigl이 주로 오탈자를 수정했습니다.

vgapal          Use the standard vga registers for palette changes.
          This is the default.
pmipal    Use the protected mode interface for palette changes.

mtrr:n          Setup memory type range registers for the vesafb framebuffer
          where n:

              - 0 - disabled (equivalent to nomtrr) (default)
              - 1 - uncachable
              - 2 - write-back
              - 3 - write-combining
              - 4 - write-through

          If you see the following in dmesg, choose the type that matches the
          old one. In this example, use "mtrr:2".
...
mtrr:     type mismatch for e0000000,8000000 old: write-back new:
          write-combining
...

nomtrr    disable mtrr

vremap:n
          Remap 'n' MiB of video RAM. If 0 or not specified, remap memory
          according to video mode. (2.5.66 patch/idea by Antonino Daplas
          reversed to give override possibility (allocate more fb memory
          than the kernel would) to 2.4 by [email protected])

vtotal:n  If the video BIOS of your card incorrectly determines the total
          amount of video RAM, use this option to override the BIOS (in MiB).
========= ======================================================================

Have fun!

Gerd Knorr <[email protected]>

Minor (mostly typo) changes
by Nico Schmoigl <[email protected]>