frame buffer 이야기(8)(9)

원문 :
http://kelp.or.kr/korweblog/stories.php?story=02/12/08/8598141
http://kelp.or.kr/korweblog/stories.php?story=02/12/10/6611366

글쓴이 : holelee (2002년 12월 08일 오후 08:56) 읽은수: 10,893 [ 임베디드강좌/이규명

]

== 시작하기에 앞서
이 글에 있는 모든 내용은 글쓴이가 가지고 있는 ATI mach 64(2MB) 그래픽 카드가 달려있고 RedHat 8.0이 설치된 PC(또는 Permedia2(8MB) 그래픽 카드가 달려 있는 RedHat 7.3이 설치된 PC)에서 제대로 동작하지만 이 글에 있는 모든 내용이 정확하다고 말씀 드릴 수 없습니다. 이 글에 있는 내용을 따라 했을 때 혹 생길 지 모르는 모든 문제에 대해서 글쓴이는 책임을 지지 않습니다. 글의 내용 중에 잘못된 내용이 있거나 질문할 것이 있으면 위쪽의 “holelee”를 누르고 메일을 보내기 바랍니다.

== 시작
저번 글에서 bmp 파일을 frame buffer상에 display하는 프로그램을 작성하였으므로 이제 16bpp frame buffer에 대한 모든 사항을 알아보았다고 볼 수 있습니다. 물론 pixel 읽기는 말로 넘어갔으므로 조금 의심스러운 부분이 남아 있을 지라도 적어도 display에 대해서는 모든 사항을 알아보았습니다. 오늘 이야기는 16bpp가 아닌 다른 bpp(bits per pixel)에 관한 프로그래밍에 대해서 짤막하게 알아보도록 하겠습니다.
PC 기반의 linux 시스템에서 frame buffer는 보통 4, 8, 16, 24, 32bpp를 사용합니다. 모두 color를 나타낼 수 있습니다. 그런데 embedded system의 경우 gray LCD를 사용하는 경우도 있고 color LCD를 사용한다고 해도 PC와는 다른 bpp를 사용하는 경우가 있습니다. 예를 들어 Compaq(HP에 인수되었지만)에서 생산한 PDA인 iPAQ의 초기 모델의 경우 12bpp를 사용하여 총 4096 color를 나타낼 수 있었습니다. 이렇게 다양한 frame buffer 하드웨어에 대하여 모든 조사를 진행할 수도 없고 테스트도 불가능 합니다. 따라서 이 글은 제 개인적인 경험(보잘 것 없기는 하지만)에 바탕으로 한 추측을 기반으로 작성되었습니다. 이 글의 내용을 모두 곧이 곧대로 사실로 받아들이지 말고 그냥 가이드 정도의 수준으로 생각하고 읽기 바랍니다. 자 시작할 까요?

== 1 bpp
pixel 하나를 1 bit로 표현할 수 있습니다. 어떻게 가능할까요? 당연히 bit가 ‘1’이면 1번 pixel이 나타나고 bit가 ‘0’이면 0번 pixel이 나타나도록 할 수밖에 없습니다. 보통은 0번 pixel은 그냥 pixel이 없는 상태로 결국 bit가 ‘1’이면 점이 있고, bit가 ‘0’이면 점이 없는 그냥 말로 “흑백”이죠. 무슨 gray level이 있고 하는 것이 아니라 그야말로 pixel의 유무를 1bit로 나타낸 것입니다. 얼마 전까지 주로 사용되는 핸드폰용 흑백 LCD가 이런 형태를 지니고 있었죠.(물론 핸드폰은 linux가 아직 널리 쓰이지 않는 분야이기는 하지만요.) 이런 종류의 frame buffer가 많이 쓰이지는 않을 것으로 보입니다. 간단한 정보를 display하기 위해서는 character LCD를 더 선호할 테니깐요.
프로그래밍은 간단합니다. 우선 Frame buffer상의 좌표를 모두 byte와 bit단위로 계산을 해야 합니다. lseek/read/write를 이용하거나 mmap을 이용하거나 하더라도 우리가 기본적으로 읽을 수 있는 최소 단위는 byte(char)이기 때문에 읽고 쓰기는 byte단위로 이루어져야 합니다. 그럼 예를 들어 320x240 사이즈의 frame buffer에서 (99, 50)에 pixel을 찍고 싶다고 가정하죠. 그럼 (99,50)의 위치는 byte 단위로는 (320*50+99)/8 = 2012가 됩니다. 그럼 offset 2012에서 byte만큼의 값을 먼저 읽어 prev_pixel(char형)에 저장합니다. 그 다음 bit offset은 (320*50+99)%8 = 3이 됩니다. 그럼 prev_pixel의 MSB부터 3비트 떨어진 비트 위치를 ‘1’로 바꾸고(prev_pixel |= 0x10 으로 하면 되죠.) 다시 그 값을 offset 2012에 다시 적어주면 됩니다. 아주 간단하죠. 이런 식으로 byte단위 offset과 그 byte내부의 bit 단위 offset을 계산해서 값을 읽거나 쓸 수 있겠습니다.

