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: Gerd Hoffmann on 26 Nov 2009 03:40 On 11/26/09 08:28, Christoph Bartelmus wrote: > Hi Gerd, > > on 26 Nov 09 at 00:22, Gerd Hoffmann wrote: > [...] >>> To sum it up: I don't think this information will be useful at all for >>> lircd or anyone else. > [...] >> I know that lircd does matching instead of decoding, which allows to >> handle unknown encodings. Thats why I think there will always be cases >> which only lircd will be able to handle (using raw samples). >> >> That doesn't make attempts to actually decode the IR samples a useless >> exercise though ;) > > Well, in my opinion it is kind of useless. I don't see any use case or any > demand for passing this kind of information to userspace, at least in the > LIRC context. > If there's no demand, why bother? There have been complains about this getting lost somewhere in this thread, so it looks like there are people which do care. cheers, Gerd -- 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 26 Nov 2009 07:20 Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >>> (This is no recommendation for lirc. I have no idea whether a >>> pulse/space -> scancode -> keycode translation would be practical >>> there.) > > It would, but not exactly in the present shape. > >> For example, there are several bttv and saa7134 devices that polls (or receive >> IRQ interrupts) to detect pulses (and the absense of them) in order to create >> a pulse/space code. The conversion from pulse/space to scancode is done inside >> the driver, with the help of some generic routines and based on the protocol >> specifications. > > Right. There are currently several problems (I'm quite familiar with > saa713x RC5 code): the one that it barely works and is not implemented > for most such "GPIO/IRQ-driven" cards (as of 2.6.29 or so). This could > be fixed, I even have a working though quick&dirty patch. Another: the > RC5 allows for groups and codes within groups. The mapping can only use > one group, and there can only be one mapping. These design limitations > mean it's unusable in many cases. This is a current limitation, since the saa713x code converts the RC5 code into a 7bits scancode, by applying a mask. One of the reasons for that conversion is that the two ioctls that allows reading/changing the keycode table (EVIOCSKEYCODE and EVIOCGKEYCODE) were implemented via a table with a fixed size of 128 entries. We already have an implementation at the dvb-usb driver that uses a table without such limits, where the IR scancode is completely stored there. So, you can create any arbitrary scancode <--> keycode table there. Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a way for doing it without causing regressions, and to find a group of people that will help testing the new way. Maybe one alternative would be to add a modprobe parameter at the converted drivers to allow them to work with the old behavior, after their migration. >> Those devices where the decoding is done by software can support any >> IR protocols. > > Yes, and there can be multiple remote controllers, and multiple code > groups within a remote. > >> This can be solved by adding a few ioctls to enumerate the supported >> protocols and to select the one(s) that will be handled by the kernel >> driver. > > The driver may have to handle many protocols simultaneously. This is not > a problem from a technical POV. There are 3 different situations: 1) hardware where you can support multiple protocols at the same time; 2) hardware that supports one programmable protocol; 3) hardware that support just one (or a limited set) of protocols. In general, (1) applies only to those devices that outputs a raw pulse/space code, where they just connect the IR sensor to a generic I/O pin and let the software to decode the code. This is the case of most of cheapest devices. Yet, you can find some cheap devices with low-cost micro-controllers with a dedicated firmware on its ROM, doing (2). The most commonly found hardware, in general have a chip to decode IR pulse/space sequences, converting it on a scancode and implementing (3). That's said, a raw input interface, only fits on case (1). On the other hand, the existing input API works for all types of IR. However, we need to add the ioctls to allow protocol selection, to better handle (1) and (3). 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 26 Nov 2009 07:40 Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > >> 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. > > IOW the driver generates artificial pulse code for lircd? > I think - pure bloat. lircd can get events from input layer without > problems. Perhaps I misunderstood? lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. > >> It is very bad to have two interfaces for the same thing, because people >> may do things like that. > > I think having a "raw" scan code interface + the key code "cooked" mode > is beneficial. For remotes lacking the raw interface only the latter > could be used. It sounds an interesting idea. >> Are you meaning that we should do more than one RC per input event >> interface? > > I think so. Why not? > > For example, one of my remotes generates codes from at least two RC5 > groups (in only one "mode"). Currently a remote is limited to only one > RC5 group. Yet, both are RC5. This can already be handled by the input layer. See dvb-usb implementation. The issue I see is to support at the same time NEC and RC5 protocols. While this may work with some devices, for others, the hardware won't allow. > > I think the mapping should be: key = proto + group + raw code, while > key2 could be different_proto + different group (if any) + another code. This may work for protocols up to RC5, that uses either 8 or 16 bits. However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits for a scancode. So, we don't have spare bits to represent a protocol, if we consider RC6 mode 6 codes as well. >> If so, why do you think we need to handle more than one IR protocol at >> the same time? > > Why not? > There are X-in-1 remotes on the market for years. They can "speak" many > protocols at once. One may want to have a protocol to handle DVD apps > while another for DVB etc. > And someone may want to use several different remotes, why not? > Personally I use two different remotes (both set to speak RC5 but what > if I couldn't set the protocol?). Sure, it requires a bit of hackery > (not with pulse code and lircd). > >> I think this will just make the driver more complex without need. > > Not much more, and there is a need. See above. Also, several protocols have a way to check if a keystroke were properly received. When handling just one protocol, we can use this to double check the key. However, on a multiprotocol mode, we'll need to disable this feature. PS.: For those following those discussions that want to know more about IR protocols, a good reference is at: http://www.sbprojects.com/knowledge/ir/ir.htm Unfortunately, it doesn't describe RC6 mode 6. 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: Andy Walls on 26 Nov 2009 07:40 On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote: > On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote: > > > On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote: > >> 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. > > > > Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are > > forced to support lirc because the remores are not available through > > other means? I believe it is the latter and applications writers would > > be happy to reduce number of ways they get button data. > > Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. serial receivers and transmitters, both supported by lirc_serial, were the most frequently used devices outside of plain old keyboards. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that... > > > I don't think there is LIRC aversion per se. We are just trying to > > decide whether multiple interfaces for the same data is needed. And > > I don't think that we will completely reject userspace components. Just > > as input subsystem allows for userspace drivers I do not think why we > > can't have the same for the LIRC. But I do think that the primary > > interface for regular userspace consumers (read mplayer and MythTV and > > the likes) should be input event interface (EV_KEY/KEY_*). > > Works for me. Even though two interfaces is a bit of "extra" work, I'm not averse to Gerd's suggestions of a dual implementation: input layer for the simple, common use case, and lirc type interface for more sophisticated usage. One thing I would like to be provided by the input layer is automatic key-up after a specified time. Remote protocols send an initial button press and then after a certain amount of time (~115 ms for RC-5) send a repeated code or repeat sequence, if the button is still pressed. Currently, most of the V4L-DVB drivers have some code to perform a timeout just to send the key-up event. That's a good bit of redundant code for key-up timeouts that I suspect makes sense for the input layer to handle. 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 26 Nov 2009 08:20
Andy Walls wrote: > I generally don't understand the LIRC aversion I perceive in this thread > (maybe I just have a skewed perception). > Regards, > Andy "LIRC Fan-Boy" Walls This is not a lirc love or hate thread. We're simply discussing the better API's for IR, from the technical standpoint, considering that some users may want to use lirc and some users may want to have their IR working out-of-the-box. By not using lirc, users will loose the advantages of having lircd, like clicking on a button and calling automatically the DVD player application, but this means that their device with the shipped IR will work without needing to do any setup. Whatever we do, both kind of usages should be possible, since there are demand for both. Also, the decision should consider that the existing drivers will need to support the new way without causing regressions. 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/ |