'분류 전체보기'에 해당되는 글 400건

컴피즈는 리눅스 데스크탑을 아주 멋진 효과로 쓰는 맛이 있게 만들어주는 정말 고마운 도구입니다. 우분투에서도 8.04부터 기본 탑재해왔고, (그 전에는 저장소에는 있었지만 따로 설치를 해줘야 했습니다.) Unity인터페이스를 굴리는데 쓰이고 있습니다. 하지만 Unity는 컴피즈를 그냥 창관리자로만 쓰고 있어서 컴피즈의 다양한 효과를 쓰려면 이리저리 삽질을 해야 합니다.

 그래서일까요? 우분투가 Unity를 탑재하기 전의 모습과 흡사한 리눅스민트(특히 MATE버전)에서는 Compiz Config Setting Manager(통칭 CCSM-컴피즈 설정 관리자)를 기본 탑재하고 데스크탑 설정에서 클릭 한방으로 컴피즈를 쓸 수 있게 배려해 놓았습니다. 우분투도 10.10까지만 하더라도 설정-모양에서 바로 컴피즈를 켤 수 있었고 이는 삽질이 동반되었던 다른 배포판에 비해 참 유용했었습니다. 하지만 Unity를 탑재하기 시작하던 11.04부터 컴피즈설정이 삽질이 되기 시작했고 상당히 짜증나는 작업이었는데 리눅스민트에서 이를 다시 클릭 몇번으로 할 수 있게 해 주었네요.

14.1.8 현재 리눅스민트 17.1(MATE)에서 컴피즈를 쓰는 법은 다음과 같습니다. 아주 간단합니다.

메뉴-기본설정-데스크탑 설정으로 들어갑니다.

그리고 창 탭을 클릭하고 다음과 같이 설정합니다.

저는 지금 컴피즈가 설정이 되어있어서 이렇게 되어있지만 기본은 마르코로 되어있을 겁니다. 그러면 여러가지 옵션들이 즐비한데 컴피즈로 바꾸면 딱 이것만 뜨게 됩니다. 그럼 나머지 옵션은 어디서 하냐구요?

컴피즈 설정 관리자(일면 CCSM)으로 하시면 됩니다. 여기서 각종 효과와 비기(...)등을 쓰실 수 있게 됩니다.

다른 효과는 몰라도 저 창 출렁거림효과는 중독성이 상당히 강하다. 괜히 창을 흔들어 보고 싶을 정도

민트메뉴-설정에 가보시면 CompizConfig Setting Manager라고 있습니다. 이게 바로 컴피즈 설정 관련프로그램인데 여기서 이것저것 건드리다보면 데스크탑이 엄청 느려(...)지는 경험을 하실 수 있습니다. 물론 컴피즈니까 GPU가속은 필수입니다. 하지만 쓰다보면 중독 될 정도로 컴퓨터를 쓰는 맛이 있습니다. Unity도 괜찮은 인터페이스지만 전 반쪽짜리 컴피즈보다는 전부 다 쓸 수 있는 MATE용 컴피즈가 상당히 마음에 듭니다. 아니 이게 진짜 컴피즈이지요. 다른 것은 몰라도 애니메이션 설정하고 창출렁거림 옵션은 꼭 켜두시길 권장합니다. 나중에는 출렁거리지 않으면 이상하다고 느껴질 정도입니다. 데스크탑 큐브도 좋지만 가상 데스크탑을 적극적으로 쓰지 않는다면 볼 일이 없는 것이 함정입니다.

어쨌건 리눅스 민트 쓰신다면 컴피즈를 켜는 것을 추천합니다.

P.S 스텝매니아를 하신다면 컴피즈 설정에서 Composite에 Stepmania를 제외 시켜주시는 것이 좋습니다. 보니까 프레임이 현저히 떨어집니다.

방법은 다음과 같습니다. CCSM에서 Composite를 누르고

Unredirect Match부분에서 위 그림과 같이 내용을 추가해주시면 됩니다.

오늘도 역시 한글 문제가 터져주셨습니다. 하지만 그리 큰 문제는 아니었고 그냥 영문폰트와 한글폰트가 연결이 안되어서 생긴 문제였기에 큰 문제는 아니었습니다.

http://linuxmint.kr/5848

여기서 보면 ~/.fonts.conf 파일을 만들고 아래와 같은 내용을 적어서 설정파일을 만듭니다.

내용을 보시면 Nimbus Sans L과 DejaVu Sans를 UnDotum 폰트와 연결하는 내용입니다.

그리고 터미널에서

fc-cache -fv 한번만 쳐주시고 로그아웃 했다가 다시 스팀에 접속하시면 한글이 멀쩡히 나오는 것을 확인 하실 수 있습니다.

이전에는 포탈시리즈나 레프트4데드 시리즈를 할 때 그냥 영문(...)으로 했었는데 생각보다 간단했었군요.

2015.2추가

위의 팁은 민트에서만 통하는 것인지 루분투에선 안 통하네요.

http://www.ubuntu-kr.org/viewtopic.php?p=121681#p121681

위의 글에 의거.

ttf-wqy-zenhei 이 패키지를 깔면 잘 나온다고 합니다. 해보니...잘 되네요.

역시나 까탈이는 오늘도 까탈스럽게 굴었습니다. 이유는 잘 모르겠지만 fglrx가 설치된 우분투에서 wine을 설치하려하니 fglrx를 지워야 한다고 뜨더군요.

이건 또 뭔가 하니까 wine 1.6이후에 추가 패키지로 설정된 opencl관련 패키지가 fglrx를 지우려고 드는 것이었습니다. 마음 같아서는 오픈소스로 갈아타고 싶었는데 아직 오픈소스 드라이버가 안 나온 상황이라(비마 기반 APU입니다.) 어쩔 수 없이 fglrx에 기댈 수 밖에는 없습니다.

 어쨌건 저랑 비슷한 상황이 있는 듯 하는 사람이 많은 듯 하여 일단 wine만 무시하고 설치하는 법만 알려 드리겠습니다.

 http://askubuntu.com/questions/540780/14-10-wine-and-fglrx-conflict

출처는 여기입니다.

 여기서는 fglrx의 패키지 설정을 바꾸는 것으로 해결하기도 하는데 그건 그거대로 삽질 같아서 wine을 그냥 강제로 설치하는 것을 알려드리겠습니다. 어차피 opencl은 fglrx 설치하면서 다 설치 되어서 필요없거든요.

 우선 wine을 deb형태로 다운로드 받습니다.

sudo apt-get download wine1.6-amd64 wine1.6-i386 wine1.6 playonlinux

여기서 playonlinux는 따로 설치하려면 설치하시고 아니면 굳이 설치 안 하셔도 됩니다. 그리고 32비트 사용자 분들은 wine1.6-amd64는 지워주세요.

이제 다 다운로드가 되었는지 확인 되셨으면 설치를 해야겠지요? 여기서 일부 옵션을 넣어줍시다.

sudo dpkg --force-all -i *.deb

이제 강제로 설치를 하려고 할텐데 그냥 메시지는 무시하셔도 됩니다. fglrx가 다 설치해 놓은 것들입니다. 구동에 아무런 지장 없습니다.

하지만 제일 좋은 것은.... fglrx를 안 쓰는 것이 가장 좋다고 생각합니다. Gallium3D가 제 칩셋을 빨리 지원해 주길 기다리면서....

2014. 1. 2

 지금 확인해보니 wine때문에 패키지 설정이 꼬여버립니다. 그냥 Playonlinux를 설치해서 이를 이용합시다. 처음 실행할 때 wine이 없다고 뭐라 뭐라 할텐데 가뿐히 무시하고 Wine versions기능으로 wine을 따로 설치해서 굴리면 됩니다.(단, PlayonLinux가 저장소에 있는 구버전이면 안 됩니다. 이건 Wine을 무조건 적으로 설치합니다.) 즉 System wine을 안 쓰면 된다는 소리.