옛날 이야기 좋아하는 사람들을 위해서 한마디 적으면, PC상에서 사용되던 그래픽 카드중에 Hercules(요즘도 Hercules라는 상표를 달고 나오는 그래픽 카드가 있는데 그런 녀석 말고.) 라고 하는 녀석도 1bpp를 사용했었죠. simcga라고 하는 CGA emulation 프로그램을 램 상주 시키고 게임을 했던 기억이 있습니다.(simvga라고 하는 희대의 사기극이 온라인계를 강타하고 그랬었죠. simvga를 다운로드 받으려고 노력했던 기억이 아련합니다.) 놀라운 것은 linux kernel source에 이 Hercules 그래픽 카드를 지원하는 frame buffer driver가 존재한다는 겁니다. DOS시절 turbo C 2.0으로 Hercules 카드에 그림을 그려본 경험으로 보면 Hercules 카드의 그래픽 메모리는 linear하지 않고 interleaving되어 있어서 offset 계산을 특별하게 했던 기억이 있는데, linux kernel source에 포함되어 있는 Hercules frame buffer는 어떻게 프로그래밍 해야 하는지 궁금합니다. 아마도 mmap을 지원하지 않거나 지원하더라도 linear하지 않을 것으로 보입니다. (도저히 그 그래픽 카드를 구할 수 있는 방법이 없으므로 테스트 못합니다. 혹 구한다고 해도 테스트하기 싫죠. -.-! 또한 kernel source code를 분석해야 할 필요성 조차 느끼지 못한답니다.)

== 2 bpp
pixel 하나를 2 bpp로 나타내는 경우는 gray level LCD에서 사용되는 것으로 보입니다. 한 점이 4개의 gray level로 나타내어 지게 됩니다. pixel값이 “00b”(이진수 00)라면 pixel이 없는 상태(즉 가장 밝은(?, 흰색에 가까운) pixel)이고 “11b”라면 가장 어두운(?, 검정색에 가까운) pixel을 나타냅니다. Pixel값을 이 어두운(?) 순서로 나열하면 “11b” > “10b” > “01b” > “00b”이 됩니다.
프로그래밍은 당연히 1bpp의 경우처럼 byte단위 offset과 bit단위의 offset으로 나누어 계산해야 합니다. 한번 더 예를 들어서 살펴보죠. 320x240사이즈의 2 bpp frame buffer에서 (99, 50)의 위치에 점 “11b”를 쓰고 싶다고 하죠. 그럼 (320*50*2 + 99*2)/8 = 4024의 byte offset을 가집니다. 그 byte 내부의 bit offset은 (320*50*2 + 99*2)%8 = 6이 됩니다. 그럼 한 byte에 총 4개의 2 bpp pixel이 들어가므로 MSB에서 6bit 만큼 떨어져 있는 위치는 LSB에 있는 2bit을 나타내게 됩니다. 따라서 byte offset에서 한 byte를 읽은 후에 LSB의 2 bit를 “11b”로 바꾸고 다시 값을 써 주면 되겠습니다.
한 byte에 4개의 pixel이 들어가므로 다음과 같이 계산 할 수도 있습니다. (320*50 + 99)/4 = 4024, (320*50+99)%4 = 3이 됩니다. 여기서 3이라는 의미는 byte내부에서 3번째 pixel 위치를 나타냅니다.(당연히 LSB 2bit죠.)

