Page MenuHomeFreeBSD

appleir: Add Apple IR receiver driver
Needs ReviewPublic

Authored by guest-seuros on Mon, Feb 23, 10:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 19, 3:44 PM
Unknown Object (File)
Thu, Mar 19, 7:28 AM
Unknown Object (File)
Thu, Mar 19, 6:44 AM
Unknown Object (File)
Wed, Mar 18, 5:31 AM
Unknown Object (File)
Wed, Mar 18, 3:43 AM
Unknown Object (File)
Wed, Mar 18, 12:27 AM
Unknown Object (File)
Tue, Mar 17, 3:03 AM
Unknown Object (File)
Tue, Mar 17, 3:02 AM
Subscribers

Details

Reviewers
obiwac
ngie
Summary

HID driver for Apple IR receivers (USB HID, vendor 0x05ac).
Supports Apple Remote and generic IR remotes using NEC protocol.

Supported hardware:

  • Apple IR Receiver (0x8240, 0x8241, 0x8242, 0x8243, 0x1440)

Apple Remote protocol (proprietary 5-byte HID reports):

  • Key down/repeat/battery-low detection
  • 17-key mapping with two-packet command support
  • Synthesized key-up via 125ms callout timer

Generic IR remotes (NEC protocol):

Output via evdev with standard KEY_* codes.
Raw HID access available at /dev/hidraw0 for custom remapping.

Based on protocol reverse-engineering by James McKenzie et al.
Reference: drivers/hid/hid-appleir.c (Linux)

Tested on Mac Mini 2011 (0x05ac:0x8242).

Test Plan

This driver works with both NEC protocol and apple remotes.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 71379
Build 68262: arc lint + arc unit

Event Timeline

Remove debug DPRINTFN calls and verbose NEC code comments

This driver was supposed to be a port form Linux Apple IR driver.

However, during development I discovered that the remote available for testing was not a genuine Apple remote but a generic NEC-compatible device with a apple logo on it.

As a result, the implementation was extended to support both the Apple protocol and generic NEC protocol devices. FreeBSD now supports both. (i tested it the the genuine remote)

haven't done a hugely in-depth review yet. Overall looks pretty good!

general question though: is this driver not applicable to other IR receivers? in which case maybe a different name would be better. I mean if other generic NEC remotes exist with a different format to the Apple one, presumably that would imply there are other IR receivers which pass on the same reports.

sys/dev/hid/appleir.c
7–9

you are duplicating this comment later on, so no need to have it here in the license header

140

