折腾过几台运营商标配的定制盒子之后，我发现一个挺有意思的规律：系统刷得再顺、解码再流畅，最后把人卡住的十有八九是遥控器。CoreELEC 这套轻量媒体系统跑在晶晨芯片的盒子上确实省资源，开机快、占用低，但它默认的按键映射表基本是按通用开发板配的，跟魔百盒这类定制盒子原厂遥控器的码值对不上，于是就出现了装完系统能亮屏、插上鼠标能操作、拿起遥控器却像块砖的尴尬场面。这篇内容聊的就是怎么把这块“砖”救回来：从判断遥控器类型、确认系统当前在用哪套红外驱动，到抓码、写配置、热加载验证、排查按键失灵，一条线走完。适合已经刷好 CoreELEC、能通过 SSH 或键盘鼠标进入系统，但遥控器按键错乱或者干脆没反应的人看；也适合手里有一堆不同型号盒子、想整理一套通用配置方法的人参考。全程只讲思路和可复现的操作，不涉及任何需要特殊网络环境的东西。

1. 先分清手里的遥控器属于哪一类

动手改配置之前，最容易被跳过、也最容易导致后面白忙活的一步，就是搞清楚你手里这个遥控器到底是怎么跟盒子通信的。我见过不少人对着一个蓝牙遥控器猛改remote.conf，改了两小时没反应，最后发现根本没配对。方向错了，后面的努力全是无效功。

1.1 红外、蓝牙、2.4G 三种遥控器的判定方法

市面上配给这类盒子的遥控器，通信方式基本就三种，判断方法其实很简单，不需要拆机。

红外遥控器是最常见的一种。特征是方向性强，你得大致对着盒子正面才能按得动，手挡住就失灵。有个几乎零成本的验证办法：把手机摄像头打开，镜头对准遥控器前端那个深色的小窗口，然后按任意键。红外发射管工作时人眼看不见，但手机 CMOS 能拍到明显的紫色或白色闪烁。拍得到闪烁就是红外，拍不到基本可以排除。另外红外遥控器一般需要两节七号电池，后盖能直接抠开。

蓝牙遥控器通常出现在带语音功能的型号上，按键少、外形简洁，有的还带一个麦克风孔。它的特点是完全不需要对准盒子，隔着沙发、塞进兜里都能用，但首次使用必须配对。如果你拿到手按任何键盒子都没反应，而盒子上又确实有蓝牙模块，那大概率就是没配对。

2.4G 无线遥控器的特征是盒子侧面或背面插着一个小 USB 接收器，遥控器本身可能还带一个 USB 充电口。这种遥控器在系统里表现为一个标准的 USB HID 键盘设备，插上就能用一部分按键，但按键对应关系经常是乱的，因为厂家按安卓的键值定义写死了。

注意：有少数盒子同时内置红外接收头和蓝牙模块，原厂配的是红外遥控器，但用户自己换成了蓝牙的。这种情况下两套配置都要处理好，别只顾着改红外。

1.2 登录系统后三行命令确认当前驱动状态

确定是红外遥控器之后，下一步不是急着改文件，而是先问系统一句：你现在到底在用哪个驱动接管红外接收头？这一步决定了你后面该改remote.conf还是rc_maps.cfg，改错文件是新手最容易踩的坑。

通过 SSH 登进盒子，CoreELEC 的默认账户是root，密码在新版本里需要先在系统的 CoreELEC 设置里开启 SSH 服务并查看。登进去之后依次跑这三条：

dmesg | grep -iE "amremote|meson-ir|rc0|remote" ls /sys/class/rc/ cat /proc/bus/input/devices

第一条看内核日志，重点找amremote或者meson-ir这两个关键字。如果日志里反复出现amremote相关的初始化信息，说明系统走的是晶晨自家的红外驱动；如果出现的是meson-ir和rc0，那就是走了内核标准的红外子系统。