== 4 bpp
4 bpp가 사용되는 경우는 크게 color와 gray level로 나누어 볼 수 있습니다. 우선 gray level(주로 LCD가 되겠죠)을 사용하는 시스템은 16 gray level을 나타낼 수 있다는 점만 빼고는 2bpp의 경우와 비슷합니다. pixel값이 “0000b”라면 pixel이 없는 상태(즉 가장 밝은(?) pixel)이고 “1111b”라면 가장 어두운(?) pixel을 나타냅니다.
그럼 color는 어떻게 될까요? pixel 값이 “0000b”이면 어떤 색의 pixel일까요? 혹 3bpp라면 R(1),G(1),B(1)로 나타낼 수 있을 지도 모르는 데 4bpp라면 그렇게 나누기도 쉽지 않습니다. 이 이야기는 아래 palette 이야기에서 살펴보도록 하겠습니다.
프로그래밍은 설명 없이도 알겠죠. 1bpp와 2bpp의 경우와 비슷하게 byte, bit offset을 각각 찾아서 프로그래밍하면 됩니다.

== palette(스펠링이 어려워요.)
palette는 우리말(?)로는 팔레트라고 하죠. 왜 그 미술시간에 튜브에 들어있는 물감을 짜서 쓸 수 있도록 구획이 있는 플라스틱으로 된 판(?) 있잖아요. 환상적인(?) 그림 솜씨를 뽐내며 설명하고 싶지만 KELP사이트의 제약으로 인해 잘 안됩니다.(혹 아직도 모르겠으면 주변 사람들에게 물어 보면 됩니다.) 컴퓨터 그래픽에서도 이 palette라는 것이 등장합니다. 컴퓨터 그래픽에서 등장하는 palette도 미술시간에 사용하던 팔레트와 마찬가지로 지금 사용하고 있는 색깔을 담아두는 공간(실제로는 memory)입니다.
Color 4bpp에서 pixel 값이 “0000b”라면 어떤 색의 pixel이 나올지 궁금했죠. 모든 사람들이 비웃을지 모르지만 답을 공개 합니다. “0번 색깔 pixel”입니다. 그럼 pixel값이 “0011b”라면 “3번 색깔 pixel”이 되고 “1111b”라면 “15번 색깔 pixel”이 됩니다. 상당히 우스운 답이죠? 그럼 이제 “x번 색깔”은 도대체 무슨 색깔인지가 궁금해 집니다.
Color 4bpp에서는 총 16개의 색의 물감을 채울 수 있는 palette가 자동으로 주어집니다. 팔레트의 구획이 총 16개이고 각각의 구획에 0번부터 15번까지의 번호를 부여했다고 가정합니다. 각 구획에 무언가 물감이 들어 있고 그 물감의 색깔을 구획의 번호에 맞추어 “x번 색깔”이라고 부르도록 합니다. 위에서 말한 “0번 색깔”은 말 그대로 palette에 있는 “0번 색깔”을 의미합니다. 그럼 이제 palette의 “0번 색깔”이 무엇인지 알아볼 수 있는 방법만 있다면 pixel값이 “0000b”일 때 어떤 색깔의 pixel인지 알 수 있습니다.
(컴퓨터에서 개수가 정해져 있는 데이터를 관리하기에 가장 편한 것은 array입니다. 따라서 palette도 array로 구현되는 경우가 일반적입니다.)