아니면 fglrx의 패키지 설정을 수정해도 문제는 없을 것이라 믿습니다. 그런데 OpenCL 관련해서 문제가 일어날지도 모르기 때문에... 일단 Gallium3D 드라이버가 나올 때까지 기다리는 걱이 최선인듯...

2014.2.

 이미 오픈소스 드라이버는 나와있었습니다. 그동안 검색 부족과 14.10을 거들떠도 안 본 죄로(...)몰랐던 것일 뿐. 그냥 커널을 3.15로 올리고 Xorg를 PPA를 통해 버전업하면 됩니다. 아니면 oibaf PPA를 이용하시면 안정적이면서 편리한 드라이버를 설치하실 수 있습니다. 그러니까 쉽게말해서 그냥 Catalyst를 버리시면 됩니다.

제목은 한글문제입니다. 이번에 이야기 할 것은 한컴의 워드프로세서가 아니라 우리가 지금 사용하는 바로 이 한글을 말합니다.

리눅스는 아시다시피 오픈소스로 공개된 커널을 기반으로 이리저리 손을 대서 만들어낸 물건입니다. 따라서 모든 세계인들이 활용 할 수 있게 만들어야 하고 또 그렇게 되고 있습니다. 그런데 워낙 리눅스 이용 인구가 적은 한국은 한글 문제에 자주 봉착합니다. 아니 한글 자체가 문제가 아니라 UTF-8과 EUC-KR의 호환문제, 게다가 Microsoft만 만들고 쓰는 CP949같은 코드 파편화 문제입니다. 사실 한글을 읽고 쓰는 것은 전혀 문제가 없습니다. 유니코드라는 국제 표준이 나오면서 전세계의 언어를 통합 관리하게 되었기 때문에 이 유니코드만 사용한다면 한글문제, 아니 전세계의 모든 언어의 문제는 해결이 가능합니다.

문제는...... 표준을 지키지 않는 것들입니다. 저는 "비표준"이나 "사실상의 표준"을 참 싫어합니다. 비표준이야 어쩔  수 없는 경우가 많다고 해도(예를 들면 M5.5같은 애매한 나사라던가....이건 M5나 M6을 쓰면 안 되나?) 사실상의 표준이라고 이를 고수하는 것도 좀 웃기다는 생각이 듭니다. 사실상의 표준이라면 이를 표준으로 지정하면 되는데 ISO에서 이를 표준으로 지정하지 않는다?

대체 무엇이 문제일까요? 대표적인 것이라면 플래시가 있습니다. 브라우저 플러그인 방식인데다가 멀티코어 사용에 문제가 있고, 어느 한 회사(Adobe)의 독점 형태로 제공되고 있다 보니 문제가 참 많습니다. 하지만 그래픽적 효과를 이렇게 쉽게 보여줄 수 있는 녀석도 없어서 플래시는 지금 웹 그래픽에서는 표준이다시피 합니다. 하지만 HTML5에서 플래시의 기술은 들어가지 않았습니다. 넣으려면 넣을 수도 있었을텐데 말입니다. 그 이유는 모바일 플래시를 써보신 분들은 아시겠지만 엄청난 연산량에 따른 문제라고 하는군요.

그러고보니 반대로 한 회사에서 만들어서 쓰다가 ISO의 표준지정으로 바뀐 기술도 있습니다. 바로 PDF! 그러고 보니 이 물건도 Adobe의 결과물이군요. PDF는 현재 문서표준으로 지정되어 있어서 모든 기술이 공개되어있습니다. 위의 플래시 기술이 완전공개가 되지 못한 것(플래시 기술의 일부는 공개가 되어있습니다. 오픈소스의 결과물이라고는 하지만...)과는 차원이 다르지요.

자 다시 한글 표준으로 돌아와서 이제 어떤 문제가 있는지 확인 해 봅시다. 먼저 MS는 CP949라는 뭔가 해괴한 EUC-KR호환 한글코드를 사용합니다. 그 와중에 내부에서는 유니코드를 사용합니다. (뭐하는 짓이야...) 그리고 KS표준에 보면 EUC-KR과 유니코드를 동시에 올려놓았습니다. 그리고 UTF-8이라는 유니코드와 아스키 호환 코드도 존재합니다. ISO는 당연히 유니코드만이 표준입니다.

네 점점 가관입니다. 특히 KS표준이 참 막장이네요. EUC-KR과 유니코드를 같이 표준으로 채택하는 바람에 통일이 이루어지지 못했습니다. 그럼 CP949는? 이건 표준 아닙니다. 그냥 MS가 만들어낸 확장 완성형 기반입니다. 마치 옛날에 조합형 vs 완성형 싸움 비슷한 생각이 드는군요. 현재로써는 완성형이 이긴 것 같기는 하지만 한/글 워드프로세서가 조합형을 썼기에 지금의 위치에 오른 것을 생각해보면....

이러한 문제는 멀리 갈 것도 없이 UTF-8을 기본으로 사용하는 리눅스/OSX에서 윈도에서 압축한 ZIP파일을 풀면 여실히 드러납니다.한글 파일명이 대책없이 깨집니다. CP949는 EUC-KR 호환이라고 했지요? 원인은 여기있습니다. 때문에 반디집같은 프로그램은 UTF-8환경을 한번 거치는 것 같기는 합니다만,(한글이 아닌 다른 외국어로 쓰인 파일명을 읽기 위함 그런데 이것이 UTF-8에서 압축한 한글에도 먹히는 것입니다.)

언제나 매번 문제를 일으키지만 해결될 기미가 안 보이는 한글문제... ISO의 권고사항만 지키면 큰 문제는 없을 것 같은데 왜 안 지키는 사람들이 많을까요? 제발 적당히 배운티 내지 않았으면 좋겠습니다.

이번에는 무진장 딱딱하고 재미없는 글을 올릴 차례입니다. 물론, 지금까지 재미있는 글은 없었지만 이번에는 더 딱딱한 이야기를 해보려 합니다.

많은 사람들은 아직도 리눅스를 엄청 딱딱하고 어려운 운영체제로 알고 있습니다. 원인이야 뻔하지만, 리눅스를 사용해본 사람들은 리눅스 자체가 어려운 것이 아니라 사용 방법이 틀렸다는 것을 알고 있습니다.

사실 리눅스를 데스크탑 운영체제로 사용하게 된 것은 그리 오래되지 않았습니다. 리눅스는 사실 서버 워크스테이션에 쓰이던 Minix의 카피였고(리누즈 토르발즈 자서전에 나와있습니다.) 그 리눅스라는 커널보다 사용자의 완전 분리라는 독특한 매력에 사람들이 빠졌다고 합니다. 즉, 한 컴퓨터에 여러사람이 달려들어도 서로 다른 환경을 쓰는 것 같은 느낌을 줬다고 합니다. 윈도 사용자분들은 1인 1PC시대에 살고 있는데다가 보통 관리자 모드로 사용하기 때문에 (UAC로 어느 정도 막고는 있지만)어떤 것인지 잘 모르겠지만, 관리자는 따로 있고 사용자들은 오로지 User모드만 사용하는 것이지요. 어떤 프로그램을 설치하고 싶으면 관리자에게 연락해서 설치해 달라고 해야 했고, 그 관리자의 계정은 언제나 root였기에 root계정이 해킹당하면 말그대로 시스템이 장악되었습니다.