第二条命令更直接。如果/sys/class/rc/目录下存在rc0这样的节点，说明标准红外子系统在工作，这套体系下ir-keytable工具是可以用的。如果这个目录压根不存在或者为空，那基本就是amremote在管事儿。

第三条命令看输入设备列表，找设备名里带ir、remote、amremote、meson-ir字样的条目，记下它对应的event编号，后面调试的时候会用到。三条命令跑完，你对当前状态应该就有底了。

1.3 动手前的准备与备份

真开始改之前，有几个准备动作建议做完，能省掉后面不少返工。

第一，确认你有一条不依赖遥控器的操作通道。SSH 是最稳的，实在不行插个 USB 键盘鼠标也能救急。因为一旦配置写错，遥控器可能彻底失灵，这时候如果没有备用输入方式，就只能拆机短接或者重刷了，代价太大。

第二，把现有的配置文件先备份一份。CoreELEC 的用户配置都在/storage/.config/下面，要备份的就是这个目录里的remote.conf和rc_maps.cfg，如果存在的话：

cp /storage/.config/remote.conf /storage/.config/remote.conf.bak cp /storage/.config/rc_maps.cfg /storage/.config/rc_maps.cfg.bak

第三，装一下 system-tools 这个官方插件。它里面带了evtest、ir-keytable等一堆调试工具，后面抓码会反复用到。在 Kodi 界面里进插件库找就行，装完之后 SSH 里就能直接调用了。

第四，准备一个纯文本编辑器改配置文件。这里要特别强调：千万别用 Windows 记事本直接改完再传上去。Windows 的换行是 CRLF，Linux 认的是 LF，带 CRLF 的配置文件在某些解析器里会直接读失败，而且报错信息极其隐晦，你可能查半天都查不出问题在哪。用 VS Code、Notepad++ 这类工具，改完记得把换行符切成 LF，编码存成无 BOM 的 UTF-8。

2. 两套按键映射体系：amremote 与 meson-ir

CoreELEC 在晶晨平台的盒子上，红外这块其实保留了两套并行的方案。这两套方案的配置文件格式、生效方式、能力边界都不一样，很多人配不成功，根本原因就是把两套东西混着用了。

2.1 remote.conf 是什么，为什么它更值得优先尝试

remote.conf是晶晨自家红外驱动的配置文件，对应的是amremote这个内核模块。它的位置在/storage/.config/remote.conf，系统启动时会读取这个文件，把里面的码值表注册进驱动。

我个人的习惯是优先试这条路，原因有三个。第一，它工作在驱动层，从红外信号解调到键值上报全在驱动里完成，延迟低，长按重复的响应也更跟手。第二，它对开机唤醒的支持更完整，盒子关机或者待机状态下，红外接收头需要保持供电并识别特定码值才能唤醒，这套机制在amremote体系里是有官方支持的。第三，格式简单，一张key_begin到key_end的码值表，左边是遥控器发出来的扫描码，右边是 Linux 输入子系统的键值，一对一，没有中间层。

它的短板也很明显：调试手段少。这套驱动不像标准红外子系统那样有ir-keytable这种成熟的抓码工具，出了问题只能靠dmesg看日志，信息量有限。所以如果remote.conf怎么改都不生效，别死磕，转头试试第二套。

2.2 rc_maps.cfg + keymap 的路子适合什么情况

第二套方案走的是 Linux 内核标准的红外遥控子系统，也就是rc-core。配置分两个文件：/storage/.config/rc_maps.cfg指定用哪张码表，/storage/.config/rc_keymaps/目录下放具体的码表文件。

rc_maps.cfg的格式是一行一条规则，三列用空格或制表符隔开，依次是驱动名、码表匹配规则、码表文件名：

# driver table keytable meson-ir * my_box

第一列写meson-ir，第二列写*表示匹配所有，第三列my_box对应/storage/.config/rc_keymaps/my_box这个文件（文件名不带路径）。

