'2015/02'에 해당되는 글 5건

이 이야기는 VMware를 유용하게 쓰시고 계실 모든 분들에게 통용될 이야기입니다. 우분투에서만 이용되는 이야기는 아닙니다. CPU성능이 더럽게 좋아서 소프트웨어 렌더링이 훨씬 더 퍼포먼스가 좋다던지(Intel, S3) 공식드라이버가 워낙 거지같아서 오픈소스프로젝트의 드라이버를 사용하시는(AMD) 모든 분들에게 다 먹히는 이야기이니 유용하게 쓰시기 바랍니다. Windows에서는 후자의 경우가 없으므로 별로 쓸 일은 없겠지만 간혹 베타드라이버에서 VMware가 가속이 안된다고 한 경우가 있으니 Windows 사용자분들도 써먹을 수 있습니다.

VMware를 쓸 때 3D 가속을 하는 이유는 무엇일까요? 보통 VirtualBox에서는 일단 Direct Rendering이 가능하다는 가정하에 3D 가속 설정만 하면 그냥 가속 모드로 들어가는 것과는 다르게 VMware는 오픈소스 드라이버이거나 최신의 드라이버의 경우 3D 가속이 검증이 안 되서 그런 것인지 3D가속을 꺼버립니다.

호스트에서 3D 가속이 안 된다고? 리눅스에서 AMD쓴다고 무시하냐?

VMware가 아무래도 기업용으로 자주 쓰이다 보니 업데이트가 늦는 편이고, 안정성을 추구하다보니 드라이버에 대해서도 상당히 보수적인 입장을 취합니다. 하지만, VMware가 아무리 보수적이라고 해도 방법이 없지는 않습니다. 환경설정에는 안 나와있지만 수동으로 설정을 하면 어떤 드라이버를 쓴다고 해도 3D 가속을 쓸 수 있습니다.

VMware의 가상머신이 있는 곳(~/vmware)에서 vmx파일을 텍스트 에디터로 열면 여러분들이 설정한 설정 값들이 텍스트형태로 나와 있음을 알 수 있습니다. 그 중 제일 마지막에 다음과 같은 한줄만 추가하면 됩니다.

이 한줄만 추가해주시면 이제 오픈소스드라이버를 쓰든, 베타드라이버를 쓰든 아니면 소프트렌더링을 쓰든(...) 3D 가속을 가상머신에서 하는 것을 보실 수 있습니다.

 이제는 Wine의 성능이 상당히 좋아졌습니다. 예전의 고작(?)윈도용 프로그램 몇개 돌리던 호환 레이어였던 Wine은 이제 상당한수준의 산업용 프로그램도 무리없이 굴릴 수 있게되었습니다. 물론, 이 모든 것이 다 사용자달의 피드백과 개발자분들의 열의 덕입니다. 

 이번에는 산업용으로 많이 쓰이는 시리얼 통신을 wine구동 프로그램으로 굴리는 방법을 알려드리고자 합니다. 그러기 전에 시리얼통신을 왜 쓰는 것인지에 대해 말씀 드려야겠네요.

 주로 시리얼 통신은 작게보면 이제는 가정에서 볼 수 없는 RS-232 9핀 커넥터를 주로 이용해서 주변 장비를 구동하는 통신 방법입니다. 본래 시리얼 통신은 직렬구조의 통신 방법을 모두 통틀어서 하는 말입니다. (Serial의 의미가 직렬이란 의미입니다.) 그리고 이 RS-232방식의 통신은 마우스나 키보드, 그 외의 작은 주변장치의 구동에 많이 쓰"였"습니다. 하지만 이 시리얼 포트는 프린터포트(혹은 병렬포트,패러럴포트)와 함께 우리가 너무나도 잘 알고 있는 USB에 의해 밀려서 사라졌습니다.

안녕? 내 이름은 시리얼 포트라고 한다. 이제 가정에서 보기 어려워진지 오래지. 하지만 산업현장에서는 내가 엄청 중요하단다.