무슨 소리인지 잘 모르겠다고요? 그냥 당시의 컴퓨터는 원격으로 접속해서 사용해야만 하는 컴퓨터였고(그래서 워크스테이션이라고 따로 지칭한 것입니다.) 이 때 관리자와 유저는 엄격히 구분되어야 했습니다. 사실 Unix시스템의 전반이 다 그러했습니다. 그런데 리눅스가 어렵다는 편견은 아마도 여기서 시작된 것 같습니다.

사실 윈도는 윈도XP시절부터 사용자를 제대로 분리하기 시작했습니다. 그전의 98시절에도 충분히 사용자분리 옵션은 있었지만 바탕화면이 공유되는 등(...) 말도 안되는 사용자 분리를 택했기 때문에 아무도 그런 기능이 있었는지도 몰랐습니다. 심지어 어떤 사용자모드를 쓰더라도 시스템의 근본까지 장악 가능했으니(리얼 도스모드 진입가능→ 하드웨어 직접 접근 가능)사용자 분리의 이점이라고 눈꼽만큼도 없었습니다. 대신 그만큼 개인이 신경 쓸 거리는 줄기는 했습니다. 그러다가 윈도NT계열이 가정용으로 들어오면서(즉, XP시절 이후를 말합니다.) 기존 NT가 했었던 것처럼 사용자 분리를 시도했는데 현실은 그냥 유저 구분없이 모두함께 관리자 모드로 사용... 윈도 비스타시절부터 UAC란 놈을 들고와서 관리자 권한이라도 경고를 한다던가 한번 필터링을 하는 방식도 취해봤지만 이미 전반적인 생태계가 관리자 권한을 요구하는 괴상한 형태로...

즉, 윈도 사용자들은 권한 분리가 익숙하지 않습니다. 그에비해 워크스테이션으로 시작된 OS인 리눅스는 이를 엄청 중요시 여깁니다. 관리자 권한 해킹당하면 해당 워크스테이션을 사용하는 모든 사람들의 정보가 전세계로 솟구칠테니까요.(혹은 삭제당하거나) 처음 리눅스란 것을 본 사람들은 여기서 짜증을 내기 시작했'었'습니다. 왜 과거형이냐면 기존 윈도 사용자들이 UAC덕에 관리자 권한으로 실행하는 것에 익숙해지기 시작했거든요. 물론 아직도 UAC가 뜨면 당황하는 사람들이 태반이기는 하지만 이제 좀 관리자 권한에 대해 이해를 하기 시작한 사람들이 보입니다. 그런 사람들에게 리눅스를 보여주고 su나 sudo 혹은 gksu같은 명령을 알려주면 그게 "관리자 권한으로 실행"이라는 것을 곧잘 이해하더군요.

(물론 아직도 이해 못하는 사람 많습니다. 왜 관리자 권한이 필요한 이유조차 모르기 때문이지만...)

그런데 우분투같은 사용자 편의를 중시한 배포판에서는 언제부터인가 관리자 권한 확인이 UAC 비스무리한 모습으로 만들어지더군요. 즉, 권한분리에 익숙치 않은 사용자들을 위해서인지 그냥 권한 분리를 윈도스럽게 해놓았습니다. 우분투가 쉽다고 하시는 분들 중에는 이러한 이유도 있습니다. 다른 배포판에서는 기본 세팅상태를 기준으로 유저모드로 sudo 명령을 쓰면 대부분 안 먹습니다!(데비안이나 페도라 기준) 우분투처럼 쓰고 싶으면 /etc/sudo내의 있는 설정파일을 수정해야만 하고 수정을 하려면 root로 로그온 해야합니다. 즉, 관리자의 손길이 필요하다는 것이지요. (이 이야기는 데비안 기준이고 페도라는 좀 다르다고 알고 있습니다.)아, 대신 우분투는 root권한 자체가 숨겨져 있습니다. 마치 윈도에서 Administrator계정이 안전모드에서만 나오는 것과 비슷합니다.

이쯤되면 리눅스는 어렵다는 것은 일부 배포판에 한정해서이기는 하지만 조금 완화 되었을 것이라고 생각이 듭니다. 자신의 정체성 중 일부를 수정하면서 까지 윈도스럽게 수정했으니까요. 소프트웨어의 부재는 전에도 말했듯이 wine이나 Virtualbox로 극복이 가능한데다가 전용 소프트웨어도 상당히 훌륭합니다.예전에는 제품개발은 어쩔 수 없이 윈도에서 했지만, 요즘은 제품개발도 리눅스에서 가능해져 가고 있습니다.(DraftSight와 CATIA의 wine 실행 - 이놈은 태생이 유닉스 용입니다.)

리눅스가 어렵다는 것은 편견이라고 했습니다. 리눅스의 대표적인 데스크탑 배포판인 우분투는 이미 윈도 사용자를 상당히 배려했습니다. 그런데도 많은 사람들은 리눅스를 어려운 운영체제로 믿고 있습니다. 일단 까더라도 사용해보고 깠으면 좋겠습니다.

이 놈이 바로 Arduino Mega. 포트가 많아서 출력이 많이 필요할 때 유용하게 쓰인다.

얼마 전에 아두이노 Mega 2560보드로 프로젝트를 잠시 진행한 적이 있었습니다.

캐릭터LCD를 붙여서 LCD에 글씨를 띄워야 하는데 자꾸 LCD에 글자가 깨지는 현상이 일어났습니다. 이유는 잘 모르겠는데 어찌어찌 하다 보니 글씨가 제대로 뜨기는 하더군요. 어쨌건 이후로는 정상적으로 작동하길래 그 날은 그냥 넘어갔습니다.

그런데 해당 문제가 다음날 또 터지더군요. LCD에서 글씨가 또 깨지더군요. 이유가 뭔지 잘 몰라서 난리를 치던 중에 프로그램 문제인가 싶어서 PC에 아두이노를 연결하자 정상적으로 LCD에 글씨가 뜨기 시작했습니다.

...사실 그동안은 전력 수급 문제로(LCD가 생각보다 전력을 많이 필요로 합니다. USB만으로는 좀 벅찰 정도입니다.)9V 어댑터를 연결해서 쓰고 있었는데 USB연결 없이 어댑터만 연결하자 LCD에 글씨가 깨지는 것이었습니다. 어댑터 문제인가 싶어서 어댑터 전압을 측정했더니 9V로 아주 쌩쌩하게 잘 돌아갔습니다. 사실 7V만 나와도 정상 작동 되어야 하는 것이기에(아두이노는 7~12V 어댑터를 연결하면 알아서 자체적으로 5V,3.3V로 알아서 낮춰서 잘 돌아갑니다.) 어댑터가 문제였을리는 거의 없습니다.

그래서 결국 아두이노 보드를 시험하던 도중 5V 출력단에서 전압이 이상하리만큼 낮은 것을 확인했습니다. 3.3V남짓 나오더군요. 그 옆에 있던 3.3V 출력단은 어떤가 봤더니 당연하게도 3.3V가 나오고 있었습니다. 즉 3.3V는 정상.

5V 출력 포트와 3.3V 출력 포트. 여기와 관련된 곳이 바로 어댑터 연결잭 근처에 있는 레귤레이터다. 즉 저놈이 전압 불안정의 원인

그래서 혹시나 하고 인터넷에 5V 출력 관련 이슈가 있나 해서 찾아보니 이슈가 있는 것인지는 모르겠지만 외국에도 사례가 있더군요.

http://www.instructables.com/id/Fix-a-fried-Arduino-Mega/#step1

Fried-Arudino...일명 날아간(튀겨진?) 아두이노 살리기.