这套方案最大的优势就是可调试性。ir-keytable这个工具可以实时把收到的红外扫描码打印到终端上，你不用猜、不用翻日志，按一下键屏幕上就出来一行码值，抓码效率比第一套高一个数量级。另外它支持多协议并行识别，NEC、RC5、RC6 可以同时开，对于那些不确定协议的老遥控器特别友好。

代价是唤醒支持弱一些，而且依赖rc0设备节点存在。有些定制盒子的红外接收头走的是晶晨自己的通路，标准子系统根本挂不上，这种情况下rc_maps.cfg写得再对也没用。

2.3 两套体系同时生效时的冲突表现与处理

理论上同一时刻只有一个驱动能绑定红外接收硬件，但实际排查中我确实遇到过两套配置都存在、表现却很诡异的情况：按某个键能触发，但延迟很高；或者长按失灵、单击却正常；又或者刚开机时好用，播了会儿视频就不响应了。

这种时候先用一条命令看模块加载情况：

lsmod | grep -iE "amremote|meson"

如果两个模块都在列表里，说明内核把两套都编进去了，谁先抢到硬件谁说了算。这时候的处理原则很简单：只改一个，另一个的相关配置文件清空或删掉。我的做法是保留remote.conf，把rc_maps.cfg里的规则注释掉，避免两套规则互相干扰。

还有一种更隐蔽的冲突：remote.conf里配置了某个键，Kodi 层的 keymap 里又把这个键重新映射了一遍，结果就是你改了驱动层没效果，因为真正决定键位行为的是上层。这个后面第 6 章会专门讲。

提示：排查阶段建议每次只改一个变量，改完立刻验证。同时改三四个文件再重启，出问题了你根本不知道是哪个改动导致的。

3. 抓码：把按键变成可读的数字

配置的本质就是建立一张映射表：遥控器按下某个键，红外接收头发出一串编码，你要告诉系统“这串编码等于电源键”。所以第一步永远是拿到那串编码，也就是抓码。

3.1 红外遥控抓码的三条路

第一条路，走标准红外子系统，用ir-keytable。前提是/sys/class/rc/rc0存在。先看当前状态：

ir-keytable

输出里会列出设备路径、驱动名、当前启用的协议，以及已经加载的码表。接着做两件事：先把现有码表清掉（否则已有的映射会把扫描码直接翻译成键值，你就看不到原始码了），再开启测试模式：

ir-keytable -c -p NEC -t

-c是清除当前码表，-p NEC是只启用 NEC 协议（不确定协议的话可以写-p all，但输出会更杂），-t是测试模式。这时候对着盒子按遥控器，终端上会实时打印类似这样的内容：

Testing events. Please, press CTRL-C to abort. 1234.567890: lirc protocol(nec): scancode = 0x4d 1234.567890: event type EV_MSC(0x04): scancode = 0x4d 1234.567890: event type EV_KEY(0x01) key_down: KEY_OK(0x160)

scancode后面那个十六进制数就是我们要的原始码。把每个键都按一遍，记在纸上或者另开一个窗口记下来，后面写码表直接用。

第二条路，走amremote体系，看内核日志。这条路信息量少，但不是完全没办法。先用一个不可能匹配的厂商码占位，然后按遥控器，看看驱动会不会把未匹配的扫描码打到日志里：

dmesg -c > /dev/null # 此时按遥控器上的键 dmesg | tail -30

有些内核版本会输出类似invalid custom code或者scancode 0x...的信息，从中可以反推。如果一条都没有，那这条路基本走不通，直接看第三条。

第三条路，也是最省事的一条：从原厂固件里捞现成的remote.conf。这类定制盒子出厂跑的安卓系统里，/system/etc/remote.conf这个文件几乎必然存在，因为原厂遥控器就是靠它工作的。把这个文件取出来，把格式调整成 CoreELEC 认的样子，成功率极高。

取法有两种。如果盒子还保留着安卓系统，并且能打开 USB 调试，直接adb pull /system/etc/remote.conf就行。如果盒子已经刷成 CoreELEC 了，那就去找对应型号的官方固件包，解包之后在system分区里翻这个文件。同型号的盒子遥控器码值基本一致，甚至同品牌不同型号之间也有很大概率通用，因为厂家经常复用同一批遥控器方案。