이 통신방법은 아직도 산업현장에서는 많이 쓰이고 있어서 이를 쓰기위해 USB-RS232변환 젠더 물건도 나와있고 이 시리얼통신은 AVR이나 PIC같은 MCU에도 많이 쓰이는데, 이것을 시리얼통신포트를 쓰지 않고 곧바로 USB에 접속할 수 있게 만든 칩도 나와있습니다.(대표적인 칩이 FTDI사의 칩입니다.) 그러나 산업현장에서는 장비 가격이 가격이다보니 여전히 위에 보이는 포트를 사용하는 장비를 많이 이용하고 있습니다. 이를 최근에 나오는 PC에 쓰기위해서는 USB를 써야만 하는데 USB-RS232변환젠더 같은 물건이 이때 상당히 애용됩니다. 그리고, 이 통신방법은 제가 여러차례 말씀 드렸던 Arduino도 쓰고 있습니다. 단, 이경우는 FTDI칩을 이용한 가상 시리얼통신입니다. 그래서 실질적으로 USB포트밖에 없습니다.

아무튼 시리얼 통신 포트는 점점 사라지고 있지만, 그 통신 방법은 여전히 많이 쓰인다는 것을 아실 수 있을 것입니다. 심지어 Arduinio도 시리얼통신포트는 쓰지 않지만 그 방식의 통신을 하고 있습니다. 그런데 문제는 이 포트를 이용하는 방법이 Windows와 Unix/Linux계열이 다르다는 것입니다.

 시리얼 통신은 어떤 포트인지 구분하는 것인지가 상당히 중요합니다. TCP/IP기반 통신과는 다르게 장비가 연결되었는가에 대한 규격 자체가 없습니다. 그냥 송신명령 내리면 (그곳에 수신을 받을 장치가 있는지 없는지는 무시하고)그냥 해당 포트로 열심히 신호를 보냅니다. 물론 받는 곳도 그냥 들어오면 땡입니다. 그래서 장비 개발자들은 장비와 연결되었는지 확인하는 것을 소프트웨어 적으로 구현해서 집어넣는데 이 때 포트 번호를 제대로 지정하지 않으면 에러메시지가 뜨도록 해놓는 경우가 흔합니다. 그래서 시리얼통신 PC프로그램은 포트설정 하는 것을 굉장히 중요시 여깁니다. 그 다음으로 중요시 여기는 것은 통신 속도(Baud Rate)지만 그것에 대한 이야기는 넘어가겠습니다. 헌데 이 통신포트구분법은 OS마다 다르기 때문에 참 난감합니다. 심지어 규칙조차도 OS마다 천차만별입니다. 

 Windows에서는 시리얼 통신용 포트를 구별할 때 COM1 COM2 ...이런 식으로 COM뒤에 숫자를 붙이는 것으로 구별합니다. 이는 USB-RS232장비나 Arduinio같은 가상시리얼포트도 마찬가지인데 특이한 것으로 연결한 순서대로 붙이되 가상시리얼 장치는 마음대로 COM포트 번호가 바뀌는 것이 일상입니다. 그래서 PC에 가상시리얼 장치(USB-시리얼)를 붙이면 그 다음에 꼭 장치관리자에서 포트번호를 꼭 확인해야 합니다. 그리고 메인보드에 시리얼포트가 있다면 이 포트가 제일 앞 번호를 선점하게 되어 있습니다. 이 경우에는 장치관리자 따위는 무시해도 상관 없습니다. 만약 보드에 시리얼 포트가 2개 붙어있다면 이 둘이 순서대로 COM1 COM2를 먹고 이후에 USB시리얼 장치가 붙으면 순서대로 붙되 쓰다보면(...)한없이 숫자가 엉키는 것을 보실 수 있습니다. (난데없는 이전장치는 COM3이었는데 COM8이라던가...)

 Unix/Linux는 시리얼장치도 하나의 콘솔로 취급합니다. 아니, 사실 여러분이 터미널 창을 하나 띄우는 것을 이 시스템은 가상시리얼 장치 하나가 연결 된 것으로 취급합니다. 사실 시리얼 통신에 제일 가까운 운영체제가 Unix계열입니다. 그러다보니 단순히 COMX로만 구분하는 Windows와 달리 구분하는 것이 상당히 다양합니다. 일단 Unix계열은 해당 어떤 포트가 어떤 포트인지 구별합니다(!). 만약 보드에 달린 시리얼 포트이면 /dev/ttyS0 ~ /dev/ttySX 이런 식으로 구분합니다.(그런데 실제 포트수와 관계없이 여러개가 준비되어 있습니다.) 그리고 USB장치를 이용했으면 /dev/ttyUSB0~ /dev/USBX 로 포트를 구분합니다. /dev/~~라고 적은 것을 보시면 아시겠지만 모든 하드웨어 장치도 파일로 취급하는 Unix계열 특성상 시리얼 포트도 파일로 취급합니다. 이 파일에 무언가를 적거나 읽어내는 것이 시리얼 통신입니다. /dev/ttyX도 있는데 이것들이 바로 여러분 PC에서 터미널로 작업할 때 쓰이는 콘솔입니다. 여기에는 실제 장치가 붙을 일은 절대 없으니까 무시하셔도 됩니다.

