On Thu, May 15, 2008 at 14:35:54 -0400, Dmitry Torokhov wrote:

On Thu, May 15, 2008 at 07:49:39PM +0200, Tino Keitel wrote:

[...]

quoted

I know. I just wanted to point out that this is a regression for all
people who use the macmini LIRC driver. This driver was present at
least in the last 2 LIRC releases. The quirks stuff in the above patch
looks like there is no way to make the macmini LIRC driver work with
the patch applied. It relies on a USB HID device, which wouldn't be
created anymore, and the user has no way to bring it back. Please
correct me with a pointer to the appropriate documentation if I'm
wrong.

There is a way to dynamically manipulate quirks for a VID/PID pair
via sysfs. I think if you set the quirk to 0 it will efefctively
disable the ignore quirk restoring the old behaviour.

Where in sysfs? I found module/usbhid/parameters/quirks and quirks
files in several devices/pci0000:00/* directories. I guess you are
talking about the latter.

How can I tell what device I need to use, or what is the recommended
way? I can only think of something ugly like

$ find /sys -name "idProduct" | xargs grep 8240

and similar with idVendor.

Does setting the quirks to 0 lead to the creation of a HID device
immediately? Where is this documented? Could it be implemented in a way
such that the user has a HID device, as long as he doesn't enable the
appleir driver?

quoted

From the user's point of view: There are no official kernel release
notes about what devices are added/removed to/from the various
ignore lists and blacklists. The kernel doesn't produce any output
about devices that are ignored or blacklisted in may cases (and
also this one). The user has no indication why his LIRC setup stops
working with the new kernel.

Not sure what we can do here... The only thing I guess is better
commit message mentioning LIRC setup concerns.

Who reads commit messages? I think it should be easy to add some
printk()s saying something like "skipping device foo, because it is on
the ignore list".

quoted

Even if all LIRC users switch to the appleir driver, what about
people who use a learning remote to have more than 6 keys that the
Apple remote has? Does this work at all? After a quick look at the
key handling it seems to me that the codes of the 6 keys are
hardcoded in the driver. So a learning remote with more keys
wouldn't work anymore.

We'll have to adjust the driver to allow changing keymap on a
per-device base from userspace. That's pretty easy actually.

I'm not talking about the keymap that is visible in userspace, but
about the keys on the remote that are detected by the kernel. The Apple
remote has only 6 keys, and they are mapped in a static array:

#define MAX_KEYS       8
static int keymap[MAX_KEYS] = ...

With the LIRC driver, I can use a learning remote with much more keys,
and then just use irrecord to create a LIRC config file.

Regards,
Tino