아무래도 제 예상입니다만 LCD를 달면서 전류가 혀용량을 넘어섰고, 그에따라 레귤레이터가 맛이 갔는지도 모르겠습니다. 어쨌건 해당 글에는 레귤레이터를 아에 갈아버리더군요. 그것도 원래 아두이노에 달려있던 SOT-223대신 LM7805로 바꿔버렸습니다.

SOT-223도 괜찮은 칩이기는 한데, LM7805가 아무래도 신뢰도가 워낙 좋다 보니 이해가 가더군요.(LM시리즈는 전자상가에서 쉽게 구할 수 있는 데다가 실습 교재로 엄청 많이 쓰입니다.) 게다가 학교에서 수리 하다보니 LM7805는 워낙 남아돌아서(...) 저 사이트에 나온대로 바꿔보기로 했습니다.

그런데....

레귤레이터의 납이 안 떨어지네요...아무리 인두로 지져도 인두 온도가 낮은 것인지 저 칩을 뗄레야 뗄 수가 없었습니다. 그래서 그냥.... 

 해당 사이트를 참고해서 Vout부분인(즉, 원래 5V가 나왔어야 했지만 맛이 가서 3.3V가 나오는) 가운데 다리(*ㅡ_ㅡ*)를 잘랐습니다. 쉽게 말해서 그냥 보드에서 안 떨어지니 그냥 고자(...)로 만들어버리는 것으로 결정.

그리고 새로이 7805를 기존 레귤레이터 다리에 위치에 맞춰서 그대로 납땜을 했습니다.

SOT-223은

1pin GND

2pin Vout

3pin Vin

이지만,

LM7805는

1pin Vin

2pin GND

3pin Vout

입니다.

즉, 중간에 다리가 꼬이는데 혹시라도 있을 합선을 방지하기 위해 가운데 다리에 수축튜브를 끼워넣어서 절연을 해줍니다.

자세한 내용은 위의 링크가 걸린 사이트를 참조하시면 편하고, Vin의 위치가 1-3이니까 기존 레귤레이터와 LM7805가 서로 마주보게(...) 납땜 해주시면 편리합니다. 즉, LM7805의 2번 다리와 3번 다리를 서로 엇갈리게 꼬고 LM7805의 1번 다리와 기존 레귤레이터의 3번 다리가 만나도록 납땜 해주셔야 합니다. 혹시라도 잘못 연결하면 레귤레이터에서 연기가 피어오르는 것을 감상하실 수 있습니다.

7805를 아두이노에 납땜한 모습 테스터기로 찍어보자 딱히 합선은 없었다.

어쨌건 레귤레이터도 바꿨겠다. 어댑터 연결후에 5V포트의 전압을 측정하자 5V 칼전압이 나옵니다. Wow!

LCD를 연결하자 LCD에 글씨 엄청 잘 뜹니다. 역시 전압이 문제였다고 밖에는....일단 7805는 열이 많이 나오는 소자라서 방열판을 붙여줘야 합니다. 7805파는 가게에서 방열판도 같이 파니까 꼭 방열판을 달아놓으세요. 안 그러면 저 7805도 맛이 가는 수 있습니다. SOT-223은 잘 모르겠지만 7805는 그만큼 허용 전류량도 높으니 전류를 많이 뽑아먹어도 이제 큰 무리는 없을 겁니다. (못해도 1A는 버틴다고 하네요.)만세!

추가 이야기

아두이노에 가변저항 없이 LCD연결하기.

보통 아두이노 예제에서 LCD연결 회로는 다음과 같습니다.

저 가변저항이 무슨일을 하는가 봤더니 LCD 글씨의 대비를 조절하는 것이라고 합니다. 즉, 전압을 조절해서 LCD의 어두운 부분을 만드는 전압을 설정하는 것인데, 까놓고 말해서 가변저항 달기도 짜증나서 이를 간단히 하는 방법을 알려드리겠습니다.

우선 저 가변저항이 없으면 글씨가 무조건 까만 사각형으로 나오게 됩니다. 그리고 가변저항을 돌리다 보면 어느 순간 글씨가 보이는데 그 글씨가 보이는 수준은 LCD마다 제각각입니다. 기준전압이 지들 마음대로인데 보통은 5V짜리 기준으로 2.5V입니다. 즉 반정도 돌리면 보입니다. 그런데 가변저항을 달 생각하니까 그냥 짜증이 나더군요. 그래서 회로를 살짝 수정했습니다.

저 갈색선이 보이시나요? 아두이노의 6번핀과 LCD의 Contrast핀을 직접 이었습니다.

6번핀이 뭐냐하면 PWM지원 핀입니다.

analogWrite(~~,~~);

이 코드가 먹히는 핀이라는 것입니다. 물론 6번핀 말고도 PWM지원 핀이면 어디에 연결해도 상관은 없습니다.

analogWrite(6,120);//6은 6번핀이라는 의미 120은 듀티비가 120 즉, 출력 전압은 120/255 * 5V

위의 코드를 Setup()함수 내에 적어주시면 가변저항 없이도 LCD의 글씨가 보일 것입니다. 좀 까맣다 싶으면 120보다 낮은 수로 바꿔주시면 되고 너무 하얗다 싶으면 120보다 높이면 됩니다. 일부 LCD는 반대일 수도 있습니다. 어쨌건 저 숫자를 바꿔주면 조절이 됩니다. 심지어 머리를 조금만 더 쓰면 대비 조절을 별도의 스위치 조작이나 PC연결로 할 수도 있습니다.

보드가 깔끔한 것을 원하신다면 이 방법을 추천드립니다. 가변저항은 좀 불편하니까요. 디지털 방식도 나쁘지는 않다고 생각합니다.

여러분들은 어떤 게임을 좋아하시나요? 사실 저는 PC나 콘솔 게임은 그렇게 좋아하지 않습니다. Long Live The Queen에 대한 글이나 에뮬레이터에 관한 글을 올린 제가 할 소리는 아니긴 하지만 저는 오락실 게임들을 좋아합니다. 그 중에서도 몸 쓰는 게임을 참 좋아하는데요. 몸 쓰는 게임의 대표 주자라면 역시...

출처 : 위키피디아

이 물건이 아닐까 합니다. 첫 작품이 나온지 20년이 다 되가는 게임입니다. 바로 Pump it up!

저는 괴수는 아니라서 보통 남들 하는 레빌7~9 정도에서 놀지만 그것도 상당히 땀이 많이 납니다. 사실 이렇게 땀 빼는 것 감안하면 대략 2000원 정도의 게임을 하면(한 번에 500원 일 경우 - 3곡씩 하게 되니까 총 12곡)어마어마한 칼로리 소모 및 입에서 단내(...)가 날 정도의 느낌이 듭니다.

리듬게임의 시초는 잘 모르겠지만 이를 대중화 한 것은 일본의 코나미입니다. 사실 Pump it up도 DanceDanceRevolution(이하 DDR)의 카피캣이었는데 어쩌다보니 크로스 라이센스가 걸리게 되어서 둘이 공생하는 관계가 되었습니다. 오랜 시간이 지나면서 둘의 게임성이 확연히 달라지기도 했고, 오랜 기간동안 발전과정을 본 Pump it up과는 다르게 DDR은 정발판이 들어왔음에도 그렇게 썩 재미있지는 않더라구요.

(사실 DDR은 정 박을 밟는 것을 중요시 여긴다면 Pump it up은 그냥 몸을 배배 꼬게 만드는 것으로 어렵게 만듭니다. 문제는 몸이 날아다니는 수준이어야 할 정도로 미친 듯이 뛰어야 합니다. 그에비해 DDR은 몇몇을 제외하면 미친 듯이 뛸 일은 별로 없습니다.)

사실 이외에도 리듬게임같이 인간 한계를 시험하는 게임을(...) 상당히 좋아해서 오락실에 가면 유비트도 같이 하는데요.