서론이 길었습니다. 이제 Wine프로그램을 이용한 장치를 어떻게 시리얼통신에 써먹는지에 대해 말씀 드리겠습니다. ~/.wine/dosdevice에 들어가보시면 C:라고 이름붙여진 링크와 Z:라고 이름붙여진 링크들이 보입니다. 여기에 com1 혹은 com2라고 만들어진 링크를 만들면 wine은 이들을 알아서 시리얼 포트로 인식해줍니다. 참으로 똑똑하지요? 하지만 이를 이용하려면 우선 wine을 이용하되 여러분이 사용하는 프로그램을 어떻게 실행할 것인지에 대해 알고 계셔야 합니다. PlayonLinux를 이용하셨다면 ~/.wine/dosdevice에 링크를 만드시면 안 됩니다. Playonlinux는 그 특징상 가상드라이브를 따로 만들기 때문에 해당 가상드라이브에 들어가셔야 합니다.

com1이란 링크가 보이는지? 이 com1은 /dev/ttyUSB0의 링크이다. 지금은 장치가 연결되어있지 않아서 오류마크가 뜬 것.

즉, Playonlinux를 이용해서 시리얼통신을 하신다면,

여기에 링크를 만들어야 하고,

그냥 해당 프로그램을 바로 파일매니저 등에서 wine Loader으로 실행하신다면,

에 링크를 만드셔야 합니다.

무슨 링크를 만들어야 하는데? 라고생각하시는 분들은 아까 제가 모든 하드웨어 장치를 파일로 생각한다고 했던거 기억하시나요? /dev/ttySX 나 /dev/ttyUSBX 같은 파일이 곧 시리얼포트를 의미합니다. 즉 저 파일을 링크(Windows 표현대로라면 바로가기)를 만들어주시면 됩니다. 

링크를 만드는 명령어는 다음과 같습니다.

USB형태의 가상포트이며 포트이름이 /dev/ttyUSB0라 했을 때, Playonlinux를 사용하지 않는 다면,

어떤 포트가 실제 장비가 쓰는 포트인지 모르시겠다면, 보드에 달린 포트는 해당 보드의 매뉴얼을 읽으시면 1번포트 2번포트등으로 구분되어져 있다는 것을 아실 수 있습니다. 1번포트가 /dev/ttyS0입니다. 이것은 Windows와 거의 동일합니다. USB를 이용하셨다면 USB시리얼장치를 연결하기 전에 

를 보고, 장치 연결 후에 같은 명령을 쳤을 때 추가된 포트가 바로 해당 장치가 쓰는 포트입니다. 이는 무식하지만 확실한 방법입니다.(저도 상당히 애용합니다.) 정 모르시겠다면 그냥 USB시리얼 장치를 순서대로 꽂으면 /dev/ttyUSB0, /dev/ttyUSB1 이런 식으로 올라갑니다. Windows 마냥 COM3 그다음 장치가 COM8이 되는 이상한 현상은 거의 없다고 보시면 됩니다.