Linux frame buffer에서는 palette라는 말을 사용하지 않고 대신 colormap이라는 말을 사용합니다. colormap이라는 말이 좀더 그럴싸하게 들리기는 합니다만 아무튼 다음과 같은 ioctl()로 colormap(palette)의 내용을 확인 할 수 있습니다.
struct fb_cmap fbcmap;
….
ioctl(fd, FBIOGETCMAP, &fbcmap);
당연히 frame buffer driver가 colormap을 지원하지 않는다면 ioctl()은 에러를 리턴하게 됩니다.

/usr/include/linux/fb.h(kernel source include/linux/fb.h)를 보면 struct fb_cmap은 다음과 같이 되어 있습니다.
struct fb_cmap {
__u32 start; /* first entry */
__u32 len; /* Number of entries */
__u16 *red; /* Red values */
__u16 *green;
__u16 *blue;
__u16 *transp; /* transparency, can be NULL */
};
start는 보통 0이고 4bpp의 경우 len은 16이 됩니다. red, green, blue는 특정 array나 아니면 malloc된 address를 가리키고 있어야 합니다.(transp는 나중에 설명하죠. 그냥 NULL) 그런 다음 위의 ioctl()을 수행하면 red, green, blue가 가리키고 있는 address에서 현재 frame buffer가 사용하고 있는 palette의 값을 읽어오게 됩니다.
그러면 “0000b” pixel의 색은 RED=fbcmap.red[0], GREEN=fbcmap.green[0], BLUE=fbcmap.blue[0]의 색을 가지게 됩니다. “1111b”는 RED=fbcmap.red[15], GREEN=fbcmap.green[15], BLUE=fbcmap.blue[15]의 색을 가지게 됩니다.
palette에 들어 있는 색을 바꿀 수 있으면 더욱 좋겠죠. 지금 셋팅되어 있는 palette를 사용하는 것이 아니라 우리가 직접 16개의 물감을 짜 놓은 팔레트를 사용하는 것이 그림 그릴 때 더 좋을 것 아닙니까? 그 방법도 있습니다. FBIOPUTCMAP ioctl을 사용하면 됩니다.(당연히 frame buffer driver가 지원하지 않는다면 error를 리턴합니다.)

이제 palette를 좀 정리해서 학구적인(?) 말로 적어보도록 하겠습니다. 어떤 computer graphic에서 palette mode를 사용한다고 하면 pixel의 값은 R,G,B값으로 직접 encoding되어 있지 않고, palette 안에 있는 색을 가리키는 index역할을 하게 됩니다. 실제 색을 알아내기 위해서는 pixel값으로 palette를 indexing하면 됩니다. Linux frame buffer에서는 palette라는 말 대신 colormap이라는 말을 사용하고 palette내용을 알아내거나 바꿀 때 FBIOGETCMAP, FBIOPUTCMAP ioctl()을 사용합니다.(정리끝 : 이렇게 간단한 이야기를 저렇게 길게 써 놓았다니..)

== 8bpp
8bpp의 경우는 gray level LCD에 사용되는 경우는 거의 없고 대부분 256 color를 나타낼 수 장치에 사용됩니다. Color 8bpp는 color 4bpp에서와 마찬가지로 palette mode를 사용합니다. 즉 pixel값에 직접 R,G,B가 encoding되어 있는 것이 아니라 pixel값으로 palette를 index해야 pixel의 색상을 알 수 있습니다. 단지 8bpp이므로 256개의 entry를 가지는 palette를 사용한다는 점이 다릅니다. 프로그래밍 방법은 아주 간단합니다. 이제는 Byte offset만 계산해서 byte의 값만 update하면 pixel이 바뀌게 됩니다. 다시 한번 예로 320x240 사이즈의 8bpp frame buffer에서 (99, 50)에 0xf0라는 pixel을 찍는다고 가정하면 byte offset은 (320*50+99)가 됩니다.
특별한 예외로, 삼성에서 나온 ARM MCU의 경우 8bpp color LCD를 지원하는 데 palette mode를 사용하는 것이 아니라 pixel값에 직접 R,G,B값이 encoding되어 있는 것으로 보입니다.(MSB부터 Red 3bit, Green 3bit, Blue 2bit라고 합니다.)