출처 - 위키피디아 리듬게임 갖다놓은 오락실치고 이거 없는 오락실은 거의 없더라. 그만큼 인기 있는 리듬게임(이자 입문용 게임)

DDR이나 Pump it up이 발판형이면 이건 터치형입니다. 사실 투명한 버튼이라고 하는 것이 맞는 것 같기는 하지만 게임내에서 터치라고 하니까 터치라고 합시다.(터치라고 해서 스마트폰용 리듬게임하듯이 그냥 쓰다듬으면 인식 안됩니다. 버튼처럼 눌러야 합니다. 이게 무슨 터치야)

터치형의 특징은 화면에 보이는 것을 직접 누른다는 것이 있습니다. 그래서 화면을 보면서 버튼을 찾아 눌러야 하는 건반형이나 비슷하게 발판을 누르는 발판형과는 다르게 상당히 직관적입니다. 초보자들도 대충 넣고 튜토리얼도 없이 그냥 게임을 해도 어렵지 않을 수준이니까요.

무엇보다 터치형은 스마트폰이 대두되면서 Deemo나 탭소닉같은 모바일 리듬게임이 나오면서 사람들에게 익숙해진 방식이기도 합니다.

모바일용 리듬게임 중 하나인 Deemo 모바일게임이 그렇듯이 터치형이다. 출처 - 리그베다위키

터치형과 발판형(혹은 건반형) 리듬게임을 하다보면 한 가지 큰 차이가 느껴집니다. 가끔 내가 엉뚱한 곳을 두드릴때가 있다는 것! 눈이 화면에 고정되어있다보니 벌어지는 현상입니다. 눈은 화면을 봐야하다보니 손이나 발이 "이 정도만 움직이면 되겠지"하고 움직이는 것에 의존 할 수밖에 없습니다. 처음 가는 오락실에서 하다보면 거리 인식이 덜 되어서 Pump it up 발판에서 떨어지기도 합니다... EZ2DJ나 BeatmaniaIIDX같은 버튼식은 처음 했을때에는 멀쩡한 바닥을 누르기도 했고요.

하지만 터치형은 그럴일이 상당히 적습니다. 눈이 손의 위치를 보정해주니까요. 터치형 게임 중 제일 대부라 할 수 있는 (하지만 지금은 관에 들어간) Djmax Technika의 경우 리듬게임 치곤 쉽다는 소리를 많이 들었습니다. 사실 그리 쉬운 게임이 아니었는데도 "일단 눈에 보이는 대로 누른다.= 몸으로 익힐 시간이 줄어든다." 바로 이거입니다.

터치형 리듬게임의 대중화를 이룬 Djmax Technika시리즈. 지금은 그냥 사망처리... 그래도 이거 없었으면 지금의 유비트나 리플렉비트같은 터치형 리듬게임이 나오기는 힘들었을 거라는게 게이머들 생각이다.

....얼마 전에 유비트와 Pump it up을 하면서 느낀 것인데 이 둘을 섞으면 어떨까? 라는 생각을 했습니다. Pump it up이야 워낙 나온지 오래되었고 익숙해서 사람들이 곧 잘하기는 하지만 처음 하거나 오랜만에 하는 사람들은 발판 위치 잡는 것을 상당히 곤혹스러워 하는 것을 많이 봤습니다. (특히 철판 때리는 소리가 들리면 100%입니다. 혹은 우당탕 소리나면서 떨어지기도...)

그러면서 생각이 든건데 유비트 처럼 발판을 보면서 발판에 뜨는 마커에 맞춰서 발로 밟게 하면 어떨까? 라는 생각을 했습니다. 즉, 터치형+발판형인 것입니다. 아니면 그냥 유비트 컨트롤러를 크게 만든 다음 발로 밟게 만들어도 되겠네요. (..4x4니까 16개... 날아다니는 것이 아니라 그냥 분신술을 써야 하는 거 아닌가?)

물론 그 만큼의 큰 대형 화면을 바닥에 깔아버릴라면 돈이....들기야 하겠지만 대형 디스플레이 가격도 많이 떨어졌고 만들려면 충분히 만들 수는 있다는 생각이 듭니다.

그리고 무엇보다 유비트를 크게 만들어서 바닥에 깔아버린다면.........외계인 색출 게임 확정! 전 원래 인간한계에 도전하는 게임을 좋아하니까 있다면 한번 해보고 싶네요.

어찌되었건 생각뿐이기는 한데 압전소자가 제 손에 들어오면서 제 손으로 만들게 될 날이 올 수도 있습니다....어떻게 될 수 있을지는...으음...?

http://blog.daum.net/moor/50

이 글은 과거 제가 했었던 삽질을 다시 정리해서 올리는 글입니다. 디제이맥스 트릴로지처럼 USB동글을 써야 하는 프로그램 구동에 도움이 되기를 바랍니다.

이 게임을 기억하시는 분들이 아직은 많으리라 믿습니다. 비록 죽어버리기는 했지만 2008년 출시된 게임치고 지금도 꿀리지 않는 명작 디제이맥스 트릴로지입니다.

이 게임의 특징으로 USB형 동글을 사용해서 복돌을 막았다는 것인데요. 2012년경에 어이없는 방법으로 뚫려버리기는 했지만(USB가 뚫린 것이 아니라, 실행파일 해킹으로 풀려버렸음)그럭저럭 복돌이를 잘 막았다고 하는 물건입니다.

2011년에 제가 갖은 삽질을 통해서 트릴로지가 Wine을 통해서 구동이 된다는 사실을 확인하기는 했는데, 이를 다시 정리해서 USB인식까지 방법을 깨끗하게 정리하고자 합니다. 참고로 OpenGL 2.1이상이 지원되어야 그래픽이 정리가 됩니다.구형 드라이버를 사용하시거나 지원이 안 되는 그래픽 칩셋을 사용하신다면 아래와 같은 이미지만 보게 됩니다.

그래픽 드라이버의 경우 오픈소스 드라이버도 별 문제없이 잘 실행되는 것이 확인되니 그냥 업데이트만 꾸준히 해주시면 별 문제는 없을 것입니다.

그래픽이야 그렇게 큰 문제는 되지 않습니다. D3D->OpenGL이 그렇게 큰 부하가 걸리는 것도 아닌데다가 2008년 게임이라 지금 기기성능이라면 별 문제는 없습니다. 제일 큰 문제는 USB인식 입니다. 그냥 눈 딱 감고 크랙을 쓰면 USB인식 문제가 한번에 해결되지만, 정품을 이용하자는 취지에 맞게 USB를 인식시켜보도록 하겠습니다.

http://wiki.winehq.org/USB

여기에 가보시면 USB인식에 관한 글이 올라와 있습니다. ftp://ftp.etersoft.ru/pub/people/amorozov/usb/

여기에 있는 패치를 한 와인을 써서 USB 인식을 하게 하면 됩니다.

우선 와인의 소스코드를 받아야겠지요?

http://sourceforge.net/projects/wine/files/Source/

여기서 와인의 소스코드를 다운로드 받도록 합시다. 와인 패치가 1.5.3이 마지막으로 되어있는 것으로 봐서는 이후 버전에서는 지원할 생각이 없어 보입니다. 소스코드도 1.5.3을 이용합시다. 그리고 ftp://ftp.etersoft.ru/pub/people/amorozov/usb/ 이곳에서 1.5.3버전의 2개의 패치 파일을 다운로드 받아서 와인의 소스코드가 있는 곳으로 던져넣읍시다.

해당 서버가 접속이 안 될 경우 여기서 받으세요. wine 1.4.1용은 1.4.1(안정버전)에서 굴려야 할 경우, 1.5.7버전은 etersoft에서 지원한 최종 버전입니다.