어쨌거나 위의 예시에서는 com1이라는 이름으로 링크를 걸었는데 보시면 아시겠지만 Wine내에서 해당 시리얼 포트를 COM1로 취급한다는 의미입니다. 즉, 이제 Wine 구동 프로그램에서 COM1로 접속을 하시면 별 문제없이 접속이 되는 것을 확인하실 수 있습니다.

민트에서 루분투로 갈아탄지 2일째입니다. 루분투는 성능상의 잇점때문인지 Pulse-audio를 사용하지 않고 Only Alsa정책을 펴고 있었습니다. 그런데 제 노트북에서는 소리가 안 나오는 기현상이 일어나서 Pulse-audio를 설치 했습니다.

이걸로 음량 조절 기능을 설치하고 음량을 조절 할 수 있게 됩니다. 터미널에서 pavucontorl만 치면 실행됩니다. 저는 소리가 안 나오는 원인이 HDMI를 기본 하드웨어로 잡아서 그렇더군요. HDMI 관련 장치를 Off로 설정하니 이후부터는 별 문제 없이 스피커로 출력이 잘 되었습니다.

HDMI어쩌고 장치를 off로 설정하면 스피커로 소리를 들을 수 있다. HDMI를 사용한다면 HDMI를 On하고 쓰면 된다.

그런데 문제가 하나 생기더군요. 키보드에 있는 볼륨 조절키를 아무리 눌러도 조절이 제대로 되지를 않았습니다. 원인은 Openbox 단축키 설정이 Alsa로 되어있어서 그런 것이었습니다.

그럼 그 설정을 Pulse-audio용으로 바꾸면 그만입니다.

단축키를 바꾸는 방법은 두가지가 있습니다. 직접 ~/.config/openbox/lubuntu-rc.xml를 수정하는 방법과 obkey라는 유틸리티를 쓰는 것입니다. 이번에 저는 obkey를 써보겠습니다.

https://code.google.com/p/obkey/downloads/list

위의 링크로 들어가서 obkey를 다운로드 받습니다. 그 다음 원하는 곳에 압축을 풀고 터미널을 열어줍니다. 터미널에서 찾아가기 쉽게 ~/obkey/ 정도에 압축을 풀어놓는 것이 좋겠지요?

이제 obkey를 압축 푼곳으로 찾아갑시다. ~/obkey에 압축을 풀었다면 cd ~/obkey/ 찾아갈 수 있습니다. 그 다음에 다음과 같은 명령어를 줍시다.

그러면 다음과 같은 설정 창을 볼 수 있습니다. 여기서 우리가 원하는 것은 XF86Audio 입니다.

모든 설정이 끝나고 저 버튼을 누르지 않으면 말짱 꽝이다. 그리고 설정 꼬일 것을 대비해서 ~/.config/openbox/lubuntu-rc.xml 파일을 백업해두자

쭉 찾아보면 Key열에 다음과 같은 세 개의 문장이 보입니다.

XF86AudioRaiseVolume

XF86AudioLowerVolume

XF86AudioMute

이 세 개를 Pulse-audio에 맞게 설정 하는 것이 이번 글의 목표입니다.

일단 찍어보시면 오른쪽 위에 Command라고 써있는 칸이 보입니다. 그곳에 보면

amixer ~~~이렇게 쓰여 있는데 이건 Alsa용 명령어 입니다. Pulse-Audio용으로 쓰려면 이걸 고치면 됩니다.

command 칸을 보면 이미 pactl~~로 고쳐놓았다. 이것이 Pulse-audio용 볼륨조절 명령이다. 터미널에서도 먹히니 한번 심심하면 해보자

고쳐야 하는 것은 다음과 같이 고치시면 됩니다.

이제 xml파일을 저장하고 로그아웃 했다가 다시 돌아오면 단축키로 볼륨 조절 되는 것을 보실 수 있습니다. 참고로 저 3%는 고칠 수 있습니다.

이외에도 obkey로 단축키를 마음대로 설정 가능하니 마음껏 이용해보시길 바랍니다.

