기본 콘텐츠로 건너뛰기

추천 가젯

Tmux 환경에서 Vim 컴파일 시 발생하는 termio/termios 감지 오류 해결 방법

 리눅스 환경에서 소스코드를 직접 빌드하다 보면 의외의 환경 변수나 터미널 세션 설정 때문에 엉뚱한 빌드 에러를 마주할 때가 있습니다. 대표적인 예로 Tmux 세션 내부에서 Vim 소스를 컴파일할 때 발생하는 termio/termios 감지 오류 가 있습니다. 이번 글에서는 해당 에러가 발생하는 원인과, 단순한 clean 으로는 해결되지 않는 이유 및 올바른 해결 방법을 정리합니다. 1. 문제 원인 Vim의 소스 코드 빌드 과정( configure )은 시스템이 System V 계열인지 Linux 계열인지 판별하기 위해 termio.h 와 termios.h 헤더 파일 및 터미널 인터페이스를 검사(Probe)합니다. 하지만 Tmux 내부(세션 안)에서 컴파일을 진행할 경우 , Tmux가 제공하는 PTY(Pseudo-Terminal) 환경과 TERM=screen 등의 특수한 환경 변수 영향으로 인해 Autoconf가 터미널 인터페이스를 검출하는 과정에서 오동작을 일으킵니다. 그 결과, 실제 시스템 조건과 무관하게 설정 에러를 발생시키게 됩니다. 2. 왜 make clean 으로는 해결되지 않을까? 일반적인 개발 과정에서는 빌드가 꼬였을 때 make clean 을 실행하곤 합니다. 하지만 make clean 은 컴파일된 오브젝트 파일이나 바이너리( .o 파일 등)만 삭제할 뿐, Autotools가 시스템 환경을 탐색한 결과로 남긴 캐시( config.cache 또는 내부 매크로 변수)나 설정 파일들은 그대로 유지 합니다. 일반적인 상황에서는 시스템의 하드웨어/OS 정보가 바뀌지 않기 때문에 이 잔여물이 문제가 되지 않습니다. 그러나 Tmux나 Screen 같은 터미널 멀티플렉서 환경에서 탐색된 왜곡된 정보가 캐시에 박혀버리면, 나중에 Tmux 외부(일반 터미널)로 나와서 빌드를 시도해도 이전의 오염된 캐시 때문에 계속해서 오류가 발생하게 됩니다. 3. 해결 방법 이 문제를 해결하기 위해서는 반드시 Tmux 외부 환경 에서 기존의 오염된 설정 파일을 ...

우분투 리눅스에서 모니터 오버클락하기.

 

리눅스에서 디스플레이 해상도 등과 관련된 패키지는 xrandr이다. 


xrandr을 통해 다양한 display mode를 체험할 수 있다. 


지금 현재 사용하고 있는, 모니터는 DELL 2312HM으로 홈페이지상 스펙으로는  1920x1080  60이 한계인 것으로 나타난다. 


처음 xrandr을 누르면, 이 이하의 설정가능한 다양한 해상도 등이 나온다. 

1080x1024 75.02 60 

640x480 75 59.94 

등이 나오는데, 이 값들은 일종의 디스플레이 업계의 약속된 추천해상도라고 할 수 있다. 


윈도우 시스템의 경우는 드라이버에 따라서, 굉장히 다양한 해상도 설정이 가능한 경우가 있는데, 이 해상도들은, 일종의 업계 호환해상도라고 할 수 있다. 


이 호환 해상도에 해당하는 것이 바로 gtf, cvt라는 것이다. (위키에 검색해보시오)


여기에는 그래픽카드에서 모니터로 신호를 보낼 때, 어떤 주파수로 신호를 보내고, 어디서부터 어디까지인지 신호를 보낼지에 대한 일종의 약속이다. 이 신호는 결국 픽셀정보를 직렬로 보내다보니 직사각형의 화면정보를 열별로 나누어 보내게 되고,  어디부터 시작인지 어디가 끝인지, 열의 시작과 끝이 어디인지 및 몇가지 정보전달을 위한  위한 메타데이터를 필요로 하게되고 이러한 값들이 직사각형 정보덩어리의  테두리 여백으로 들어가게 된다. 

기본 규약은 어차피 자동으로 처리가 되므로 필요한 것은 저 호환 해상도에 해당하는 gtf와 cvt이다. 

리눅스의 경우 gtf를 누르면 다음처럼 나오고,

원하는 해상도를 입력하면 다음처럼 나온다. 