== 15bpp
16bpp에서 한 픽셀이 dummy(1bit),R(5bit),G(5bit),B(5bit)으로 나타내어질 때 보통 15bpp라고 칭하기도 합니다. Dummy bit가 있다고 해도 한 pixel이 16bit로 나타내어지므로 16bpp라고 해야 정확하다고 볼 수 있습니다.

== 16bpp
넘어 갑니다.

== 24bpp
24bpp이상은 작은 embedded system에서 쓰이는 경우는 거의 없습니다. 아무래도 bpp가 커질수록 메모리에 대한 부담이 크게 작용하기 때문입니다. Embedded system에 사용된다면 대부분 TV(settop)와 같이 display를 주로 이용하는 system의 경우가 많습니다. 24bpp를 보통 true color라고 부릅니다. 24bpp에서 한 pixel의 값은 R,G,B가 각각 8bit(1byte)씩인 모여서 24bit를 이루게 됩니다. 따라서 프로그래밍을 위해서는 offset을 계산한 후에 R,G,B 1byte씩을 써 주면 됩니다.
(R,G,B가 1 byte씩이라는 것은 일반적인 경우입니다. 정확하게 R,G,B가 어떤 bit를 점유하고 있는지는 16bpp에서와 마찬가지로 struct fb_var_screeninfo 내부의 struct fb_bitfield타입의 red, green, blue를 각각 참조를 해야 알 수 있습니다.)

== 32bpp
32bpp도 24bpp와 마찬가지로 true color라고 부릅니다. 24bpp와 동일하게 R,G,B값이 각각 8bit(1byte)로 coding됩니다. 나머지 8bit를 우리는 보통 alpha channel(이하 alpha)이라고 부릅니다. alpha는 그 pixel의 투명도(transparency)를 나타냅니다. 위의 colormap에서 나오는 transp라는 포인터와 struct fb_var_screeninfo내부의 struct fb_bitfield transp라고 하는 부분도 이에 해당합니다. 투명도에 대해서 감이 없는 분은 http://www.directfb.org/screenshots/gimp.png 을 열어보기 바랍니다. 반투명한 image들이 막 섞여 있는 것이 보일 겁니다. 보통 Alpha와 R,G,B를 합쳐서 ARGB라고 부르는 경우도 있습니다. 프로그래밍 방법은 역시 크게 다르지 않습니다. 한 pixel이 4 byte의 크기를 가지므로 4 byte단위의 offset을 계산한 후에 4 byte를 적어 주면 됩니다. 쉽게는 그냥 unsigned형 데이터를 직접 쓰면 되겠습니다.
(A,R,G,B가 1byte씩이라는 것은 일반적인 경우를 나타내며 정확히 A,R,G,B에 대한 bitoffset을 계산하기 위해서는 struct fb_bitfield red, green, blue, transp를 참조하면 됩니다.)

== 몇 가지 남은 이야기
왜 9bpp라는 것은 잘 사용되지 않을까요? R,G,B를 각각 3bit씩 coding하면 아주 쉬울 것 같은데 말이죠. 그 이유는 9bpp로 하면 offset계산과 9bit를 읽고 쓰기가 불편하기 때문일 겁니다. offset계산이야 당연히 byte단위와 bit단위로 나누어 계산한다고 하더라도 항상 2byte를 읽어와서 bit masking을 하고 그 값을 다시 적는 것이 까다롭겠죠. 잘 이해가 안되는 사람은 직접 코딩을 해보면 쉽게 이해할 수 있을 겁니다.

