리눅스(linux)에서 리모콘 설정 1/3

 linux에서 리모콘 설정 방법을 정리해 둔다.

나중에 다 잊어먹은 상태에서도 도움이 될 수 있도록, 그리고 혹시나 이 글을 보는 다른 사람에게 조금이라도 도움이 될 수 있도록 가급적 설정과정에서 내가 알게된 배경지식까지 자세히 적으려 했다.
글이 길다.

0. linux에서 리모콘 사용/설정 방식

리모콘 사용은 리모콘에서 송신한 적외선(IR) 신호를 받아 이를 적정한 입력신호(input event)로 해독(decode) 및 변환(mapping)하여 필요한 application에 전달하는 작업이라고 할 수 있다. linux에서 이러한 작업은 kernel 2.6.33 이전까지는 모두 lirc라는 패키지(프로그램)에 의존하고 있다가, 이후부터 리모콘 관련 기능들--주로 수신기 드라이버와 프로토콜--을 하나씩 kernel에 추가하기 시작해서 현재 커널이 지원하는 수신기는 lirc없이 사용이 가능하다. 물론 아직까지 모든 기종의 IR 수신기와 리모콘을 kernel이 지원하지 못하고 있고, 커널이 지원하는 IR 송수신기도 과거와 같이 lirc를 이용하여 사용이 가능하다.

2023년 7월 현재, linux에서 리모콘 사용/설정 방법은 다음과 같이 대략 3가지 방법을 생각해 볼 수 있다.

①  kernel이 수신에서 전달까지 모든 과정을 처리하는 방법

   물론 kernel이 IR신호 수신장치의 드라이버와 송신장치(리모콘)의 프로토콜을 지원하는 경우에만 가능하다. 장점은 설정이 간단하고 일관적이라는 점. 단점은 내가 리모콘을 주로 사용하는 프로그램인 kodi가 아직 이 방법을 100% 지원하지 않는다는 점.

②  lirc가 수신에서 전달까지 모든 과정을 처리하는 방법

   커널이 지원하지 않는 리모콘과 수신장치에 대해서도 설정할 수 있지만 이 역시 현실적으로 lirc가 드라이버를 지원하는 기종으로 제한된다. 장점은 usb 타입을 포함한 다양한 리모콘을 지원한다는 점. 단점은 약간의 중복(overhead)?

③  수신에서 해독까지는 kernel이, 변환에서 전달은 lirc가 처리하는 방법

  당연히 위 ①의 조건을 충족해야 하는 제한이 있지만, 기존에 lirc를 이용해 리모콘을 사용해오던 application이 있다면 그 설정을 바꿀 필요가 없다는 장점이 있다. 단점은 역시나 약간의 중복?

[출처] lirc 웹페이지

이 세가지 방법에 대해 자세한 설정과정을 적는다. 다시 말하지만 글이 길다.

1. kernel이 모든 과정을 처리하도록 설정하는 방식

먼저 kernel의 관점에서 입력신호 처리에 대해 생각해 보자. 리모콘은 키보드나 마우스와 같이 입력(input) 서브시스템에 연결된  여러가지 입력 장치의 하나일 뿐이다. 생각해 보면 무선 키보드나 리모콘이나 그리 다를 건 없는 것 같다. 그리고 입력장치의 종류는 앞으로 갈수록 다양해 질 것이 분명하다. 예컨대 가상환경에서의 자이로스코프 센서 신호와 같은 것들 말이다.

자연스럽게 OS 또는 kernel의 입장에서는 이렇게 다양한 입력장치의 신호(input event)를 일관되게 처리할 수 있는 체계가 필요한데, 이럴 때 나 같이 뭘 잘 알지 못하는 사람도 "이건 구조적인 문제"라느니 "天災가 아니라 人災"라느니 하는 말처럼 쉽게 써 먹을 수 있는 magic word가 "계층화"와 "추상화"라는 용어이다. 다시 말해 입력 신호 처리과정을 단계(계층)별로 나누고 하위 단계에서는 다양한 입력장치의 신호를 어떤 표준 입력신호로 변환(추상화)한 후 그 이후 단계에서는 그 입력신호를 발생한 장치(input source)가 무엇이든간에  동일한 방식으로 처리하자는 것이다. 현재는 udev에 통합된 HAL(Hardware Abstraction Layer)을 생각해 보면 감이 올 듯.

뭔가 거창한 것 같지만--괜히 영어 약자와 용어에 주눅들 필요 없다--간단히 말하면, 리모콘의 "1'이라는 버튼을 눌렀을 때 발생한 IR 입력 신호를, 키보드에서 "1"이라는 키를 눌렀을 때 발생하는 입력신호(keycode, 예컨대 KEY_1)로 하위 단계에서 변환할 수 있다면–즉, 두 입력 신호를 그 이후 처리 단계에서 일관된 방식으로 처리할 수 있도록 추상화할 수 있다면--, 이후의 리모콘의 "1"이라는 버튼의 입력 신호를 처리하는 것이나 키보드의 "1"이라는 키 입력을 처리하는 것이나 다를 바가 없다는 뜻이다.

당연히 linux의 입력신호 처리 체계(UAPI)도 이러한 개념과 설계가 적용되어 있다. 그래서 linux kernel이 리모콘 신호를 모두 처리하도록 설정한다는 것은, 리모콘이 보내는 IR 신호를 수신하여 linux의 일관된 입력 신호(input event)로 변환(mapping)해 줄 수 있도록 설정하는 것이라 할 수 있겠다. 이걸 조금 더 구체적으로 말하면, 이러한 수신/변환 작업을 정확하게 할 수 있는 IR 수신기 kernel 드라이버와 프로토콜, 그리고 키맵 파일(keymap file)을 찾아 설정하는 작업이 될 것이다.

각설하고, 아래와 같은 설정 환경에서 kernel이 리모콘 신호를 모두 처리하도록 설정한다.

   [설정 환경]

• PC
   - intel NUC(NUC7CJYHN)
• OS
   - Artix linux, kernel 6.1.28-1-lts     
     Artix는 systemd 대신 openrc를 사용하는 것을 제외하고는 Arch linux와 거의 동일하다. kernel version이 2.6.36 이상이라면 배포판은 크게 상관이 없을 듯.
• IR 신호 송수신기
   - NUC 내장 ITE8708 CIR transceiver
• IR 신호 송신기(쉽게 리모콘)
   - dvico Fusion remote
• 리모콘을 주로 사용할 프로그램
   - kodi version 19(Matrix) / version 20(Nexus)

dvico Fusion 리모콘 & 수신기

    1-1. 먼저 kernel이 IR 송수신기를 지원하는지 확인

    이는 ir-keytable이라는 프로그램을 이용해서 확인할 수 있는데, Artix(또는 Arch) linux의 경우 v4l-utils 패키지에 포함되어 있다. 다른 배포판도 비슷할 것이다.

    아무런 옵션 없이 ir-keytable을 실행해서 아래와 비슷한 실행결과를 볼 수 있다면 커널이 지원하는 IR 송수신기를 발견했다는 뜻이다. 만약 ir-keytable이 IR 송수신기를 찾을 수 없다면, 안타깝지만 "2번" lirc를 이용하여 설정하는 방법을 시도해 봐야 할 듯.

$ ir-keytable

Found /sys/class/rc/rc0/ with:

Name: ITE8708 CIR transceiver

   Driver: ite-cir

   Default keymap: rc-rc6-mce

   Input device: /dev/input/event4

   LIRC device: /dev/lirc0

   Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm 

   Enabled kernel protocols: lirc 

   Extra capabilities: <access denied>

    ir-keytable은 리모콘 설정에 필요한 필수적인 정보들을 보여준다. 위의 경우, 커널이 발견한 IR 송수신기는 하나 뿐이고 모델(기종)은 "ITE8708 CIR"이며, 이 송수신기는 "/sys/class/rc/rc0"와  "/dev/input/event4"라는 장치 파일을 통해 접근할 수 있고, 현재 커널이 지원하는 13가지 프로토콜의 종류 중 현재 lirc라는 프로토콜이 활성화 되어 있다는 사실을 알 수 있다.

    그리고 lsmod로 확인해 해보면기 해당 IR 송수신기 드라이버(커널 모듈)이 로드되어 있는지도 확인할 수 있다. 만약 로드되지 않았다면--그럴 가능성은 낮지만-- modprobe로 로드한다.

$ lsmod

Module                  Size  Used by

                  ...