3.2 从原厂固件里“捡”一份现成的 remote.conf

我实测下来，这条路对新手最友好。原厂文件长这样（不同型号会有差异）：

factory_code = 0xff000001 work_mode = 0 repeat_enable = 1 repeat_delay = 130 repeat_peroid = 120 release_delay = 20 key_begin 0x11 116 0x54 115 0x53 114 key_end

拿到之后要做的判断是：右边的数字是不是 Linux 输入子系统的标准键值。原厂安卓用的键值体系跟 Linux 不完全一样，有的文件右边写的是安卓的AKEYCODE_*数值，这种就不能直接抄，得换算。判断方法很简单，谷歌一下常见键值：116 是电源、115 是音量加、114 是音量减、103 是方向上、108 是方向下、105 是左、106 是右、28 是确认、158 是返回、102 是主页。如果你看到文件里右边大量出现这些熟悉的数字，恭喜，可以直接用。

如果右边是一堆完全对不上的数字，比如全是 2、3、4、5 这类小整数，那多半是安卓键值，需要一张对照表转换，或者干脆只抄左边的扫描码，右边的键值自己按功能重新填。

3.3 蓝牙遥控器配对与 2.4G 接收器的处理

这两类跟红外完全是两条技术路线，混在一起讲容易乱，单独说清楚。

蓝牙遥控器的配置主要在配对环节。进 Kodi 界面，找到 CoreELEC 设置里的蓝牙选项，打开蓝牙，让遥控器进入配对模式（一般是同时长按两个键几秒，指示灯快闪），然后在列表里选中它配对。配对成功后，用cat /proc/bus/input/devices应该能看到一个新的输入设备，名字通常包含遥控器型号。

配对之后如果按键映射不对，处理方式和红外完全不同：它已经是一个标准输入设备了，你不需要抓码，只需要在 Kodi 层重新映射键位，具体做法见第 6 章。也有少数蓝牙遥控器配对后完全没反应，那可能是协议版本或者 HID 描述符的问题，这种基本无解，换遥控器比折腾系统划算。

2.4G 遥控器最简单，插上 USB 接收器，系统自动识别成键盘，一部分按键立刻能用。剩下不能用的或者映射错的，同样是走 Kodi 层的 keymap 调整。有一个小细节值得注意：这类接收器插拔之后设备编号可能变化，如果你写了依赖event编号的规则，建议用 udev 规则按设备名做固定命名，别写死编号。

4. 写配置：参数逐行拆解与实操示例

码抓到了，接下来就是把它写成系统认识的格式。这一章把两套配置文件的写法都过一遍，重点讲清楚每个参数到底在干什么，因为很多教程只给模板不讲原理，导致换个盒子就懵。

4.1 remote.conf 关键参数逐个说清楚

一份完整的remote.conf大概长这样，我按行解释：

factory_code = 0xff000001 work_mode = 0 repeat_enable = 1 repeat_delay = 130 repeat_peroid = 120 release_delay = 20 key_begin 0x11 116 0x54 115 0x53 114 0x50 103 0x10 108 0x51 105 0x12 106 0x55 28 0x13 158 0x14 102 key_end

factory_code是厂商码，也可以理解成遥控器的身份标识。不同厂家、不同批次的遥控器这个值不一样，写错了整张表都失效。这个值通常能从原厂文件里直接拿到；拿不到的话，就只能靠dmesg里未匹配时的输出反推，或者干脆多试几个常见值。

work_mode决定解码方式，0 是软件解码，1 是硬件解码。这里有个反直觉的点：很多人以为硬件解码更准，实际上不少盒子上work_mode=1反而会导致部分按键识别不出来。我的建议是默认填 0，出问题了再试 1。

repeat_enable控制长按重复，填 1 开启。这个必须开，否则你在 Kodi 里按住方向键想快速翻列表，结果只动一格。

repeat_delay是首次重复的延迟，单位毫秒。填 130 意味着按住键 130 毫秒后开始重复。填太小容易误触发连击，填太大长按反应迟钝。

repeat_peroid是重复周期，也就是每次重复之间的间隔，单位毫秒。注意这个参数的拼写是peroid而不是period，这是晶晨驱动沿用了十几年的历史拼写错误，你写成正确的period反而不生效。这个坑我踩过，当时排查了半个多小时才发现是拼写问题。

release_delay是松手后的延迟。这个值设得太小，快速连按会丢键；设得太大，连按会变成延长按。20 到 50 之间比较稳妥。

key_begin和key_end之间就是映射表，每行两个值，左边是抓到的扫描码（十六进制），右边是 Linux 输入键值（十进制）。中间用空格或制表符隔开，行尾可以加#注释，写上按键名称方便以后维护。

常用键值整理成表，照着填就行：

4.2 keymap 文件写法与 Kodi 键位对应表

走meson-ir这条路的话，码表文件的格式更简洁，一行一个映射：

# table my_box, type: NEC 0x4d KEY_POWER 0x56 KEY_VOLUMEUP 0x16 KEY_VOLUMEDOWN 0x45 KEY_UP 0x15 KEY_DOWN 0x44 KEY_LEFT 0x14 KEY_RIGHT 0x40 KEY_OK 0x43 KEY_BACK 0x09 KEY_HOME

左边是抓到的扫描码，右边是键名，键名来自内核的input-event-codes.h，绝大多数发行版都支持用名字而不是数字，可读性好很多。

写完码表文件，放到/storage/.config/rc_keymaps/my_box，注意文件名不要带扩展名，然后编辑/storage/.config/rc_maps.cfg加上那一行规则。两个文件都就位之后，可以先不重启，用命令直接加载测试：

ir-keytable -c -w /storage/.config/rc_keymaps/my_box

这条命令是临时生效，重启就没了，正好用来验证码表写得对不对。如果按键正常，再让它持久化——重启系统，rc_maps.cfg会在启动阶段被读取并应用。

键值和 Kodi 动作之间的对应关系，官方有一套默认映射，理解这套映射能帮你判断“为什么这个键按了没反应”。Kodi 会拦截一部分键值做全局处理，比如KEY_HOME回到主页、KEY_BACK返回上一级、KEY_OK和KEY_ENTER当作确认、四个方向键控制焦点移动、KEY_PLAYPAUSE（164）控制播放暂停。视频播放界面下还会额外响应快进快退、字幕切换、音轨切换等。

这意味着，如果你把某个物理按键映射成了KEY_F1这种 Kodi 没有默认绑定的键值，那它按下去就是没反应——不是配置错了，是上层没给它安排活儿。碰到这种情况，要么换一个更有意义的键值，要么去 Kodi 层自己绑定，后者在第 6 章讲。

4.3 热加载与重启验证的正确姿势

改配置最烦的就是每次都要重启，好在两套体系都有热加载的办法。

amremote这条路，CoreELEC 里带了remotecfg这个工具，可以直接重新加载配置，不用重启：

remotecfg /storage/.config/remote.conf

执行完直接按遥控器测试，立刻能看到效果。如果命令报错说找不到文件，检查一下路径和权限，/storage/.config/下的文件属主应该是 root。

meson-ir这条路就是前面提到的ir-keytable -c -w，同样是即时生效。

验证的时候建议按这个顺序来：先测方向键和确认键，这四个键决定你能不能操作界面；再测返回和主页，决定你能不能正常导航；最后测音量键和电源键。如果前两组正常、只有电源键不行，那大概率不是码值错了，而是电源键被系统单独接管了，这个在第 5.2 节展开。

如果热加载有效但重启之后失效，说明配置没有持久化。检查两个地方：文件是不是放在了/storage/.config/下（不是/etc/或者/root/），以及rc_maps.cfg里那一行的驱动名拼写对不对。

