mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Scott D. Davilla" <davilla@4pi.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: add appleir USB driver
Date: Fri, 16 May 2008 17:46:01 -0400	[thread overview]
Message-ID: <p0623098ac453a5767fbb@[192.168.2.55]> (raw)

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 while you could continue with including this patch, you would need 
to include key tables for 256 x 256 keys and provide a method to 
disable this device in favor of the usbhid method. A method to 
disable the usbhid usage could be using the modprobe option usbhid 
quirk and passing the ignore flag (the usbhid modprobe quirk passing 
was enabled in 2.6.23.x

I do not understand why this patch is not dropped. The Apple IR is a 
USB HID device and LIRC handles this very nicely. If you do not want 
to use LIRC, then talk to the usbhid device directly.

I use it for the AppleTV (which has an even different device id). I 
have two patches pending that add IR support and audio support for 
the AppleTV. They are pending even though the patches have existed 
since the 2.6.22 kernel because the only way then to boot the AppleTV 
was a nasty EFI patch which would never be accepted.

The AppleTV now has a stable bootloader (atv-bootloader) that uses a 
standard non-EFI linux kerenel and kexec to launch the real standard 
kernel in a similar method as Linux on the PS3. The atv-bootloader 
translates EFI structures into E820 structures and moves the ACPI and 
SMBIOS pointers to where Linux can find them and sets up for a vesafb 
device. The AppleTV is a pure EFI box with no PC BIOS compatibility 
layer.

With atv-bootloader in place and stable (several months and numerous 
users), now I can work on pushing these two patches upstream.

I'm off list so please "CC" to respond.

Scott









             reply	other threads:[~2008-05-16 22:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-16 21:46 Scott D. Davilla [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-05-14 22:15 Greg KH
2008-05-14 23:27 ` Matthew Garrett
2008-05-14 23:49   ` Greg KH
2008-05-15  6:20     ` Sitsofe Wheeler
2008-05-15  3:50 ` Dmitry Torokhov
2008-05-15 13:21 ` Tino Keitel
2008-05-15 13:45   ` Dmitry Torokhov
2008-05-15 17:49     ` Tino Keitel
2008-05-15 18:35       ` Dmitry Torokhov
2008-05-15 20:59         ` Tino Keitel
2008-05-16  7:19           ` Jiri Kosina
2008-05-16  7:26             ` Tino Keitel
2008-05-16 13:13           ` Dmitry Torokhov
2008-05-16 13:32             ` Tino Keitel
2008-05-16 13:53               ` Dmitry Torokhov
2008-05-16 14:07                 ` Tino Keitel
2008-05-15 18:40     ` Greg KH
2008-05-15 20:59       ` Tino Keitel
2008-05-15 21:11         ` Greg KH
2008-05-15 23:27           ` Tino Keitel
2008-05-16  2:32             ` Greg KH
2008-05-16  5:44               ` Tino Keitel
2008-05-15 13:40 ` Tino Keitel
2008-05-15 18:41   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='p0623098ac453a5767fbb@[192.168.2.55]' \
    --to=davilla@4pi.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®