Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
in [Kernel]
|
Prev: x86, crypto, Use gas macro for PCLMULQDQ-NI and PSHUFB
Next: [patch 6/8] x86: UV - XPC NULL deref when mesq becomes empty.
From: Andy Walls on 8 Dec 2009 07:40 On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: > On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: > > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the > > end of the month. > > > > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with > > a common set of parameters, so I may be able to set up the decoders to > > handle decoding from two different remote types at once. The HVR boards > > can ship with either type of remote AFAIK. > > > > I wonder if I can flip the keytables on the fly or if I have to create > > two different input devices? > > > > Can you distinguish between the 2 remotes (not receivers)? Yes. RC-6 and RC-5 are different enough to distinguish between the two. (Honestly I could pile on more protocols that have similar pulse time periods, but that's complexity for no good reason and I don't know of a vendor that bundles 3 types of remotes per TV card.) > Like I said, > I think the preferred way is to represent every remote that can be > distinguished from each other as a separate input device. OK. With RC-5, NEC, and RC-6 at least there is also an address or system byte or word to distingish different remotes. However creating multiple input devices on the fly for detected remotes would be madness - especially with a decoding error in the address bits. Any one vendor usually picks one address for their bundled remote. Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. > Applications > expect to query device capabilities and expect them to stay somewhat > stable (we do support keymap change but I don't think anyone expectes > flip-flopping). OK. -- 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: Andy Walls on 8 Dec 2009 07:50 On Tue, 2009-12-08 at 09:32 -0200, Mauro Carvalho Chehab wrote: > Andy Walls wrote: > > On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote: > > So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the > > end of the month. > > Good! Please, try to design the decoder as an independent module that gets > data from a kfifo and generate scancodes for the input API. Hmmm. Let me see how the protoype turns out keeping that design objective in mind. I've already got the current RC-5 and NEC decoding state machines in cx23885-input a bit layered, but they are taking advantage of specific events signaled by my v4l2_subdev implementation. Strictly speaking the state machines don't have to. All of the remote protocols I have played with make framing pretty easy. > > I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with > > a common set of parameters, so I may be able to set up the decoders to > > handle decoding from two different remote types at once. The HVR boards > > can ship with either type of remote AFAIK. > > > > I wonder if I can flip the keytables on the fly or if I have to create > > two different input devices? > > IMO, the better is, by default, to open just one input device per IR receiver. > >From what I understand from our discussions, if the user wants to filter IR > commands into several input interfaces, some userspace interface will be > provided to allow the creation of other input interfaces for that purpose. Hmm. That's not what I just thought I read from Dmitry.... Oh well. If I don'y get it done by 24 Dec, it'll be in the new year. Regards, Andy -- 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 8 Dec 2009 08:40 Andy Walls wrote: > On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote: >> On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote: > >>> So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the >>> end of the month. >>> >>> I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with >>> a common set of parameters, so I may be able to set up the decoders to >>> handle decoding from two different remote types at once. The HVR boards >>> can ship with either type of remote AFAIK. >>> >>> I wonder if I can flip the keytables on the fly or if I have to create >>> two different input devices? >>> >> Can you distinguish between the 2 remotes (not receivers)? > > Yes. RC-6 and RC-5 are different enough to distinguish between the two. > (Honestly I could pile on more protocols that have similar pulse time > periods, but that's complexity for no good reason and I don't know of a > vendor that bundles 3 types of remotes per TV card.) You'll be distinguishing the protocol, not the remote. If I understood Dmitry's question, he is asking if you can distinguish between two different remotes that may, for example, be using both RC-5 or both RC-6 or one RC-5 and another RC-6. >> Like I said, >> I think the preferred way is to represent every remote that can be >> distinguished from each other as a separate input device. > > OK. With RC-5, NEC, and RC-6 at least there is also an address or > system byte or word to distingish different remotes. However creating > multiple input devices on the fly for detected remotes would be madness > - especially with a decoding error in the address bits. > > Any one vendor usually picks one address for their bundled remote. > Hauppaugue uses address 0x1e for it's RC-5 remotes AFAICT. The address field on RC-5 protocol is not meant to distinguish different vendors, but different "applications". It identifies that a code should be sent to a TV or a VCR, or a DVD or a SAT. In the case of bundled IR's, some vendors like Hauppauge opted to use a reserved address to avoid conflicts with other equipments. It happens that vendor's "reserved address" can be different between two different vendors, but is just an educated guess to say that an address equal to 0x1e is Hauppauge. 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 8 Dec 2009 09:30 Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: >> IMO, the better is to have an API to allow creation of multiple interfaces >> per IR receiver, based on some scancode matching table and/or on some >> matching mask. > > I think setting the keytables for each logical device would do. Yes. > > I.e. just have a way to create additional logical devices. Each can have > its own keytable. The decoders would send their output to all logical > remotes, trying to match the tables etc. > >> It should be possible to use the filter API to match different IR's by >> vendor/product on protocols that supports it, > > That would mean unnecessary limiting. If the mask is (unsigned)-1, it will not add any limit. This should be the default. The advantage of the mask is that you can speedup the keycode decoding by not calling a seek routine in the cases where it doesn't make sense. Also, the cost of scancode & scancode_mask is cheap enough, comparing with the potential optimization gain of not seeking a data in a table that wouldn't match anyway. Also, the IR core may automatically generate such mask, by doing an "and" operation of all the scancodes at the table during table initialization/changes. If the mask is zero, it defaults to use a (unsigned) -1 mask. 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: Krzysztof Halasa on 8 Dec 2009 18:40
Jon Smirl <jonsmirl(a)gmail.com> writes: > Why do you want to pull the 1KB default mapping table out of the > device driver __init section and more it to a udev script? Now we will > have to maintain a parallel udev script for ever receiver's device > driver. Of course no. We will need a single program (script etc.) for all devices. And we will need a database of the known remotes (scan and key codes). > You can handle that with __devinit __devinit is NOP with hot-plug. Fortunately we don't need the keymaps in the kernel. For certain uses we may (and may not) need to have one keymap built-in, perhaps something similar to the embedded initrd. -- Krzysztof Halasa -- 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/ |