please add space between ; and /*

158–167

I don't know if I love this way of doing things. Perhaps this function should simply return (data >> 1) & KEY_MASK and then you track if a second report is expected separately?

213

are you sure about this? do you have an example battery low report which contains valid/sensible subsequent remote_id and key_code values?

Address review feedback and add hardware test results

  • Fix header: remove duplicate description, move #include <sys/cdefs.h> after comments, ASCII-only arrows
  • Battery low: log once (sc_batt_warned flag), do not process as keydown
  • Remove appleir_get_key() negative-index trick; track two-packet state inline
  • Add sc_twoco callout to expire stale two-packet state after 250ms
  • Fix repeat handling: validate repeat packet matches sc_current_key
  • Strip verbose debug comments from NEC section

Tested on Mac Mini 2011 (0x05ac:0x8242): KEY_ENTER two-packet command,
key repeat, and synthesized key-up all verified via /dev/input/event0.

share/man/man4/appleir.4
57

The hardware section appears verbatim in the hardware release notes, so it needs context.

Out of curiosity, how much of the Linux driver did you use as a reference for this driver? I'm concerned about licensing of the new code.

sys/dev/hid/appleir.c
118–120

Out of curiosity, how much of the Linux driver did you use as a reference for this driver? I'm concerned about licensing of the new code.

How much was copied is the controlling question. Please include a path in the linux tree or git url.

The reverse engineering of the Apple IR protocol was done by James McKenzie in the Linux driver 2 decades ago.
I referenced the Linux files in the original message and in the code (see line 14).

My work here is the FreeBSD driver side is implement probe, attach / detach, build the driver skeleton

During testing I first used the wrong remote.
With a generic NEC-compatible remote the driver seemed to work.

When I compared the behavior with the Linux implementation, I saw that the key mapping was different.

After comparing both drivers, I found that Apple remotes need a special handling in the mapping.
So I ported the Apple remote quirk from the Linux driver to fix the mapping.

If the Apple reverse-engineering part is considered problematic, it can be removed.
The IR receiver still works with standard NEC remotes, and basic IR functionality remains. (Linux Driver don't support that)

The Apple protocol only adds extra features such as battery reporting and Apple-specific button which is apple hardware specific.

sys/dev/hid/appleir.c
7–9

Thanks.

Address review: clarify licensing, rewrite HARDWARE section with USB IDs

  • License header: explicitly state protocol constants are factual hardware data (not copied code), clarify Linux reference is GPL-2.0 with no code copied
  • man page HARDWARE: replace machine model list with USB product ID table; the previous list appeared verbatim in release notes without context
  • battery-low: already handled correctly (log once + ignore); the report byte[4] is 0x00 when battery-low so no valid key_code to process

Replace static product ID table with dynamic report descriptor detection: match any Apple USB HID device with a 5-byte input report

Revert dynamic detection: Thunderbolt Display Audio (0x05ac:0x1107) has a 5-byte HID input report and caused a false positive on Mac Mini 2011 test hardware. Restore static product ID table.

Hardware section is looking good! Consider sorting them in reverse order, so that as it gets longer over time, the current stuff that people are more likely to be able to source is at the top.

share/man/man4/appleir.4
36–41

No need to duplicate this information, it bloats the manual and will make it harder to maintain later :)

73

Macros inside list width arguments is unspecified behavior, sometimes rendering as -1 columns. Manpages have a ton of consumers.

84–85

The Lk macro accepts an argument to do this.

Address review: remove duplicate device list from DESCRIPTION, fix .Bl width arg (no macros), use .Lk with description argument, add space between ; and /*, document byte[4]=0x00 on battery-low, sort HARDWARE newest first

Apple has deprecated IR receivers in favor of wireless. no new hardware will require this driver.

sys/dev/hid/appleir.c
14
16

Thank you for clarifying this point!

67–68

Is this defined or discussed anywhere else, and if so can it be mentioned here?

130–133

style(9): is the whitespace correct here (Phabricator sometimes goofs up when rendering hard tabs)?

153

If this is used as a sentinel, it might be a good idea to either put it at the top of the conditional block (if not reentrant friendly) or down at the bottom (if reentrant friendly)

238–239

Could you please add helpfully named constants for 0x26, et al, with corresponding comments?

257–258

This can fail. How should the driver respond to the failure?

268

This can fail. How should the driver respond to the failure?

291–292

This can fail. How should the driver respond to the failure?

368

Can this fail?

379–380

evdev_free(..) handles the NULL case gracefully for consistency with free(3), et al.

392–396

These calls can all fail at various points in the driver lifecycle. I would check the result and return an appropriate error if some of these calls fail (otherwise the driver/device could be left in a non-determinate state at detach).

sys/modules/hid/appleir/Makefile
1–2

We don't add $FreeBSD$ to files anymore.

Does building/installing this driver on all platforms (TARGET/TARGET_ARCH) make sense?

sys/dev/hid/appleir.c
193

Can you please add helpfully named constants with corresponding documentation (optional, but encouraged) for 0x25, et al?
I realize that you fundamentally did this, but in the event the comment gets scrambled, refactored, etc, having humanized names might help prevent context loss (this general comment applies for other areas where I asked about "magic constants").

sys/modules/hid/appleir/Makefile
7

Where is opt_kbd.h included?

Out of curiosity--since I no longer have any Apple IR remotes (my last one went away with my AppleTV back in the late 2010s), have you tried taking off the case and looking at the internal chips for identifying marks on any of the ASICs? I'm curious because it might help you figure out which NEC ASIC may or may not be compatible with this driver.