提示：/flash分区默认是只读的。如果你要改config.ini里的唤醒参数，得先mount -o remount,rw /flash，改完再mount -o remount,ro /flash。直接改会提示 Read-only file system，很多人以为是权限问题，实际上是文件系统挂载属性。

5. 失灵场景排查实录与速查表

配置写完能用了，不代表以后不会出问题。这一章按我实际遇到的顺序整理一下典型的失灵场景。

5.1 故障速查表

表格里最后那条其实是最常见的“疑难杂症”，值得单独说。

5.2 电源键唤不醒单独说

盒子关机之后按遥控器没反应，但插电开机之后遥控器一切正常，这个问题的本质是：关机状态下系统只跑一个极简的待机程序，红外接收头由专门的电路维持供电，它只认一个固定的唤醒码。你改的remote.conf在关机状态下根本没被读进去。

唤醒配置在/flash/config.ini里，需要两步：

mount -o remount,rw /flash vi /flash/config.ini

找到或者添加这两行：

remotewakeup='0xbf40fe01' decode_type='0x0'

remotewakeup是唤醒码，格式跟普通扫描码不太一样，它是厂商码加数据码拼起来的完整帧，通常能在原厂固件的配置文件里找到，或者从dmesg里识别。decode_type指定解码协议，0x0 是 NEC，0x1 是 RC6，具体填哪个取决于遥控器。

改完保存，执行mount -o remount,ro /flash恢复只读，然后完整断电重启一次（不是重启系统，是拔电源），让待机程序重新读取配置。

如果配完还是不行，有两个方向要查。一是厂商码不匹配，remotewakeup里的高位部分要跟遥控器实际发出的前导码一致，这个得靠抓码确认。二是 HDMI-CEC 在捣乱，有些电视会通过 CEC 通道发送唤醒指令，跟红外唤醒产生竞争，表现就是有时能唤醒有时不能。可以在 Kodi 的 CEC 设置里把相关功能关掉试试。

5.3 几个只有踩过才知道的坑

第一个坑：文件名对但位置错。CoreELEC 启动时会依次读取几个位置的配置，/storage/.config/的优先级最高。但有些老教程写的是/etc/remote.conf或者/root/.config/，照着放进去，系统压根不读。判断方法很简单：改完重启，如果dmesg里没有任何关于读取配置的日志，多半就是位置不对。

第二个坑：文件编码。用 Windows 上的编辑器改完再用 SFTP 传上去，很容易带上 CRLF 或者 UTF-8 BOM。remote.conf的解析器对这种东西极其不宽容，可能整份文件直接读失败，日志里还不会有明显报错。检查方法：

file /storage/.config/remote.conf cat -A /storage/.config/remote.conf | head -5

如果cat -A的输出行尾是^M$，那就是 CRLF；正常应该只有$。行首出现M-oM-;M-?这种乱码就是 BOM。两个都得处理掉，用dos2unix或者编辑器里的转换功能都行。

第三个坑：一个键值被两个扫描码占用。这种情况多出现在你从网上抄了一份别人的码表、又自己补了几行的情况下。两个扫描码都映射到KEY_BACK，按哪个都触发返回，看起来“某个键失灵了”，实际上是映射重复。写完之后扫一眼有没有重复的右侧值，能避免大半这类问题。

第四个坑：Kodi 层的覆盖。你在驱动层把某个键映射成了KEY_MENU，结果按下去什么都不发生。原因是 Kodi 的默认 keymap 里KEY_MENU在当前窗口没有绑定动作，事件被吞掉了。这时候你可以换一个键值，也可以在 Kodi 层补一条映射。判断方法：SSH 里跑evtest，按那个键，看终端有没有打印事件。有事件说明驱动层没问题，问题在上层；没事件说明驱动层就没认出来。

