El 3 de septiembre de 2009 01:45, Tony Bones <email@example.com>
Thanks for all the great info. It's failing at:
This looks rather strange... This call is simply informing the kernel that a new possible source for triggering a LED is possible (in this case setting the LED on when transmitting IR). I don't know how it may be that this function fails to set data->txtrigger.
You could try just commenting out all led_XXX() calls in the code, along with the error checking ifs() to see what happens.
I'm guessing because there is no device actually
plugged into the CIR port yet. I'm going to try that later when I have
You bring up another point, this is kernel driver and
does not work with lirc. I wonder why the author wrote this as a
kernel driver instead of a lirc driver. So I'm wondering how this
driver would then interact with an application like MythTV. Or even if
it would be worthwhile (how much effort) to convert this to a lirc
driver so it would just work everywhere lirc works.
I've searched a little bit into the mailing lists.
It seems there are two camps about this all. "Input" guys just want devices that return keys. This is what the patch you found does, at the cost of decoding the RC-(5|6) protocol in a receiver-specific driver. And, moreover, at the cost of restricting a perfectly generic receiver to a handful of supported protocols (no custom/raw remotes allowed). At least, it seems this patch allows (or at least it should allow) keymap configuration via input-utils input-kbd.
Christoph's view (may he correct me if I'm wrong) is that it's not good to tie perfectly generic receivers into specific protocols or remotes. His work in LIRC takes this approach and (most) drivers just report raw data (pulse/space time lengths) to a user space daemon (lircd) that's able to decode any protocol. It's even able to decode the signals of different remotes with different protocols at the same time with any generic (pulse/space length sending) IR receiver.
BTW, programs prepared to use LIRC directly talk to lircd via a socket, instead of using input "keys". IIRC, LIRC has a devinput driver that can read the actual keys (decoded key codes) of any input device (the IR receiver in that patch, a real keyboard...) and translate them as a kind of IR remote that programs that know how to use LIRC can then use.
In the same way, LIRC now has uinput support, that allows lircd to create a virtual input device (following the kernel input device interface) that emits as key events after lircd has decoded them (be it from a generic LIRC-supported generic receiver, or by forwarding/translating devinput precooked codes).
So far my only involvement with LIRC so far has been the wpc8769l driver that I wrote by reverse engineering the thing in my laptop. It seems that the driver you found the patch is for a hardware that shares a fair amount of registers with mine. Probably both of them should be merged. Alas! Each one lives on a different side of the fence, because mine is a generic space/pulse one :-(
Without knowing too much about the input/LIRC debate, I think I'm with Christoph about supporting a generic interface with only one point of decoding supporting multiple protocols. In other case you'll have every IR receiver driver doing its own decoding once and again.
On the other hand, I prefer the decoding output to get to programs via standard input-device events rather than a LIRC-specific protocol. The X server understands input-device events. The Linux console understands them too... Active focus issues (which application receives the keys you push) are already handled more or less properly, while using the daemons and interfaces native to LIRC requires you to configure a maze of switching "modes" depending on which application you want to receive them (it's MythTV or Xine the one you wanted to "PLAY"?).
So I like a lot the work Christoph has put into the uinput support, because it's a very nice step in unifying the "output" half of IR receiving in Linux.
The problem is that, even with this, there seems to be people that complains that they are required to install and configure a user space daemon (lircd) in order to use the remote (with receiver) they've just plugged into their machine. They just want to plug in the TV receiver card and be able to just use the remote provided with that card to type in 1, 2, 3, PLAY, PAUSE. They seem to consider the configuration of lircd and the piping of data kernel receiver -> user lircd -> kernel uinput -> user application to be overkill to use a bundled remote.
It may be that there is a well defined set of common receiver-remote combinations, but they are specific setups, anyways, and from my point of view you end up coding a lot of specific cases into the kernel instead of using a generic framework with user-space configuration. You duplicate the code (duplicate decoding of signals in each receiver driver) and you reduce the flexibility (fixed receiver <-> protocol combinations).
So, if you ask me, I would go the LIRC way in the kernel with a minimalist lircd daemon (just decode -> uinput), or even moving the minimalist decoding daemon into the kernel (some new generic any-protocol framework available for all the drivers), providing user-space interfaces for the mapping of remote codes to input device key codes, and for mapping input receivers to virtual input devices.
The other part that LIRC addresses is the sending of IR codes. I don't have any idea about whether it could or should fit into the input-dev framework, or it would be better to put it into a parallel send-only infrastructure.
I would actually like to get some authoritative information on the current status of this all and whether there are plans to unify things up. Perhaps Christoph may provide some links or further info (if he has the time and isn't infinitely bored by this saga).
I can't really use it in its current state until I can get application support for it, I'm guessing.
If your application understands LIRC, you could use the devinput driver for lircd. If not, you should be able to configure its keymap to match the "keyboard" keys expected by your application.