터미널이나 파일매니저, 웹브라우저는 단축키로 해 놓으면 아주 편합니다.

이전에 제가 쓴 글을 보면 AMD를 신명나게 욕을하면서 드라이버 지원이 참 안 좋다는 이야기를 한 적이 있습니다. 그리고 오늘도 역시 AMD는 리눅스 사용자에게 정말 거지같다는 것을 보여주었습니다.

이미 Wine 관련으로 한바탕 개고생을 선보여주셨던 Catalyst님이 이번에는 32bit OpenGL라이브러리 관련으로 엿을 먹여주었습니다. 사실 이번에 메모리 관련 이슈로인해 루분투로 갈아탔는데 민트에선 그럭저럭 별 문제 없던 Playonlinux에서 다음과 같은 오류를 뿜어주시더군요.

32비트 라이브러리가 없으니 설치하라는 거다. 근데 catalyst깔면서 이미 다 깔린 상태였다

32비트 라이브러리가 없으니 해결하라는 의미인데 혹시나 하고 Win32프로그램을 돌려보니 오류가 와장창....wine과 fglrx관련 이슈가 있기는 있더군요. 그런데 64비트우분투에서 win64비트프로그램을 돌리는 것은 별 문제가 없는데 32비트는 이러한 문제가 생겼습니다. 그리고 32비트 리눅스용 프로그램도 OpenGL사용하는 프로그램에 한해 같은 증상이 있었습니다. 사실 윈도용 프로그램 아니면 32비트 프로그램 쓸 일이 없기는 한데(한글2008 제외) 그래도 이건 좀 아니지 않나 싶습니다.

그래서 오늘 하루를 다 허송세월한 뒤에 오픈소스 드라이버가 없나 찾아보니 이미 개발이 되어져 있더군요. 다만 커널 3.15이상이어야 하고 Xorg도 PPA를 통해 업그레이드를 해야 합니다. 그런데 이미 Catalyst에 화가 머리끝까지 난김에 그냥 커널 업데이트 및 Xorg 업데이트를 했습니다.

그랬더니....

화면이 훨씬 더 부드러워지고 Firefox에서도 GPU가속이 됩니다!(그동안 GPU가속은 남의나라 이야기였습니다.) 이게 뭐지? 싶어서 glxgears를 돌려봤더니 60fps으로 제한을 걸어져 있더군요. Vsync기능이 생긴 듯 했습니다. 중요한것은 AMD공식드라이버란 놈은 Vsync도 안 되어있던 놈이었는데 그 덕에 쓸모없이 성능을 깎아 먹고 있었습니다. 데스크탑 효과에 120fps이상 돌릴 이유는 없잖아요. 역시나 리눅스에서는 오픈소스 드라이버가 정답이었습니다. 훨씬 빠르고 쾌적해졌습니다. 그리고 Wine문제도 없습니다. 32비트문제도 한번에 해결 되었습니다. 이거야 원...갑자기 시원시원하니 속이 시원합니다.

60fps로 Vsync기능이 돌아가고 있음이 확인 된다. AMD 공식드라이버란 놈은 Vsync가 꺼진상태로 시스템을 괴롭히고 있었다.

벤치마크에서도 http://www.phoronix.com/scan.php?page=article&item=amd_apu_1310&num=1 제가 쓰는 Beema기반은 아니지만 80%정도 성능을 따라잡았다고 하니 오픈소스드라이버가 상당한 능력을 지닌 것은 맞습니다. 심지어 안정성은 이쪽이 더 좋습니다. Catalyst는 그냥 불안합니다. 가끔 마우스 포인터 깨지는 것도 예사입니다. 하지만 오픈소스는 역시 전혀 그런 문제가 없군요.

APU사용자 분들 바로 Kernel PPA에서 3.15이상의 커널로 업데이트 하신 뒤에 Oibaf PPA에서 업그레이드를 해보세요. 갑자기 지옥에서 천국으로 바뀝니다!!

Beema/Mullins기반 APU PC에서 ubuntu14.04 그래픽 드라이버 오픈소스로 사용하기

