蓝牙Apple Magic Keyboard的Fn键（2015）

部分答案：理解HID基础结构和HID原始数据

（免责声明：我只为USB完成了所有这些操作，但我想它会以相同或相似的方式应用于蓝牙）。

HID设备可以以定义良好的格式发送和接收报告。特定设备的格式由HID描述符给出，对于USB，它与其他USB描述符非常相似（例如lsusb，如果未绑定它们，则可以列出它们）。详细信息（用于USB）可以在人机接口设备（HID） PDF文档的设备类定义中找到。

可以找到有关HID的内核文档Documentation/hid。如所hiddev.txt解释的，事件的数据流是这样的：

 usb.c --> hid-core.c --> hid-input.c --> input-subsystem

在中drivers/hid/hid-input.c，特别是在例程中hidinput_configure_usage，根据HID描述符分析报告。

因此，如果看不到Fn钥匙，那就是问题所在。

看到的输出hidraw0看起来令人怀疑，好像有几种报告具有不同的ID（此报告的ID为1，普通键盘报告的ID为0）。

但是要确保，我们需要HID描述符。HID描述符可通过hidraw设备上的ioctl获得。例如https://github.com/DIGImend/usbhid-dump，您可以使用来获取描述符（仅限USB）并https://github.com/DIGImend/hidrd进行解析。/samples/hidraw/hid-example.c内核源代码中还有一个文件，显示了如何通过ioctl获取HID描述符。可以很容易地对其进行修改以产生类似于的十六进制转储usbhid-dump。您必须将其用于蓝牙，所以我将其放在pastebin中。用编译make。

（如果您不习惯编译外部项目：下载zip文件两个，每个解压到一个空目录，./bootstrap，./configure，make。现在你可以直接使用的二进制文件，将它们添加$PATH等）

现在您可以使用

sudo ./hid-desc /dev/hidraw0 | tail -n+3 | head -1 | hidrd-convert -ihex -ospec

除了提供此输出（或hexdump，如果不起作用）之外，hidraw如果Fn结合使用其他各种键（字母，箭头），请测试会发生什么情况。还测试正常按键会发生什么。

如果无法使内核识别特殊报告，我不确定继续进行的最佳方法。也许最简单的方法是编写一个C程序，该程序可以分析hidraw输入中的事件并产生其他输入事件，类似于input-create。

更新：HID描述符00在末尾包含一个额外的内容。如果删除它，它将解析为

Usage Page (Desktop),                           ; Generic desktop controls (01h)
Usage (Keyboard),                               ; Keyboard (06h, application collection)
Collection (Application),
    Report ID (1),                      ; +00 report id
    Usage Page (Keyboard),                      ; Keyboard/keypad (07h)
    Logical Minimum (0),
    Logical Maximum (1),
    Usage Minimum (KB Leftcontrol),             ; Keyboard left control (E0h, dynamic value)
    Usage Maximum (KB Right GUI),               ; Keyboard right GUI (E7h, dynamic value)
    Report Size (1),
    Report Count (8),
    Input (Variable),                   ; +01 modifier
    Report Count (5),
    Report Size (1),
    Usage Page (LED),                           ; LEDs (08h)
    Usage Minimum (01h),
    Usage Maximum (05h),
    Output (Variable),
    Report Count (1),
    Report Size (3),
    Output (Constant, Variable),
    Report Count (8),
    Report Size (1),
    Logical Minimum (0),
    Logical Maximum (1),
    Usage Page (FF00h),                         ; FF00h, vendor-defined
    Usage (03h),
    Input (Constant, Variable),         ; +02 vendor
    Report Count (6),
    Report Size (8),
    Logical Minimum (0),
    Logical Maximum (101),
    Usage Page (Keyboard),                      ; Keyboard/keypad (07h)
    Usage Minimum (None),                       ; No event (00h, selector)
    Usage Maximum (KB Application),             ; Keyboard Application (65h, selector)
    Input,                              ; +03 6 keysym bytes
    Report Count (1),
    Report Size (1),
    Logical Minimum (0),
    Logical Maximum (1),
    Usage Page (Consumer),                      ; Consumer (0Ch)
    Usage (Eject),                              ; Eject (B8h, one-shot control)
    Input (Variable),                   : +09.0
    Report Count (1),
    Report Size (1),
    Usage Page (FF00h),                         ; FF00h, vendor-defined
    Usage (03h),
    Input (Variable),                   ; +09.1
    Report Count (1),
    Report Size (6),
    Input (Constant, Variable),         : +09.2-7
    Usage Page (FF02h),                         ; FF02h, vendor-defined
    Usage (55h),
    Report ID (85),
    Logical Minimum (0),
    Logical Maximum (255),
    Report Size (8),
    Report Count (64),
    Feature (Variable, No Preferred, Volatile),
End Collection,
Usage Page (FF00h),                             ; FF00h, vendor-defined
Usage (14h),
Collection (Application),
    Report ID (144),
    Usage Page (Power Device),                  ; Power device (84h, power page)
    Report Size (1),
    Report Count (3),
    Logical Minimum (0),
    Logical Maximum (1),
    Usage (61h),
    Usage Page (Power Batsys),                  ; Power battery system (85h, power page)
    Usage (44h),
    Usage (46h),
    Input (Variable),
    Report Count (5),
    Input (Constant),
    Report Size (8),
    Report Count (1),
    Logical Minimum (0),
    Logical Maximum (255),
    Usage (65h),
    Input (Variable),
End Collection

有一个输入事件报告的ID十六进制01，一个电池状态报告的ID十六进制90，一个用于照常设置LED的输出以及一个特定于供应商的功能控件。

我标记了输入事件报告的字节。有几个供应商定义的字段，我们不知道他们在做什么，而不得不猜测。

输入事件报告由10个​​字节组成，您的示例解码如下：

ID MM VA K1 K2 K3 K4 K5 K6 VB

01 00 00 00 00 00 00 00 00 02  ; press? Fn 
01 00 00 00 00 00 00 00 00 00  ; release? Fn

01 00 00 3b 00 00 00 00 00 00  ; press F2
01 00 00 00 00 00 00 00 00 00  ; release

01 00 00 00 00 00 00 00 00 00  ;
01 00 00 00 00 00 00 00 00 02  ; press Fn?
01 00 00 3b 00 00 00 00 00 02  ; press F2
01 00 00 00 00 00 00 00 00 02  ; release F2 (but not Fn?)

ID是报告。MM是标准的8个修饰符位，这些Fn键没有空间。K1到K6高达6个键按压simultanously。VA并且VB是特定于供应商的。假设在上一个示例中您Fn按住并刚刚按下并释放F2，我的猜测是in中的位1VB代表Fn（或至少与之相关的）修饰符。

使用hexdump -e '10/1 "%02X ""\n"'得到9个字节每行输出，并结合检验这一假设Fn与几个键，包括你到底想要重新定义的组合。

更新：为了完整性和将来的参考，尽管我认为在这种情况下它不再重要：可以使用UHID注入HID事件，请参见Documentation/hid/uhid.txtandsamples/uhid/uhid-example.c在内核中。