第五个坑：遥控器本身的物理老化。用久了导电橡胶触点会氧化，表现是某个键特别难按，要用力才灵。这不是软件问题，拆开用酒精棉擦一下触点和 PCB 上的碳膜能救回来。判断方法：用手机摄像头看，按那个键的时候如果闪烁明显比其他键暗或者干脆不闪，那就是物理问题。

6. Kodi 层的按键二次定制

驱动层把码值翻译成键值之后，还有一道工序：Kodi 把这些键值翻译成具体动作。这一层是可选的，但如果你想让遥控器用起来更顺手，这层值得花点时间。

6.1 keymaps/remote.xml 的作用范围

Kodi 的按键映射文件在/storage/.kodi/userdata/keymaps/目录下，默认可能不存在，自己新建一个remote.xml就行。它的作用域分得很细，最外层是keymap标签，里面按界面场景划分，比如global是全局生效、Home是主页、FullscreenVideo是全屏播放、VideoOSD是播放控制条。

一份最简的写法长这样：

<keymap> <global> <remote> <play>PlayPause</play> <title>ContextMenu</title> <subtitle>ShowSubtitles</subtitle> </remote> </global> </keymap>

<remote>这一层对应的是红外或者 HID 遥控器上报的键值，跟键盘的<keyboard>区分开。<play>是键名，对应KEY_PLAYPAUSE，后面的PlayPause是 Kodi 内建动作名。

这套机制最实用的地方在于，它可以把一个物理键在不同场景下映射成不同功能。比如同样的返回键，在主页按是退出，在播放界面按是回到列表，在设置界面按是返回上一级，全都是 Kodi 根据当前窗口自动分派的，你不需要重复配置。

修改完之后，Kodi 会自动重载 keymap，不用重启。如果改了没效果，检查 XML 是不是语法错误——差一个闭合标签就会整份失效，而且 Kodi 的日志里报错信息藏得比较深，得开调试日志才看得到。

6.2 长按、组合与场景化映射

基础映射搞定之后，可以玩一些进阶的。

长按在 XML 里是用longpress标签表示的，夹在按键标签里面：

<keymap> <global> <remote> <title> <shortpress>ContextMenu</shortpress> <longpress time="800">ActivateWindow(ShutdownMenu)</longpress> </title> </remote> </global> </keymap>

time属性是长按判定阈值，单位毫秒，默认 500 左右。设成 800 意味着按住超过 0.8 秒才算长按，短按触发前者。这个功能在遥控器按键少的时候特别有用，一个键当两个用，把常用功能都塞进去。

场景化映射就是把同一个物理键在不同窗口里绑定不同动作。下面这个例子是把遥控器上的菜单键做成“在播放界面呼出音轨切换，在列表界面呼出上下文菜单”：

<keymap> <FullscreenVideo> <remote> <menu>AudioNextLanguage</menu> </remote> </FullscreenVideo> <MyVideoNav> <remote> <menu>ContextMenu</menu> </remote> </MyVideoNav> </keymap>

这里的关键是窗口名要写对。FullscreenVideo是全屏播放、MyVideoNav是视频文件列表、MyMusicNav是音乐列表、Home是主页、Settings是设置界面。写错了不报错，就是不生效，所以调试的时候建议先在一个场景里验证成功，再往上加。

我个人的经验是，遥控器的按键不是越多越好配，而是要配成一套有肌肉记忆的逻辑。方向上确认返回这四个键是最高频的，不要在它们上面叠长按功能，容易误触；音量和播放控制次之；菜单类功能放在边缘按键上做长按，用不上的时候不碍事。配完之后让家里人用两天，哪儿别扭就调哪儿，比自己一个人对着屏幕测试靠谱得多。

配置这东西没有一劳永逸的版本，盒子换了、遥控器换了、系统大版本升级了，都可能要重新过一遍。我自己的习惯是把调好的remote.conf和rc_maps.cfg连同对应的盒子型号一起存在一个目录里，下次遇到同型号的机器直接拷进去，热加载一下就能用，省下来的时间比当初折腾配置的时间多得多。