I'm a bit short on time to write up a more complete reply to anything in this 
thread at the moment, but a few quick notes interspersed below.


On Nov 23, 2009, at 12:29 PM, Mauro Carvalho Chehab wrote:

> Krzysztof Halasa wrote:
>> Mauro Carvalho Chehab <mche...@redhat.com> writes:
...
>>> Considering the common case
>>> where the lirc driver will be associated with a media input device, the
>>> IR type can be detected automatically on kernel. However, advanced users may
>>> opt to use other IR types than what's provided with the device they
>>> bought.
>> 
>> I think most users would want to do that, though I don't have hard
>> numbers of course. Why use a number of RCs simultaneously while one will
>> do?
> 
> If you're building a dedicated hardware to act as a MCE, it makes sense to
> use just one IR to control your TV and your hardware, but the common usage
> is to add a TV board or stick to your desktop to see TV. For this,
> the standard IR fits well.

The main use case that I have personal experience using IR and capture devices 
is with MythTV. Its not at all uncommon for a MythTV user to have a setup where 
the capture devices are attached to a completely different system from the 
system where the IR part needs to be. MythTV is client-server -- the backend 
server does the video capture via the capture devices, and the frontend client 
plays back the video, and its the frontend client that you navigate via an IR 
remote control. There are quite a few available IR options that are NOT tied to 
a video capture device at all -- the mceusb and imon drivers submitted in my 
patch series are actually two such beasts.

And particularly with the mceusb receivers, because they support damn near 
every IR protocol under the sun at any carrier frequency, using a remote other 
than the bundled one is quite common. Most people's set top boxes and/or 
televisions and/or AV receivers come with a remote capable of controlling 
multiple devices, and many bundled remotes are, quite frankly, utter garbage. I 
use a Logitech Harmony 880 universal remote myself.


>>> It should also be noticed that not all the already-existing IR drivers
>>> on kernel can provide a lirc interface, since several devices have
>>> their own IR decoding chips inside the hardware.
>> 
>> Right. I think they shouldn't use lirc interface, so it doesn't matter.
> 
> If you see patch 3/3, of the lirc submission series, you'll notice a driver
> that has hardware decoding, but, due to lirc interface, the driver generates
> pseudo pulse/space code for it to work via lirc interface.

Historically, this is true. But the version I submitted actually defaults to 
operating as a pure input layer device for all the imon devices that do onboard 
decoding. There are older imon devices that don't do onboard decoding, and I 
retained "legacy", if you will, lirc interface support in this pass of the 
driver for the onboard decode devices for those that want to keep things 
running as they always have (via a modparam).

More replyification later tonight...

-- 
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to