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: Krzysztof Halasa on 23 Nov 2009 18:00 Devin Heitmueller <dheitmueller(a)kernellabs.com> writes: > For example, you might want the IR receiver to be listening for codes > using the "Universal Remote Control XYZ" profile and the IR > transmitter pretending to be "Cable Company Remote Control ABC" when > blasting IR codes to the cable box. Ideally, there would be a single > shared database of the definitions of the remote controls, regardless > of whether you are IR receiving or transmitting. Well, with different receivers, the maps must certainly be different. There can be single database in the userspace but the kernel must be uploaded the relevant info only. -- 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/
From: Andy Walls on 23 Nov 2009 20:00 On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: > Czesc Krzysztof, > > on 23 Nov 09 at 15:14, Krzysztof Halasa wrote: > [...] > > I think we shouldn't at this time worry about IR transmitters. > > Sorry, but I have to disagree strongly. > Any interface without transmitter support would be absolutely unacceptable > for many LIRC users, including myself. I agree with Christoph. Is it that the input subsystem is better developed and seen as a leverage point for development and thus an "easier" place to get results earlier? If so, then one should definitely deal with transmitters early in the design, as that is where the most unknowns lie. With the end of analog TV, people will have STBs feeding analog only video cards. Being able to change the channel on the STB with an IR transmitter controlled by applications like MythTV is essential. And on some different notes: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. I believe Jarod's intent is to have the LIRC components, that need to be in kernel modules, moved into kernel mainline to avoid the headaches of out of kernel driver maintenance. I'm not sure it is time well spent for developers, or end users, to develop yet another IR receive implementation in addition to the ones we suffer with now. I would also note that RC-6 Mode 6A, used by most MCE remotes, was developed by Philips, but Microsoft has some sort of licensing interest in it and it is almost surely encumbered somwhow: http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt "Microsoft recommends the Microsoft-Philips IR protocol (based on RC6) * You can become a licensee at no charge to you [...] * How to license RC6 * Contact RemoteMC @ microsoft.com for license agreement" I would much rather that RC-6 be handled as much as possible in user space than in the kernel. LIRC userspace components already handle it, IIRC. Regards, Andy "LIRC Fan-Boy" Walls -- 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 23 Nov 2009 20:20 On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote: > lirc(a)bartelmus.de (Christoph Bartelmus) writes: > > >> I think we shouldn't at this time worry about IR transmitters. > > > > Sorry, but I have to disagree strongly. > > Any interface without transmitter support would be absolutely unacceptable > > for many LIRC users, including myself. > > I don't say don't use a transmitter. > I say the transmitter is not an input device, they are completely > independent functions. I can't see any reason to try and fit both in the > same interface - can you? The underlying hardware need not be completely independent. For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012] chips have IR hardware that shares a common timing source, interrupt line, interrupt status register, etc, between IR Rx and Tx. They can also do things like loopback of Tx to Rx. That said, an underlying hardware implementation can be split up to user space with separate interfaces Tx and Rx. The underlying driver module would have to manage the dependencies. I would guess that would be easier for driver modules, if the userspace interfaces were designed with such combined IR Tx/Rx hardware in mind. 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: Jarod Wilson on 23 Nov 2009 23:20 On 11/23/2009 04:10 PM, Christoph Bartelmus wrote: > Hi Jarod, > > on 23 Nov 09 at 14:17, Jarod Wilson wrote: >>> Krzysztof Halasa wrote: > [...] >>> 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. > > No, it's not. > I think you misunderstood the code. The comment may be a bit misleading, > too. > Early iMON devices did not decode in hardware and the part of the driver > that Krzystof is referring to is translating a bit-stream of the sampled > input data into pulse/space durations. Sorry, no, I know the newer devices don't actually send pulse/data info out to userspace, just hex codes that correspond to key presses. What I meant was "onboard decoding devices can operate as pure input devices or in classic lirc mode", leaving out the details on exactly what they were sending out to userspace. :) -- Jarod Wilson jarod(a)wilsonet.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: Jarod Wilson on 23 Nov 2009 23:40
On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: > On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: >> Mauro Carvalho Chehab<mchehab(a)redhat.com> writes: >> >>> Event input has the advantage that the keystrokes will provide an unique >>> representation that is independent of the device. >> >> This can hardly work as the only means, the remotes have different keys, >> the user almost always has to provide customized key<>function mapping. >> > > Is it true? I would expect the remotes to have most of the keys to have > well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. .... >> We need to handle more than one RC at a time, of course. >> >>> So, the basic question that should be decided is: should we create a new >>> userspace API for raw IR pulse/space >> >> I think so, doing the RCx proto handling in the kernel (but without >> RCx raw code<> key mapping in this case due to multiple controllers >> etc.). Though it could probably use the input layer as well(?). >> > > I think if the data is used to do the primary protocol decoding then it > should be a separate interface that is processed by someone and then fed > into input subsystem (either in-kernel or through uinput). > > Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for > keys and buttons on all devices. Current lircd actually inter-operates with the input subsystem quite well for any and all supported remotes if their keys are mapped in their respective lircd.conf file using standard input subsystem key names, and the lirc daemon started with the --uinput param. lircd decodes the raw IR, finds the mapping in its config, and happily passes it along to uinput. -- Jarod Wilson jarod(a)wilsonet.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/ |