16bpp 이상의 그래픽 시스템에서는 일반적으로 palette mode를 사용하지 않습니다. 그 이유는 어짜피 palette도 메모리의 어딘가에 저장하고 있어야 하는데 bpp가 커질수록 palette의 사이즈가 기하급수적(?)으로 증가하기 때문입니다. 예를 들어 320x240 16bpp 그래픽 시스템에서 palette mode를 사용한다고 가정하죠. 그리고 각 palette안에 들어 있는 pixel은 24bpp로 코딩되어 있다고 할 때 palette를 위해서 필요한 메모리의 크기는 24bit*2^16 = 196608byte가 됩니다. 또한 pixel값을 저장할 메모리의 크기는 320*240*16bit=153600byte이므로 시스템은 총 350208byte의 메모리를 사용합니다. 그런데 320x240 24bpp 그래픽 시스템이 palette mode를 사용하지 않으면 pixel값을 저장할 메모리만 필요하므로 총 320*240*24bit = 230400byte만 필요합니다. 당연히 320x240 16bpp palette mode에서 display할 수 있는 image는 모두 화질 저하 없이 320x240 24bpp 시스템에서 display할 수 있습니다. 이런 결과를 보고 누가 16bpp 이상의 그래픽 시스템이 palette mode를 사용하겠습니까?

bmp파일을 16bpp frame buffer상에 display하는 프로그램에서 24bpp로 encoding된 bmp파일도 display가 가능했습니다. 24bpp pixel을 16bpp pixel로 변환할 때 R,G,B각각의 하위 2~3비트씩을 떼어내었다는 것을 코드를 살펴본 사람은 알 수 있을 겁니다. 당연히 24bpp frame buffer에 display하는 것보다 화질 저하가 생겼지만 어쩔 수 없습니다. 16bpp로 나타낼 수 있는 색상의 수가 24bpp보다는 적으므로 피할 수 없습니다. 실제로 화질 저하를 좀더 줄이려면 bmp파일 내의 각 pixel의 R,G,B값의 통계적인 분포를 살펴보고 그에 따라서 하위 비트를 떼어낼지 아니면 상위 비트를 떼어내어 saturation시킬 지 결정해야 합니다. 예를 들어 24bpp로 encoding된 bmp파일이 R,G,B값을 하위 두 비트만 사용하여 매우 어두운 image였다면 제가 수행한 방법으로는 완전히 검은 image를 얻을 수 밖에 없습니다.
그럼 24bpp로 encoding된 bmp파일을 8bpp(palette mode) frame buffer상에 display하려면 어떻게 해야 할까요? 16bpp의 경우는 그래도 pixel의 값이 R,G,B 값 자체로 코딩되어 있으므로 적당히 bit를 떼어내면 쉽게 가능합니다. 하지만 Palette mode를 사용하면 256가지 색상은 원하는 색상을 마음대로 골라서 사용할 수 있지만 다른 색깔은 어떻게 표현할 방법이 없습니다. 혹시 24bpp로 encoding된 bmp파일이 256색 이하만 사용한다면 그 사용된 색으로 palette를 업데이트하고 display하면 화질 저하가 전혀 없는 image를 얻을 수 있습니다. 하지만 그럴 가능성은 일반적으로 매우 적죠. 이런 경우 bmp파일을 살펴봐서 bmp파일에서 적당히 256가지 색상을 찾은 다음 그 256가지 색상으로 bmp파일의 각 pixel을 이미 고른 256개의 색상중에 가장 가까운 색상으로 모두 바꾸어서 화질 저하를 최소화하려고 노력합니다. 당연히 화질 저하가 최소화되려면 256가지 색상을 잘 선택해야 합니다. 이런 과정을 전문 용어로는 dithering(디더링)이라고 표현한다고 합니다. 사실 전 dithering의 구체적인 방법은 전혀 아는 바가 없습니다. 그래서 처음부터 frame buffer이야기를 16bpp로 한정한 것입니다.(아! 이 잔머리 놀랍지 않습니까?) bmp파일 display 예제로 올렸던 압축 파일 내부의 kelp_logo_1bpp.bmp와 kelp_logo_4bpp.bmp는 KELP 사이트의 logo(24bpp)를 PC용 프로그램으로 dithering해서 만든 이미지입니다. kelp_logo_1bpp는 당연히 흑백이니까 차이가 나고 kelp_logo_4bpp도 잘 살펴보면 원본 이미지와 차이가 나는 것을 볼 수 있습니다.

