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 <mchehab@xxxxxxxxxx> 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 jarod@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