wine1.4.1for_usb_patch.tar.gz

wine1.5.7_for_usb_patch.tar.gz

그리고 터미널을 열고 소스코드가 있는 곳으로 찾아간 뒤에

patch -p1 > 0001 ~~~

patch -p1 > 0002 ~~~~

라고 해주시면 패치가 완료 됩니다. 그리고 그대로 make를 해주시면 와인이 컴파일이 완료 됩니다.

아무래도 그냥 make 보다는 deb으로 만드는 것이 편하니까

dh_make -r

fakeroot debian/rules binary

위의 명령으로 deb으로 만들어줄 수 있으며 이를 설치해서 써도 되지만 그냥 PlayonLinux를 이용하는 것이 제일 좋은 방법입니다.

노틸러스나 컹커러로
~/.PlayOnLinux/wine 여기에 들어가 보면 linux-x86과 linux-amd64가 있는데, 32비트면 x86일 것이고 64비트면 amd64로 컴파일 되었을 테니 해당 폴더 안에 대충 1.5.3-usb 등으로 폴더를 만든뒤에 deb의 압축을 풀어버립시다.

그리고 Playonlinux에서 설치를 누르고 리스트에 없는 설치(install a non-listed program)를 누른다음 Install a new prefix -> 대충 Prefix이름을 적고-> Use another version of Wine을 이용해서 아까 압축 풀었던 1.5.3-usb를 선택하도록 합시다.

그렴 이제 USB 지원 Wine으로 트릴로지를 설치할 준비가 되었습니다.

그런데 우선 해야할 일이 있다. 트릴로지를 우선 Setup하지 말고 USBSETUP 폴더 안에 있는 USB드라이버를 우선 선택해야만 한다. 그 이유는 게임 설치 후에 드라이버 설치 할 때 게임 인스톨러가 에러가 나는데 미리 드라이버를 설치해 두면 드라이버 설치를 무시하고 넘어 갈 수가 있다. 우선 USBSETUP을 합시다.

granddog.reg

그리고 Playonloinux의 구성버튼을 누르고 트릴로지 설치 Prefix를 선택한 후 레지스트리 에디터를 버튼을 누르면 윈도에서 봤던 것과 같은 레지스트리 에디터가 뜹니다.

위의 레지스트리 파일을 다운로드 받은다음 레지스트리 에디터에서 파일-레지스트리 가져오기를 누르고 위의 파일을 선택하면 레지스트리가 등록이 됩니다.

Run a.exe ~~~버튼을 누르고 트릴로지 Setup.exe를 선택하면 이제 본격적으로 게임을 설치 할 수 있게 되는데, 마지막 드라이버 설치시에 주의사항이 있습니다. 파일을 덮어씌울 것인지 물어볼 때 무조건 "아니오"를 눌러주셔야 합니다. "예"를 누르는 순간 에러가 나면서 설치가 취소됩니다.

그리고 마지막으로 수동으로 패치를 해주시면 트릴로지가 리눅스에서 실행되는 것을 보실 수 있습니다.

이렇게 말이지요~

스크린샷은 2010년 당시의 스크린샷입니다. 하지만 똑같이 실행된답니다.

사운드 싱크에 문제가 있을 수 있는데 Pulse-Audio를 삭제해 주시거나 Wine에 Pulse-audio 패치를 해주시면(...)싱크 밀림을 막을 수 있습니다. Pulse-audio를 삭제하는 것이 가장 싱크밀림을 확실히 잡을 수 있는 방법인데, 대신 오디오관련 설정이 엄청 꼬입니다. Pulse-audio관련 패치를 하는 방법은 조금 레이턴시를 잡을 수는 있지만 Alsa-Pulseaudio의 오버헤드는 여전해서 미묘한 싱크 밀림이 생깁니다. 게다가 가뜩이나 USB관련 패치를 한 데다가 미리 패치를 하지 않은 죄로 컴파일을 또 해야하는 불상사가 생깁니다. 

그냥 오디오 꼬이는 것은 적응의 문제 혹은 삽질이라고 생각하고 Pulse-audio를 삭제해봅시다. 우분투나 Pulse-audio쓰지 다른 배포판은 그냥 Alsa만 쓰기 때문에 일부 동영상 플레이어를 제외하면 딱히 호환 문제는 없습니다.

Pulse-audio 삭제법은 나중에 포스팅 하기로 하고, 이상 리눅스에서 트릴로지 실행하는 법을 알아보았습니다. Wine패치하기 어려우신 분들은 그냥 세이브를 다시 해야하는 문제가 있기는 하지만 No-USB패치 하시는 것도 나쁘지는 않다고 생각합니다. 단, 어디까지나 정품 이용!

오늘의 글은 정말 말 많고 탈 많은 AMD(구 ATI)의 리눅스 지원에 대한 글입니다.

감정적으로 엄청 까는 글이므로 보시기 싫으신 분들은 봐주시지 않으셨으면 좋겠습니다. 까는 글이므로 그림이나 사진을 넣는 것을 최대한 뺴려고 합니다. 정말 화가 머리끝까지 솟구쳐서 하는 이야기이므로 AMD그래픽을 좋아하신다면 반대로 화가 나실 수도 있습니다.

우선 AMD로 인수되기 이전의 말 많고 탈 많은 이야기부터 시작합니다.

리눅스나 BSD 계열은 예전에는 많은 양의 3D 그래픽을 요구하지는 않았습니다. 그 정도의 3D 연산을 요구하는 프로그램이래봐야 CATIA (~v4) 정도? 였습니다. 그나마도 3D CAD프로그램은 워크스테이션 여러대를 이어서 돌리는 것이었으니 지금과 같은 직접적인 GPU연산을 필요로 하지는 않았습니다. 그냥 OpenGL가속에 도움이 되는 정도 였습니다. 물론 이 당시에 fglrx라는 놈이 ATI사에서 개발되어서 유닉스 기반 3D연산에 상당히 도움이 되기는 했습니다. 90년대의 3D CAD관련 글을 보면 이에 대한 글이 있을 정도로 fglrx는 고마운 존재였다고 합니다. 물론 ATI의 그래픽 중에서도 FireGL그래픽카드만 적용 가능했지만 당시의 3D CAD는 고가였고 전문가만이 사용가능한 프로그램이었습니다. 그 외의 3D 연산을 필요로 하는 것은 게임 정도였지만 당시의 유닉스는 게임을 돌릴 이유가 없었습니다. 애초에 3D게임도 많이 부족했습니다.제대로 된 3D 게임은 95년쯤에야 나왔으니까요.

그러던 어느날 리눅스 데스크탑이 시장에 나오고 갑자기 뜨기 시작했습니다. 하지만 이 당시에도 리눅스 데스크탑은 중요한 위치에 있지 않았고 3D 가속은 안중에도 없었습니다. 그 당시에는 멀티미디어가 주류였고 이 당시에 Mplayer 같은 놈들이 개발되어서 애용되어집니다. 3D 연산은 필요했지만 있으면 좋고 없으면 말고 수준이었습니다. 리눅스를 사용하는데 필수는 아니었으니까요. 리눅스 데스크탑이 나오고 X의 발전이 이루어졌지만 당시의 X는 2D 가속에 초점이 맞추어져 있었습니다. 그리고 각종 그래픽 칩셋의 프레임버퍼 드라이버들이 세상에 나와서 X에 들러붙게 됩니다. (nv, ati, tdfx, i810 등등의 이름으로 나왔습니다. 척 보기에도 어떤 그래픽드라이버인지 알 수 있지요?) 당시의 커널은 오로지 프레임버퍼만 제공했던 것으로 기억합니다. GUI뿐만 아니라 2D 프레임 버퍼도 X의 유저모드로 전부 제공했기에 xorg.conf 파일(X설정 파일)은 하나라도 잘못 설정하면 그냥 데스크탑 전체가 바보가 되버리는 어마어마한 양의 설정 파일이었습니다. 하지만 이것도 크게 중요하지는 않았습니다. 일단 GUI만 띄우는 데에도 엄청난 노력이 필요했으니까요. 물론 이 때에도 fglrx나 nvidia 같은 바이너리형 독점 드라이버들이 있기는 했습니다. 쓰는 사람만 썼기에 그렇지...

그러던 어느날....

2005년이었던 것으로 기억합니다. 아니, 2004년이었나? 오픈수세로 유명한 노벨이라는 기업에서 XGL이라는 것을 발표하고 공개를 했습니다. 그리고는 3D 가속환경하에서 엄청난 데스크탑 효과를 보여주며 GUI란 이런 것이라고 보여주게 됩니다. 지금의 윈도7,8의 창 효과정도는 버로우 시킬 정도의 화려한 효과였습니다. 사실 맥에서는 이와 비슷한 효과를 이미 사용하고 있었습니다. 이를 따라한 것이기는 한데, 역으로 말하면 리눅스 데스크탑에서도 맥처럼 상시 그래픽 가속이 가능하다는 이야기가 됩니다. 덕분에 리눅스 커뮤니티에서는 이를 적용하기 위해서 삽들을 뺴들기 시작했고 폭발하기 시작했습니다. 이후 이 3D데스크탑 효과기능은 Beryl등의 이름을 거쳐서 Compiz-Fusion이란 이름으로 나오게 되는데 이 당시의 삽질은 정말 어마어마했습니다. 각 리눅스 배포판들은 이를 적용하려면 XGL을 기존의 X를 버리고 설치해야 했는데 이게 꽤 엄청난 삽질이었거든요.XGL을 성공적으로 설치했다고 한들, 그래픽 드라이버가 DRI(즉, 직접 렌더링)이 지원되지 않으면 말짱 꽝이었습니다. 드라이버 소스가 공개되어있던 인텔을 제외한 다른 오픈소스 드라이버들은 DRI가 잘 안 되었고, 자신의 칩셋에 대해 잘 아는 회사들만이 드라이버를 내놓을 수 있었습니다. 이 때 빠르게 드라이버를 내놓은 곳은 여전히 fglrx란 이름으로 내놓았던 ATI였지만, 무슨 생각이었는지 Compiz가 말을 안 듣는다거나 커널패닉을 일으키거나 하는 이유로 말썽을 일으키게 됩니다. 반대로 Nvidia는 무슨 짓을 한 것인지, 굉장히 안정적인 드라이버를 내놓습니다. 지금도 비슷하지만 워낙 ATI의 드라이버가 막장이었기에 멀쩡한 ATI카드를 버리고 한 단계 낮은 Nvidia카드로 갈아타는 사람도 있었습니다.

XGL적용삽질이 한창 이루어질 때 즈음, 리눅스계의 독보적인 기업인 레드햇에서 GLX라는 것을 내놓게 됩니다. XGL과 이름이 비슷하지요? 기능은 사실상 동일 하지만 이는 기존 X를 갈아치우지 않고 X에 패치형태로 적용한 물건입니다. 즉, XGL이 기존 X와 어느정도 호환성을 갖추고 쌓아올린 물건이면 GLX는 기존 X를 이리저리 개조해서 만든 물건이라는 것이지요. 그리고 Compiz는 둘 다 적용 가능하게끔 개발이 이루어지게 되어서 배포판은 선택의 기로에 서게 됩니다. 이 선택의 기로는 그래픽 드라이버도 마찬가지였다고 합니다. 예전부터 fglrx를 내놓던 ATI는 XGL을 선택했고 Nvidia는 GLX 쪽으로 가닥을 잡았던 듯 합니다. 하지만 웃긴 것은 GLX를 쓰던 XGL을 쓰던 Nvidia는 별 문제가 없었는데, ATI는 GLX를 쓰면 난리를 쳤습니다. 드라이버 개발능력이 경쟁사보다 딸리는 것인지 대체...

2007년에 가장 다운로드수가 높았던 배포판인 우분투는 XGL과 GLX 둘 다 가능하게끔 설정을 하기는 했는데, 이 당시의 글을 보면 독점 드라이버 설치가 정말 거지같았던 것을 알 수 있습니다. 이리하면 저곳에서 뻑나고 저리하면 이쪽에서 뻑나고 커널 업데이트하면 또 뻑나고...어휴... 그리고 Compiz(당시는 Beryl이었나요?)를 설치하면 그대로 GUI가 사라지는 등...캐노니컬에서도 이를 인지 했는지 이후 8.04라는 역대 최고의 안정적인 버전이 나오면서 그래픽드라이버 설정을 간단하게 마우스 한 두번 클릭으로 바꾸고(아니면 설치 중에 드라이버 설치 한다고 물어봅니다. 지금도 그렇기는 하지만)기본 3D X환경을 GLX로 가게 됩니다. 그리고는 Compiz를 기본 탑재해버립니다. 그 덕이었을까요? 다른 배포판 들도 XGL대신 GLX를 선택해버리고(사실 기존 X를 개조한 수준이라 딱히 수정할 곳이 없어서 그냥 X를 설치하면 되니까 XGL에 비해 메리트가 있었습니다.) XGL에 별다른 메일링이 없어져 버렸습니다. 즉, XGL이 도태되어져 버린 것입니다. 덕분에 ATI는 발등에 불 떨어졌지요. GLX만 쓰면 난리를 쳐대는데, 이를 해결해야 했으니까요. 당시의 회고에 따르면 fglrx만 설치하고 Compiz환경으로 만들면 그대로 하얀화면으로 되어버리는데, 우분투는 기본적으로 compiz를 쓰다보니 우분투를 쓰면서 fglrx를 쓸 수가 없었다고 합니다.그나마 오픈수세는 XGL을 탑재했다보니 큰 문제는 없었는데, 이마저도 XGL이 도태되면서 노벨에서도 GLX를 적용한 X를 탑재하기에 이르릅니다. 그동안 ATI는 삽질을 계속했습니다.

당시의 드라이버에 대해 말씀드리지면 윈도용 Catalyst는 물론이고 리눅스의 fglrx도 해커들이 개조를 해야 쓸만하다는 평을 들을 정도로 참 드라이버가 막장이었습니다. 윈도용도 막장이었는데, 개발팀이 훨씬 적은 리눅스, 유닉스 용은 뭐...말을 말아야지요.

그래서였는지, ATI는 중대 발표를 해버립니다. 나온지 3년 밖에 안 된 X시리즈(R500)까지의 드라이버 지원을 중단 하겠다고 선언을 해버립니다. 즉, 과거의 칩셋에 대한 지원을 끊음으로써 드라이버 개발에 더 많은 지원을 하겠다는 것이지요. 이는 윈도+리눅스+기타 OS 전부 통하는 이야기였습니다. 그리고 정말로 드라이버가 개변한 시기는 AMD에 인수되고 몇 년 지난 2013년이 되어서야 쓸 말한 드라이버소리를 듣게 됩니다. 과연 이것이 잘 한 것인지 아니면 무리수였는지는 모르겠지만, 덕분에 당시 나온지 3년밖에 안 된 X시리즈 사용자들은 엿을 먹게 되었습니다. 드라이버 지원은 레거시라는 이름 하에 해주겠다고 했지만 그나마도 2009년에 끊었습니다. 윈도는 어땠냐구요? 기존에 제공된 드라이버 해킹해서 적용하고 있습니다. 무슨 We Are The World도 아니고...

