That would be me sending to Greg. my bad. I should be posting here
and I've disciplined myself accordingly (a smack upside the head).
The history of the appleir patch is that James McKenzie created it as
a method to get IR controller support working for the MacMini. This
was way back in time before Apple EFI even had a PC BIOS
compatibility layer.
The patch was migrated to the MacTel mactel-linux svn by huceke and
stayed for 2.6.17, 2.6.18, 2.6.20 and 2.6.21 kernel usage. There were
numerous other patches there that did not migrate upstream for
various reasons mainly I think because it was known that they would
never be accepted. These were niche patches for Linux support on
Apple hardware, some using EFI boots, others using Apples EFI PC BIOS
compatibility layer. Some patches were pushed upstream (imacfb),
others stayed.
In 2.6.22, the appleir patch was dropped at mactel-linux because
usbhid support was added in the kernel by including the proper
VID/PID so that the Apple IR devices (now more than one) was
recognized by usbhid and can be seen as "/dev/usb/usbhid0" typically.
I'm not sure when support for the MacMini using usbhid was added to
LIRC.
Just about every distro that has any form of IR support uses LIRC and
LIRC uses usbhid for Apple IR support. This is a userland device as
it should be.
The Apple IR remote can increment an IR user device id such that you
can pair specific IR remotes to computers and not have them control
each other. This user device id is the last byte in the pre_data
(LIRC speak) so there are 256 possible values. There are also 256
possible key values. I believe there might be forbidden values as the
actual IR protocol has a checksum. You can use a JP1 programmable
remote or a learning remote to "extend" beyond the six button limit
of the Apple IR remote controller. Numerous users do this as it
eliminates having to purchase a replacement IR remote and IR receiver
if they find a six button IR remote limiting.
So wh...