그리고 커널 업데이트

http://kernel.ubuntu.com/~kernel-ppa/mainline

여기서 제일 아래쪽으로 가서 원하는 커널 버전(3.15이상)을 찾아간 다음

32비트 버전 사용자는

linux-headers-~~~-generic~~_i386.deb

linux-headers-~~~all.deb

linux-image-~~~_i386.deb

이 3가지를 다운로드 받고

64비트 사용자는 

linux-headers-~~~-generic~~_amd64.deb

linux-headers-~~~all.deb

linux-image-~~~_amd64.deb

현존하는 리눅스 데스크탑 중 가장 가벼운 데스크탑 환경은 무엇일까요?

분명 예전에는 XFCE가 가장 가벼웠다고 했던 것 같은데 어느새 LXDE라는 새로운 데스크탑 환경이 나와서 XFCE보다 더 가벼운 환경이 되었습니다. 그 뒤에 어느새 Enlightment라는 환경이 나와서 LXDE보다 더 가벼운 환경이라는 타이틀을 내걸게 되었더군요. 하지만 non-KMS 환경에서는 동작이 제대로 안 되는 등 Enlightment는 지향하는 바가 좀 다른 듯 하기는 합니다. 현재 KMS가 제대로 작동이 안 되는 초 구형 하드웨어에서 사용하려면 LXDE가 가장 가볍다고 봐야 합니다.

LXDE의 전체적인 모습. 어디선가 많이 본 듯한 느낌이 든다. 출처: LXDE.org

이러한 이유 덕분에 LXDE는 오래된 컴퓨터에서 돌아가야 할 때 많이 애용되고 있고 지금도 애용되고 있습니다. 헌데 이 LXDE가 새로운 모습으로 바뀔 예정이라고 합니다.

이름하여 LXQT입니다. 

LXDE의 다음세대라 할 수있는 LXQT의 모습. LXDE랑 별 다를바 없어 보인다. 출처: LXQT.org

갑자기 이름이 바뀐 것을 보면 근본부터 갈아 엎었다는 것을 알 수있을 겁니다. 네 LXQT는 기존의 LXDE와 연관이 별로 없습니다. 다만 개발자가 같고, 지향하는 바가 같습니다.(편리하면서도 가벼운 환경을 지향합니다.)

그런데 갑자기 멀쩡한 LXDE대신 LXQT가 개발되었을까요? 이유는 그래픽라이브러리 QT와 GTK에서 비롯되었습니다.

GTK는 그동안 LXDE를 통해서 잘 이용되어진 라이브러리입니다. 하지만, LXDE는 2010년 이후로 사용되어지지 않은 GTK-2버전을 이용해 왔는데 GTK-2는 GTK-3이 나오면서 개발이 중지된 라이브러리가 되었습니다. 그래서 LXDE의 개발자는 GTK-3과 QT5를 저울질 하던 중에 나온지 훨씬 오래되어서 상당히 안정화된 QT를 선택했습니다. 그리하여 LXQT가 나오게 되었고 지금 상당한 속도로 개발이 진행중입니다. QT만 설치하면 지금 당장 우분투에서 가동도 가능합니다.

몇몇 PPA를 등록해야 하기는 하지만 아직 개발중인 것이니까 그러려니 합시다.

이와 같은 명령어로 우분투에서 LXQT를 사용할 수 있습니다. 하지만 LXDE와 큰 차이는 못 느끼겠습니다. 하지만 LXDE를 사용하신다면 슬슬 LXQT로 넘어가실 준비를 해야 할 것입니다. 개발자가 LXQT를 개발하고 있는 이상 LXDE는 도태될 확률이 높습니다. 그리고 Lubuntu의 Daily-update채널에 LXQT가 올라오고 있는것을 봐서 다음 Lubuntu는 LXQT기반일 것이 확실합니다. 이로써 LXDE의 도태는 기정 사실 이게네요. LXDE를 사용하시던 분은 LXQT의 Lubuntu가 나온다면 꼭 이렇게 이야기 합시다.

LXDE 그동안 고마웠어!