이 무렵 Nvidia는 그냥 쿨하게 싹 다 지원하는 방향으로 가게 됩니다. 8800GT가 나오면서 이전의 드라이버를 끊기는 했지만, 이전 드라이버들이 최신 OS에 적용할 수 있게끔 지원을 해줍니다. 예를 들이서 96.xx 버전은 XP까지만 지원이 가능한 드라이버지만 윈도8에서 설치가 되게 끔 해주는 것입니다. 실제로 96.xx 버전을 윈도8에서 설치하면 지원 하드웨어(즉, Geforce 4 이전의 물건)의 구동이 무리없이 됨을 알 수 있습니다. (물론 완벽하지는 않아서 버그가 있기는 합니다.) 그에비해 Catalyst는 이 짓을 하면....까만화면을 보게 됩니다.(OS 가리지 않는 WDM기반이라며? 이건 대체...???)리눅스도 사정이 비슷해서 지금도 구형 하드웨어에 최신 우분투를 설치하면 Nvidia칩셋이라면 상당히 구버전인 96.xx나 1xx.xx 를 설치 할 수 있게끔 되어있습니다. ATI칩은???? 안 되요. 설치하면 까만화면만 보게됩니다.

자 아까 GLX와 XGL 지원에 대한 이야기를 잠깐 했었지요? ATI는 XGL위주로 가게 되었는데 XGL이 도태되면서 하는 수 없이 GLX지원으로 방향을 틀게 되고 이는 어마어마한 버그의 향연으로 이루어지게 됩니다. 한달에 하나씩 나오는 주제에 버그가 수정되지도 않은채 나오기도 하고(hex 에디터로 수정해서 쓰는 사람도 있었습니다. 물론 방법을 공개했으니 이를 배포판에서 적용해서 내놓기도 했습니다. 이게 어떻게 독점 드라이버지...?) 경쟁사는 어땠을까요? Nvidia는 GLX를 쓰던지 XGL을 쓰던지 큰 문제는 벌어지지 않았습니다. 그러니 GLX로 넘어가더라도 XGL관련 코드만 삭제하면 그만이었으니 문제는 전혀 없었습니다. 이 쯤되면 ATI는 욕을 바가지로 퍼 먹어도 할 말 없습니다. 덕분에 리눅스는 당시의 인텔2D가속 문제와 함께(당시 인텔은 동영상 티어링 문제로 말이 많았습니다.) 무조건 Nvidia라는 분위기가 형성되게 됩니다. 이후에 인텔의 문제가 해결되며 문제를 일으키는 GPU제조사는 ATI뿐이었습니다.(다른 S3등은 제조사 도움없는 오픈소스 드라이버 뿐이었으니 무시합시다. - 인텔은 제조사 도움을 받는 오픈소스 드라이버였음)

이후 ATI가 AMD에 인수되며 자금사정이 나아지며 드라이버 지원이 나아지는 듯 했습니다. 하지만 현실은 시궁창. Nvidia가 각종 삽질을 하고 AMD에 비해 높은 가격을 받지만, 리눅스에서는 여전히 Nvidia가 선택 될 수밖에 없습니다. 물론 ATI가 R500이하 시리즈의 드라이버 지원을 끊을 때, 기술문서를 공개 함으로써 오픈소스 드라이버 개발지원을 해주기는 했습니다. 그래서 오픈소스드라이버가 개선되어졌냐고 하면 Catalyst 설치시의 40%성능도 채 안 나옵니다. 제가 보기에는 그냥 지들이 드라이버 개발능력이 안 되니까 커뮤니티에 떠 넘긴듯한 인상이 듭니다. AMD로 넘어간 지금도 사정이 거기서 거기라 Catalyst가 안 돌아가면 고성능 3D 연산은 포기해야 합니다.

제가 리눅스를 쓰면서 언제나 느끼는 것이지만 다시는 ATI(AMD)칩 쓰는 하드웨어는 이제 안 사려고 합니다. 이 고통은 그냥 돈으로 해결하는 것이 답일 듯 합니다. 아무리 칩을 잘 만들면 뭐합니까? 아무리 싸게 내놓으면 뭐 합니까? 제가 쓰기에 불편하면 그건 그냥 실리콘 덩어리입니다. 하드웨어 설계능력이 좋아도 소프트웨어가 거지같으면 병신 된다는 것을 너무 뼈저리게 느끼고 있습니다. 더군다나 리눅스는 하드웨어를 보통 안 바꾸니 (서버 위주로 사용하면서 일부 계층은 최적화를 중시한다는 것을 감안합시다.)소프트웨어 지원이 절실한데 리눅스를 윈도지원 하듯이 하는 것은 아니라고 봅니다. 다시는..다시는 안 쓸겁니다. AMD GPU...

최근 갑작스런 일 폭풍에 9월 중 블로그 활동이 바닥을 치고 있습니다. 오늘 밤샘작업(...)을 끝내고 간만에 티스토리에 접속했더니 방문자수가 급증했더군요. 글도 안 올렸는데?

갑작스럽게 방문자수가 폭발했기에 확인 해봤더니 원인은 역시나 우분투도 아니고, 또 Long Live The Queen 관련....

오늘 메일을 보니 그럴만한 이유가 있었더군요.

험블에 떴으니 구입하실 분은 당장 해외결제 체크카드를 만들어서 지르시길. (VISA체크카드는 외환이나 신한 계좌 하나 트면서 달라고하면 청소년도 그냥 줍니다.)

험블번들 Weekly에 Long Live The Queen이 떴군요. 물론 평균가 이상 돈을 내야 하지만 워낙 평균가가 껌값(...$6...라니...)인 관계로 많이 구입하신 것 같습니다. 그러다 한글패치 검색을 통해서 이리저리 흘러들어오신 것 같습니다.

그런데...여긴 한글패치가 있는 장소가 아니거든요. 본 한글패치의 개선패치가 있을 뿐입니다. 한글패치의 DLC라고 할까?

다시 한번 말씀드리지만 한글패치는

http://ghap.tistory.com/entry/LONG-LIVE-THE-QUEEN-%ED%95%9C%EA%B8%80-%ED%8C%A8%EC%B9%98-%ED%8C%8C%EC%9D%BC%EC%9E%85%EB%8B%88%EB%8B%A4

여기 있습니다. 제 패치는 일종의 한글패치 확장입니다. Ghap님 패치 없이 제 패치해봐야 한글로 게임 안 되요~ (물론 일부는 되기는 합니다만, 애초에 대사가 한글화가 안 되는데...)

무엇보다 제 패치는 렌파이를 통짜로 교체하는 위험이 좀 있어서 혹시라도 엔진이 꼬이거나 하면 재설치를 해야 합니다. 용량이 작아서 금방되기는 하지만 스팀이 워낙 느려터졌으니...

엔진패치도 문제없다고 생각하신다면 해주시면 좋습니다.

참고로... 엔진을 그냥 버전만 교체하는 것이 아니라 중복 번역을 해결하기 위해 커스터마이징된 엔진이 올라올 예정입니다. 그리고 마찬가지로 그 엔진에 포팅작업을 한 스크립트 패치도 올라올 예정이고요. (별건 아니고 그냥 엔진 교체랑 다를 것은 없습니다.)엔진교체 없이 중복번역을 해결해 보려 했는데 답이 좀처럼 안 나와서 그냥 엔진에 손을 대서 중복 번역을 해결하기로 했습니다. 이제 일 폭풍이 잠시 끝났으니 중복 번역 관련 엔진 수정을 시작하려 합니다. 그래봐야 say함수 구겨버리고 말겠지만.