마지막으로 24bpp나 32bpp를 왜 true color라고 부를까요? 이건 학교 다닐 때 수업시간에 얼핏 들은 이야기인데 보통 사람의 눈으로는 256개 이상의 gray level로 encoding된 image를 256개의 gray level image와 구별하기 힘들다고 합니다. 즉 똑 같은 image를 512(9bit)개의 gray level로 나타내든지, 1024(10bit)개의 gray level로 나타내든 256 gray level로 나타낸 모습과의 화질 차이는 보통 사람 눈에는 안 보인다고 합니다. 어찌 보면 사람의 가청 주파수가 20Hz~20kHz라는 것과 같은 사람의 한계라고 볼 수 있습니다. 물론 백마 타고 온 초인이 간혹 존재해 구분해 내겠지만요. 따라서 R,G,B를 각각 256(8bit)단계로 표현한 24bpp와 32bpp를 true color라고 부릅니다. 마케팅적인 요소가 있는지 아니면 초인들이 늘어났는지 알 수는 없지만 DVD player에서 사용하는 DAC(Digital to Analog Converter)은 보통 R,G,B(또는 Y,Cb,Cr)를 각각 10bit씩 사용하고 PC 시스템에서도 최근에 나온 matrox Parhelia와 같은 그래픽 카드는 R,G,B값을 8bit이상으로 표현할 수 있는 경우가 있습니다. Matrox Parhelia 그래픽 카드는 너무 비싸서 선뜻 사기도 힘들고 저와 같은 막눈으로는 화질이 좋아졌다고 판단할 수 없죠.

== 마치며
간단히 적으려고 했는데 많이 길어졌습니다. 너무 길어져서 그냥 휙 넘어간 부분도 많은데 그냥 이해하기 바랍니다. 이번 글에서 제일 중요한 이야기는 palette에 관한 것이었고 상식으로 alpha channel이나 이런 것들을 기억해 두면 됩니다. 이번 글은 사실 frame buffer뿐 아니라 대부분의 그래픽 시스템과 그래픽 파일에도 동일하게 적용되는 부분입니다.
다음 글이 frame buffer 이야기의 마지막 글일 겁니다. frame buffer를 사용하는 몇 가지 프로그램들에 대한 소개하고 frame buffer의 한계 등에 대해서 다룰 예정입니다. 빨라도 다음 주말에나 글을 쓸 수 있지 않을까 생각이 듭니다.

(푸념 한마디) 지금 사용하고 있는 MS Windows PC의 그래픽 카드(matrox G400)가 맛이 가려나 봅니다. 툭하면 화면에 줄이 가고 다운 되고 그러네요. 드라이버 문제라면 다시 설치해 보겠지만 잘 모르겠네요. 가뜩이나 궁핍한 생활에 그래픽 카드마저 속을 썩이니…혹 Hercules 그래픽 카드를 아직까지 골동품(?)으로 소장(?)하고 있는 분은 저한테 택배로 부쳐 주시기 바랍니다. PC에 ISA slot이 있었나? 앗, 그러고 보니 MS Windows가 Hercules 카드를 지원하지 않을 듯. Linux 만세! 후후…

저작자표시 비영리 변경금지

'Programming > Linux_Kernel' 카테고리의 다른 글

Branch Prediction (2)	2009.06.26
SecureCRT 에서 menuconfig 보기 (0)	2009.06.08
frame buffer 이야기(6) (7) (0)	2009.06.04
frame buffer 이야기(4) (5) (0)	2009.06.04
frame buffer 이야기 (3) (0)	2009.06.04

December Dream

frame buffer 이야기(8)(9)

'Programming > Linux_Kernel' 카테고리의 다른 글

티스토리툴바

frame buffer 이야기(8)(9)

'Programming > Linux_Kernel' 카테고리의 다른 글

'Programming/Linux_Kernel' Related Articles

티스토리툴바