ite_cir                32768  0

                  ...

    1-2. 리모콘(송신기)의 프로토콜 확인

    네트워크에서와 마찬가지로 리모콘이 IR신호를 송신하고 이를 수신하는 방식(프로토콜)도 여러가지가 있다. 위 1-1 과정에서 확인한대로 Artix linux의 kernel은 lirc를 비롯한 13가지프로코콜을 지원하고, 기본적으로 lirc 프로토콜이 활성화(enabled) 되어 있다. 사실 lirc는 실제 리모콘이 사용하는 프로토콜이 아닌 일종의 가상 프로토콜로 대부분의 linux 배포판에서 기본적으로 활성화 되어 있다. 이에 대해서는 "2번-kernel이 지원하는 IR 수신기"에서 설명하기로 하고, 일단 리모콘이 사용하는 프로토콜을 찾아야 한다.

    아래와 같이 ir-keytable을 이용하여 모든 프로토콜에 대해(-p all 옵션) 테스트 모드(-t 옵션)로 실행한 후, 리모콘의 아무 버튼이나 눌러 본다.

    [주의] 만약 위 1-1 과정에서 확인된 IR 수신기가 두 개 이상일 때는 -s 옵션에 sysfs의 장치 경로를 명시해서 테스트할 수신기를 특정해 주어야 한다. 예를 들어, 위에서 rc0로 식별된 ITE8708외에 다른 수신기가 하나 더 rc1으로 식별되었고, 우리가 확인하려는 수신기가 ITE8708(즉 rc0)이라면 "-s /sys/class/rc/rc0" 옵션을 추가하여야 한다. 이하 모든 ir-keytable 실행에 대해 동일하다.

$ sudo ir-keytable -p all -t

Protocols changed to unknown other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp cec imon rc-mm 

Can't find xbox-dvd bpf protocol in /etc/rc_keymaps/protocols or /usr/lib/udev/rc_keymaps/protocols

Testing events. Please, press CTRL-C to abort.

241.672409: lirc protocol(nec): scancode = 0x15e

241.743674: lirc protocol(nec): scancode = 0x15e repeat

241.852148: lirc protocol(nec): scancode = 0x15e repeat

244.497597: lirc protocol(nec): scancode = 0x15f

244.569600: lirc protocol(nec): scancode = 0x15f repeat

244.676374: lirc protocol(nec): scancode = 0x15f repeat

^C  ⇐ 중단하려면 Ctrl-C

    결과에서 알 수 있듯이 dvico Fusion 리모콘은 nec 프로토콜을 이용하여 신호를 보낸다는 것을 알 수 있다. 일단 눌러본 리모콘의 버튼 이름과 ir-keytable이 출력한 scancode를 메모해 놓는다. 

만약 리모콘의 프로토콜을 찾을 수 없다면 역시 다음 lirc를 이용한 설정을 시도해 보는 수 밖에 없다.

    1-3. 키맵 파일 찾기

    리모콘 버튼이 눌렸을 때 발생하는 IR 신호는 커널에 의해서 1차적으로 scancode(예: 0x15e)로 인식(변환)된 후 keymap 파일을 통해 실제 사용할 수 있는 keycode(예: KEY_OK)로 변환(mapping)된다. ir-keytable이 포함된 v4l-utils 패키지를 설치하면 /usr/lib/udev/rc_keymaps/ 디렉토리 아래 toml 형식의 다양한 keymap 파일이 같이 설치된다. 이 중에서 내게 맞는 keymap 파일을 찾는다.

    일단 리모콘 모델명과 비슷한 이름을 가진 파일--내 경우에는 dvico_mce.toml--을 찾아서 에디터로 열어 본다. 만약 0x015e = "KEY_OK"와 같이 위 1-2에서 확인한 scancode가 올바른 keycode로 맵핑되어 있는 행(line)을 찾을 수 있다면 Bingo! 파일 윗 부분에 프로토콜이 nec으로 설정되어 있는지도 확인하자.

    만약 파일명으로 찾을 수 없다면 grep을 이용해 v4l-utils 패키지가 제공하는 keymap 파일 중에 위 scancode가 맵핑되어 있는 파일이 있는지 찾아 본다.

$ grep -Hi 0x15e /usr/lib/udev/rc_keymaps/*.toml

    grep으로도 마땅한 keymap 파일을 찾을 수 없다면, 즉 v4l-utils 패키지에서 내 리모트에 맞는 keymap 파일을 제공해 주지 않는다면, 직접 만드는 수 밖에 없다. /usr/lib/udev/rc_keymaps/ 디렉토리에서 keymap 파일을 하나 선정해서--가장 범용적인 rc6_mce.toml 파일이 좋겠다-- /etc/rc_keymaps/ 디렉토리에 복사한 후 스캔코드와 여기에 맞는 keycode를 하나씩 수정해 줘야 한다. 기존 keymap 파일을 일부만 수정하는 경우도 마찬가지이다. 참고로 /usr/lib/udev/rc_keymaps/에 있는 키맵 파일들은 직접 수정하지 않는게 좋다. 나중에 v4l-utils 패키지를 업데이트할 때 overwrite되기 때문이다. 하지만 여기에서 키맵 파일을 작성/수정하는 방법까지는 가지 않기로 한다. Googling!

    [선택 사항]

    반드시 필요한 과정은 아니지만, 커널이 리모콘 수신기를 찾았을 때 udev가 그 키맵 파일을 자동으로 로드할 수 있으면 좋을 것이다.

    v4l-utils 패키지를 설치하면, /lib/udev/rules.d/70-infrared.rules라는 udev 규칙 파일이 설치되는 데, 이 규칙 파일이 하는 일은 커널이 IR 수신장치를 발견하면 그 수신장치의  Default keymap(1-1. ir-keytable 실행 결과 참조)에 해당하는 keymap 파일을 /etc/rc_maps.cfg라는 설정 파일에서 읽어 찾아 로드하는 것이다. 말이 좀 복잡한 것 같지만 조금 더 읽어 보면 이해가 될 것이다. 일단 70-infrared.rules 파일의 내용을 보자.

$ cat 70-infrared.rules

# Automatically load the proper keymaps after the Remote Controller device

# creation.  The keycode tables rules should be at /etc/rc_maps.cfg 

ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="rc", KERNEL=="event*", ENV{.rc_sysdev}="$id", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $env{.rc_sysdev}"

    위에서 $env{.rc_sysdev} 변수는 sysfs상의 적절한 IR 수신장치 노드(rcN, N은 일련번호)로 치환되니 크게 신경 쓸 필요가 없다. 이제 이 udev 규칙 파일의 RUN+= 부분을 직접 실행해 이 규칙 파일이 어떤 일을 하는지 구체적으로 확인해 보자. 내 시스템에는 IR 수신 장치는 하나(rc0) 뿐이어서 굳이 명시하지 않았지만, 수신장치가 두 개  이상이라면 위에 [주의] 사항에서 적은 것처럼 -s 옵션으로 수신장치를 명시해야 한다.

$ sudo ir-keytable -a /etc/rc_maps.cfg -v

Found device /sys/class/rc/rc0/

              ...

Parsing uevent /sys/class/rc/rc0/uevent

/sys/class/rc/rc0/uevent uevent NAME=rc-rc6-mce

/sys/class/rc/rc0/uevent uevent DRV_NAME=ite-cir

/sys/class/rc/rc0/uevent uevent DEV_NAME=ITE8708 CIR transceiver

              ...

Keymap for ite-cir, rc-rc6-mce is on rc6_mce.toml file.

    kernel은 부팅과정 또는 그 이후에 인식한 다양한 장치(device)들의 정보를 sysfs(/sys 디렉토리)를 통해 user space에 노출/공유하는데, IR 리모콘 수신기의 경우에는 /sys/class/rc/rcN(N은 일련번호)이라는 디렉토리--사실은 symlink이지만-- 아래에 있는 서브 디렉토리와 파일들에서 커널이 노출한 정보를 읽어 올 수 있다. kernel이 어떻게 장치를 인식하는 지와 sysfs와 에 대해서는 이 글의 범위를 벗어나므로 여기까지만 적기로 하고, 궁금하면 여기 하고 여기를 참조한다. 아무튼 ir-keytable은 /sys/class/rc/rc0/uevent 파일에서 읽어온 IR 수신기 정보(NAME=rc-rc6-mce에 주목)를 기초로 /etc/rc_maps.cfg에서 적정한 키맵 파일(위의 예에서는 rc6_mce.toml)을 찾아 로드하는 것이다.

    내 경우에는 dvico_mce.toml 키맵 파일을 로드해야 하므로 rc_maps.cfg에서 다음과 같이 rc-rc6_mce 키맵에 대해 디폴트로 rc6_mce.toml 키맵 파일을 로드하게 되어 있는 행을 주석처리하고 dvico_mce.toml 키맵 파일을 로드하도록 수정한다.

#* rc-rc6-mce               rc6_mce.toml

* rc-rc6-mce               dvico_mce.toml

    1-4. 테스트

    이제 리모콘의 프로토콜과 내게 맞는 키맵 파일을 확인 했으니, 다음과 같이 ir-keytable을 실행하고 리모콘 버튼을 하나씩 눌러 본다.

$ sudo ir-keytable -p [리모콘 프로토콜] -c -w [키맵 파일] -t

    내 경우에 실행 결과는 다음과 같았다.

$ sudo ir-keytable -p nec -c -w /lib/udev/rc_keymaps/dvico_mce.toml -t

Read dvico_mce table

Old keytable cleared

Wrote 45 keycode(s) to driver

Protocols changed to nec

Testing events. Please, press CTRL-C to abort.

203.487632: lirc protocol(nec): scancode = 0x15e

203.487654: event type EV_MSC(0x04): scancode = 0x15e

203.487654: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)

203.487654: event type EV_SYN(0x00).

203.539088: lirc protocol(nec): scancode = 0x15e repeat

203.539109: event type EV_MSC(0x04): scancode = 0x15e

203.539109: event type EV_SYN(0x00).

203.776801: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)

203.776801: event type EV_SYN(0x00).

205.743663: lirc protocol(nec): scancode = 0x15f

205.743685: event type EV_MSC(0x04): scancode = 0x15f

205.743685: event type EV_KEY(0x01) key_down: KEY_RIGHT(0x006a)

205.743685: event type EV_SYN(0x00).

205.794704: lirc protocol(nec): scancode = 0x15f repeat

205.794728: event type EV_MSC(0x04): scancode = 0x15f

205.794728: event type EV_SYN(0x00).

205.903133: lirc protocol(nec): scancode = 0x15f repeat

205.903157: event type EV_MSC(0x04): scancode = 0x15f

205.903157: event type EV_SYN(0x00).

206.030025: event type EV_KEY(0x01) key_up: KEY_RIGHT(0x006a)

206.030025: event type EV_SYN(0x00).

    리모콘의 스캔코드(예: 0x15e)와 입력 이벤트(예: EV_KEY), 그리고 키맵 파일을 통해 변환된 키 코드(예: KEY_OK)를 확인할 수 있다. 리모콘 입력 이벤트가 키보드 이벤트(EV_KEY)로 인식된다는 점에 주목하자. 여기까지 되었으면 설정이 99% 완료된 셈이다. OK! 😊

    그런데 간혹 테스트 결과가 다음과 같이 스캔코드만 보여 주고 입력 이벤트나 키 코드를 보여 주지 않는 경우가 있다. 이유는 모르겠다. 하지만 결과가 이렇다고 리모콘 설정이 꼭 실패한 것은 아니다.

$ sudo ir-keytable -p nec -c -w /lib/udev/rc_keymaps/dvico_mce.toml -t

Read dvico_mce table

Old keytable cleared

Wrote 45 keycode(s) to driver

Protocols changed to nec 

Testing events. Please, press CTRL-C to abort.

1059.877592: lirc protocol(nec): scancode = 0x15e

1059.929764: lirc protocol(nec): scancode = 0x15e repeat

1060.037693: lirc protocol(nec): scancode = 0x15e repeat

    위의 경우처럼 ir-keytable이 스캔 코드에 매칭하는 키 코드를 보여 주지 않는다면 테스트 화면에 출력된 스캔 코드를 현재 로드된 키맵 파일과 하나씩 직접 맞춰 보는 수 밖에 없다. 현재 로드된 키맵 파일은 -r 옵션을 주어 확인할 수 있다.

$ sudo ir-keytable -r 

          ...

scancode 0x0103 = KEY_NUMERIC_0 (0x200)

scancode 0x015b = KEY_LEFT (0x69)

scancode 0x015e = KEY_OK (0x160)

scancode 0x015f = KEY_RIGHT (0x6a)

Enabled kernel protocols: lirc nec 

    위 결과를 보면 키맵 파일은 정확하게 로드된 것으로 보인다. 그리고 리모콘의 OK 버튼을 눌렀을 때 스캔코드  0x015e이 발생했고, 키맵 파일에서 KEY_OK에 매핑되어 있다. 번거롭긴 하지만 이렇게 하나씩 확인해서 모든 리모콘 버튼이 원하는 키 코드에 정확하게 매핑되어 있다면 아무 문제 없다.

    혹시 대부분의 버튼이 정확하게 매핑되어 있지만 몇개 버튼이 부정확하게 매핑되어 있다면 그 키맵 파일, 즉 위에서 -w 옵션으로 적어준 파일을 /etc/rc_keymaps/ 디렉토리에 복사한 후 부정확하게 매핑된 스캔코드와 여기에 맞는 키 코드를 수정해 주면 된다. 물론 수정 후 다시 테스트할 때는 -w 옵션에 수정된 파일의 경로를 적어 줘야 할 것이다.

    1-5. 설정 저장

    설정 마지막 단계이다. 지금까지 장황하게 설정과정을 적었으나, 한 줄로 요약하면 ir-keytable이라는 프로그램을 이용해서 커널이 IR 수신기의 드라이버와 프로토콜을 지원하는지 확인하고 적정한 keymap 파일을 찾아 테스트 하는 것이었다. 이렇게 찾아낸 프로토콜과 키맵 파일이 테스트를 통해 정상 작동하는지 확인했으니, 이제 컴퓨터가 부팅할 때마다 자동적으로 위 명령이 실행되도록 하면 된다. 참고로 ir-keytable로 설정한 내용은 sysfs의 해당 장치(리모콘 수신기의 경우 rcN) 관련 파일(예컨대 프로토콜의 경우 protocols 파일)에 기록되는데, sysfs는 ram 기반 파일시스템이라 재 부팅하면 사라진다.

    사실, 위에서 선택사항으로 /etc/rc_maps.cfg에 키맵 파일을 설정했다면. 부팅할 때 마다 70-infrared.rules라는 udev 규칙 파일이 자동적으로 실행되어 IR 수신기의 Default keymap에 맞는 적절한 keymap 파일을 로드할 것이고, keymap 파일에 프로토콜이 적혀 있으니 해당 프로토콜도 자동으로 활성화 될 것이다. 그래서 ir-keytable을 부팅 시 마다 다시 실행할 필요는 없다. 이론적으로는… 😕

    그런데 내 경우에는 키맵은 제대로 로드가 되는데 프로토콜이 제대로 설정되지 않았다. 이유는 역시 모르겠다. udev 로그를 보면 분명 udev 규칙 파일이 ir-keytable을 아무 문제없이 실행하는 걸로 나오는데 말이다. 참고로 로그 중 (err)은 에러가 났다는 게 아니라 출력 스트림이 stdout이 아닌 stderr이었다는 뜻이다. 

event4: /usr/lib/udev/rules.d/70-infrared.rules:4 RUN '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $env{.rc_sysdev}'

event4: Setting permissions /dev/input/event4, uid=0, gid=994, mode=0660        

event4: Successfully created symlink '/dev/char/13:68' to '/dev/input/event4'       

event4: sd-device: Created db file '/run/udev/data/c13:68' for '/devices/pnp0/00:01/rc/rc0/input4/event4'

event4: Running command "/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0"              

event4: Starting '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0'

event4: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0'(err) 'Old keytable cleared'    

event4: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0'(err) 'Wrote 45 keycode(s) to driver'

event4: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0'(err) 'Protocols changed to nec '

event4: Process '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0' succeeded.

    그래서 결국 부팅 시마다 ir-keytable을 다시 한번 실행해 줘야 했다. 위에서 rc_maps.cfg 파일 수정을 선택 사항이라고 한 이유도 그것 때문이다. Artix는  openrc를 사용하고 있으므로 /etc/local.d/ 디렉토리에 파일을 하나 만들어 위 테스트 단계에서 실행했던 ir-keytable 명령에서 테스트 옵션(-t)만 빼고 그대로 적어준다. 파일 이름은 아무거나 상관없으나 반드시 .start로 끝나야 하고 실행 속성(x bit)을 부여한다. Systemd 사용자라면 oneshot 서비스를 하나 만들거나 여기를 참고해서 drop-in 파일을 하나 만들면 될 것이다.

    나는 remote_setup.start라는 파일을 만들었다.  

$ ls -l /etc/local.d/remote_setup.start 

-rwx------ 1 root root 72 Jul 25 14:23 /etc/local.d/remote_setup.start

$ sudo cat /etc/local.d/remote_setup.start 

# Setup the internal ITE8708 remote control

/usr/bin/ir-keytable -p nec -c -w /lib/udev/rc_keymaps/dvico_mce.toml

    reboot 한 후 이번엔 -t 옵션만 주고 다시 한번 테스트 해본다.

$ sudo ir-keytable -t

    그럴 가능성은 낮지만, 만에 하나 여기서 이상이 있으면 다시 처음부터 하나씩 체크해 보는 수 밖에 :-(

    [추가]

    나중에 알게 되었지만 프로토콜이 lirc로 초기화된 이유는 위와 같이 udev 규칙 파일이 실행된 후에 lirc daemon이 실행(load)되었기 때문이다. 앞에서 설명한 것처럼 과거에 lirc에서 하던 IR 신호 처리를 kernel이 하기 시작하면서, lirc의 기본 설정은 위 "③ 수신에서 해독까지는 kernel이, 변환에서 전달은 lirc가 처리하는 방법"으로 바뀌었는데, 이 경우 lirc가 리모콘 신호를 다시 수신하면 동일한 신호가 두 번 처리되는 현상이 발생한다. 그래서 lirc 버전 0.9.3부터는 lirc가 로드될 때 커널이 별도로 IR 신호를 수신하지 못하도록 프로토콜을 lirc로 초기화하는 코드가 삽입되었다고 한다. 자세한 내용은 여기 참조.
    따라서 절대 lirc를 쓰지 않을 것이라면 위 선택사항에서처럼 rc_maps.cfg을 수정한 것으로 충분하고 따로 .start 파일을 만들지 않아도 된다. 하지만 나중에 어떻게 될지 모르니 lirc를 쓰지 않더라도 .start 파일을 만들어서 손해 볼 일은 없는 듯. 

    1-6. kodi 설정

    리모콘 신호가 키보드 입력과 동일하게 처리되니, 원칙적으로 lirc 패키지도 필요없고, kodi에서 리모콘 신호 처리와 관련된 Lircmap.xml 이나 remote.xml 파일이 개입될 여지도 없다. 그리고 디폴트로 설치되는 keyboard.xml 파일(/usr/share/kodi/system/keymaps/keyboard.xml)도 무난해서 딱히 수정할 부분도 없는 것 같다.

 

    그런데 문제는 이 글을 쓰는 현재까지 kodi가 리모콘 신호 처리와 관련해서는 linux kernel에서 지원하는 keycode를 모두 수용하지 못하고 lirc에 의존하고 있다는 점이다. 그래서 리모콘과 일반적인 키보드에서 공통적으로 사용되는 keycode(예: KEY_LEFT, KEY_NUMERIC_1)는 kodi에서 문제없이 작동하지만 리모콘에서만 사용되는 keycode(예: KEY_CHANNELDOWN, KEY_OK)는 인식을 하지 못한다. kodi 위키에서는 keyboard.xml에 keyname이 정의 되지 않은 키도 keyname 대신 keycode를 사용하여 키가 눌렸을 때 실행할 Action을 설정할 수 있다고 설명하고 있지만, 여기에서 말하는 keycode는 OS에서 사용하는 keycode가 아니라 kodi에서 사용하는 VKey 코드로--정확하게는 여기에다 0xF000을 OR 연산한 값의 십진수, 이걸로 한참을 헤맸다--, Vkey로 정의되지 않은 key는  kodi의 debug log를 켜 놓고 봐도 아예 인식조차 되지 않는 것으로 나온다.

    그래서 결론은... 일반적인 리모콘과 키보드에서 공통적으로 사용되는 keycode만 사용할 것이라면 모르겠으나, 리모콘을 쓰는 주용도가 kodi라면 아직까지는 다음 "2번"이나 "3번" 방법이 더 나을 듯.

처음엔 포스트 하나에 다 쓸 생각이었는데 이렇게 길어졌다. 두번째 lirc를 이용한 설정방법과 세번째 kernel과 lirc를 혼용한 설정방법은 다음 포스트에 적기로 한다.