cvt의 경우도 마찬가지이다. 




이렇게 얻은 정보를 가지고 xrandr를 사용하여 추가하여 사용할 수 있다. (싱글모니터는 요렇게하지만 듀얼부터는 몇자를 더적어야)

Modeline 뒷 정보를 다음처럼,
xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
xrandr --addmode "1920x1080_60.00"

xrandr --mode "1920x1080_60.00"



자 이제부터 모니터 오버클럭이야기를 해보자. 


원래부터 지원되는 해상도임에도 불구하고 저렇게 입력하면, dvi single link나(대부분 와이드 해상도 면... 맞아...) 오래된 hdmi 버전을 쓰는 모니터는 먹통이 된다.   저 첫번째 숫자부분이 165를 넘어가면 먹통이 된다. (내 테스트는 164도 먹통이었음 163.xx까지는 잘 되었음. 이 현상은 케이블 먹통이라 하자.) 

 당연히 약속이 잘되어 있는 친구들이, 메타데이터가 덜 필요하다. 약속만 되어 있으면, 봉화 몇개로도, 전쟁유무가 파악되는 법 ...  

예비약속이다보니, 더 많은 정보가 필요하다.  


이 예비약속들만으로는 되지 않는다. 윈도우 처럼 넘실거리는 수많은 모니터 해상도 지원은 가능하지만, 오버클럭은 불가능하다. 

아날로그 시대에 비해 디지털 시대에 HD가 붙기 시작하는 친구들은 해상도가 더 큰 편이다보니, 메타데이터를 잘 접어서 구석에  넣는 방법이 생겼다. 

(이 문장은 내 개인 추측이다. 틀렸을 수 있다. )

그 방법을 cvt-rb 방식이라 한다. 

https://en.wikipedia.org/wiki/Coordinated_Video_Timings#Reduced_blanking 

우분투에서는 cvt-rb 방식을 apt로 받는 cvt에서 지원을 한다. 


보면 알겠지만, 갑자기 165MHz까지 가기에는 많이 남게된다. 

그런데 안타깝게도, 이 규약은 원래 나올 때, 60Hz의 배수만을 지원하기 위해 나왔다. (아마 표준 나오고 빠른 모니터가 너무 빨리 나왔을때 나온걸로 보인다)

그러다보니 이툴은 60-120hz사이의 다른값들을 쓰기에 부적절하다. 뭐 구글에 linux monitor overclock이라 검색하면 수정된 cvt와 더 다르게 구겨넣는  방식인 cvt-rb2까지 지원하는 녀석이 깃헛에 있음을 알 수 있다. 

❯ wget http://www.uruk.org/~erich/projects/cvt/cvt.c

$ curl https://raw.githubusercontent.com/kevinlekiller/cvt_modeline_calculator_12/master/cvt12.c --output cvt12.c

Compilation:

$ gcc cvt12.c -O2 -o cvt12 -lm -Wall

앞 친구는 60hz 배수를 써야하는 규약을 무시하고 중간 친구들을 만들어주고, 뒷친구는 cvt-rb2까지 지원을 하는 친구인데 뒤에걸 일단 쓰는 걸로 하자. 뒤에 것은 c 옵션으로 강제조항이 있다. 

그 방법을 통해 60까지 지원하는 h2312hm을 


Modeline "1920x1080_73.86_rb2"  164.99 까지 올렸다. 

일단 강제조항을 써서 얻은 cvt-rb는 dell이 나름 메인스트림 회사라 지원을 제대로 안한다. 이상한 회사라면 지원했을 수도 있어서 .. 75성공했을텐데... 


일단 dvi-d sigle-link에서는 이 이상 올릴 수가 없다. 

일단 저위에 그림처럼, 24라는 표준 깜빡임의 배수로 설정할 예정이다만, 저정도로 가득채워서 올릴 수 있다. 


나중에 display port를 지원하는 그래픽카드가 있으면 좀 더 노력을 해보겠다. 


  이러한 방식으로 linux에서는 디스플레이 오버클럭을 한다. 

모니터가 지원을 안하고 힘들어 할 수 있지만, 보통은 여유를 가지고 지원을 해주므로,  refresh 속도를  더 올려보자. 

내 모니터는 75정도에서 한계점을 가진게 맞는지... 1280 720에서 여유가 많이 있음에도 120 90은 실패했다. 

여러번의 시도를 거치면 적당한 해상도에서 최대 refresh값을 얻을 수 있지 않을까... 리눅스는 노가다다. 



댓글