Another approach to IR
in [Kernel]
|
From: Patrick Boettcher on 1 Dec 2009 12:40 Hi, On Tue, 1 Dec 2009, Devin Heitmueller wrote: > On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab > <mchehab(a)redhat.com> wrote: >> Just taking an example from the dibcom0700 driver (as the same driver >> supports several different RC5 and NEC codes at the same time), >> the kernel table has several keycodes added there, all working >> at the same time. Providing that the scancodes won't overlap, you can >> map two different scancodes (from different IR's) to return the same >> keycode (table is not complete - I just got a few common keycodes): > > Mauro, > > Just to be clear, the dib0700 does not actually support receiving RC5 > or NEC codes at the same time. You have to tell the chip which mode > to operate in, via a REQUEST_SET_RC to the firmware (see > dib0700_core.c:405). The em28xx works the same way (you have to tell > it what type of IR format to receive). > > The fact that the driver currently uses the same lookup table for both > types of remote controls however, was perhaps not the best design > choice. It really should be separated out, and merged with the > regular ir-functions.c. I just never got around to it. I did not follow all the discussion, still I have a comment: I will soon work on a device where it is the driver who is doing the decoding of the IR-frames. It is (maybe, I'm still missing some pieces to be sure) possible to receive different protocols at the same time with this hardware. -- Patrick http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 1 Dec 2009 12:40 Maxim Levitsky wrote: > On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: >> While reading all of these IR threads another way of handling IR >> occurred to me that pretty much eliminates the need for LIRC and >> configuration files in default cases. The best way to make everything >> "just work" is to eliminate it. >> >> The first observation is that the IR profile of various devices are >> well known. Most devices profiles are in the published One-for-All >> database. These device profiles consist of vendor/device/command >> triplets. There is one triplet for each command like play, pause, 1, >> 2, 3, power, etc. >> >> The second observation is that universal remotes know how to generate >> commands for all of the common devices. >> >> Let's define evdev messages for IR than contain vendor/device/command >> triplets. I already posted code for doing that in my original patch >> set. These messages are generated from in-kernel code. >> >> Now add a small amount of code to MythTV, etc to act on these evdev >> messages. Default MythTV, etc to respond to the IR commands for a >> common DVR device. Program your universal remote to send the commands >> for this device. You're done. Everything will "just work" - no LIRC, >> no irrecord, no config files, no command mapping, etc. > You are making one big wrong assumption that everyone that has a remote > uses mythtv, and only it. > > Many users including me, use the remote just like a keyboard, or even > like a mouse. +1. I also use the remote as a keyboard replacement. I used an IR like that for a long time while teaching, using a standard USB video board, as a way to remotely control my notebook. Well, now I have an USB IR for this usage, using HID, that emulates both keyboard and mouse. In fact, the application didn't change. I'm just using the standard USB class for HID, instead of using vendor class to generate the same kind of evdev events ;) Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mauro Carvalho Chehab on 1 Dec 2009 12:50 Patrick Boettcher wrote: >> The fact that the driver currently uses the same lookup table for both >> types of remote controls however, was perhaps not the best design >> choice. It really should be separated out, and merged with the >> regular ir-functions.c. I just never got around to it. > > I did not follow all the discussion, still I have a comment: > > I will soon work on a device where it is the driver who is doing the > decoding of the IR-frames. It is (maybe, I'm still missing some pieces > to be sure) possible to receive different protocols at the same time > with this hardware. That's good news! Needing to pass a modprobe parameter to select the protocol is not nice, and, while an ioctl will be needed to select IR protocols (as there are some hardwares where this is not possible at all), the better is to auto-detect the protocol. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 1 Dec 2009 13:00 On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: > > For sure we need to add an EVIOSETPROTO ioctl to allow the driver > to change the protocol in runtime. > Mauro, I think this kind of confuguration belongs to lirc device space, not input/evdev. This is the same as protocol selection for psmouse module: while it is normally auto-detected we have sysfs attribute to force one or another and it is tied to serio device, not input device. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jon Smirl on 1 Dec 2009 13:20
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab <mchehab(a)redhat.com> wrote: > Hi Jon, > So, what we can do is to have a "default" keycode table mapping several > different IR's there to be used by drivers that are shipped with an IR > that can be fully mapped by the default table. However, for devices > with scancodes that overlaps with the default table, we'll need a separate > table. The goal is to try and design a set of zero config defaults that can work for 90% of users. LIRC merges two different things, basic IR driver support and application scripting for non-IR aware apps. Application scripting for unaware apps is always going to happen in user space and it will always need to be manually configured. But scripting should be optional. I'm looking at the driver half and I'd like to explore how zero config support can be built for IR aware apps. Of course we don't have any IR aware apps today because no kernel IR event types have been defined yet. It is better to simply make the apps IR aware and have them process IR events from evdev (in other words forget about the configs code it was a poor man's scripting scheme). For mouse/keyboard support something parallel to USB HID is needed. A couple of common device profiles would be mapped to keyboard/mouse events by default. That should support 90% of users. The other 10% can use a set keys IOCTL to change the mappings. A couple of use cases: insert MSMCE IR device kernel automatically loads all drivers IR events appear in evdev as vendor/device/command triplets apt-get mythtv set universal remote to xmit DVR commands everything just works set universal remote to xmit device A commands device A commands mapped to keyboard/mouse movements everything just works For these default cases you just have to read enough docs to know what device to set your universal remote to. The scenario I'd like to achieve install TV app install audio app install home automation app use multi-function remote to control in parallel with zero config other than setting three devices into the remote. -- Jon Smirl jonsmirl(a)gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |