Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab mche...@redhat.com writes: Jon Smirl wrote: This model is complicated by the fact that some remotes that look like multi-function remotes aren't really multifunction. The remote bundled with the MS MCE receiver is one. That remote is a single function device even though it has function buttons for TV, Music, Pictures, etc. An unsolved question on my mind is how should we map such IR's? Should we provide a way for them to emulate a multifunction IR (for example, after pressing TV key, subsequent keystrokes would be directed to the TV evdev device?), or should we let this up to some userspace app to handle this case? This case feels similar to that of Caps Lock, Num Lock and Scrool Lock, but I don't know if that scheme could be applied here. -- Regards, Feri. -- 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
Re: [RFC v2] Another approach to IR
Dmitry Torokhov dmitry.torok...@gmail.com writes: On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: We should not forget that simple IR's don't have any key to select the address, so the produced codes there will never have KEY_TV/KEY_DVD, etc. Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select media inputs in a device/application. My receiver accepts codes like that. Sorry, my point wasn't the event names, I picked them for their superficial correspondence to the TV, DVD, SAT etc. buttons found on multifunction remotes. Obviously I picked wrong. I was also wrong to assume that remotes with such buttons are always multifunction remotes in the sense that they are meant to control separate devices. As Mauro pointed out, (some) bundled remotes with such buttons aren't; thus I wouldn't consider them multifunction at all. They simply have some extra buttons labelled TV, DVD etc, which probably shouldn't be mapped to KEY_TV, KEY_DVD etc. (since those events carry different semantics) but should be mapped to something else. Or not, if these buttons change some internal decoder state instead, modifying the mapping or destination input device of the other keys. It's just a different scenario, where the kernel could reasonably give rather different representations to simple applications aiming at plugplay: letting through the function change events untouched, or masking and using them internally. True multifunction devices don't send such events, the TV, DVD etc buttons on them change their internal state and the scan codes sent by the other keys, if I understand this correctly. I'd prefer if these two behaviours could be abstacted from, and the input layer interface would provide destination selection events + generic events, or (to be defined) device specific events only in either case. Is that possible or even reasonable? -- Thanks, Feri. Ps: I'm writing this in the hope to clean up the landscape and possibly help in choosing the best design. I'm not at all familiar with IR, and the above distinction was pretty surprising for me. Also, I'm just lurking here, so don't take me too seriously. :) -- 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
Re: [RFC v2] Another approach to IR
Mauro Carvalho Chehab mche...@redhat.com writes: Dmitry Torokhov wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: Now I understand that if 2 remotes send completely identical signals we won't be able to separete them, but in cases when we can I think we should. They are the same key events (Lets's say KEY_PLAY) but one is supposed to affect CD player while another DVD player application. Evdev will not be able to distinguish them but if we had 2 separate devices then applications could read from the one thet user assigned to them. This is clear, but the point is that the two distinguish scancodes can (and, in practice, will) be generated by the same IR. For example, my Satellite IR produces two different sets of codes. if you press SAT, all keys you press after that will have the sat address. If you press TV, they'll get a different address. The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT, KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent by any remote (ok, I'm stretching it a bit). Instead, a multifunction remote (or two distinct remotes) would send different scan codes[1], which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example. Btw. the former is already defined, besides the generic KEY_PLAY. Even if all this worked, user space would need integration with hal/devicekit to open the new input devices appearing on the fly (if it's initiated by the arrival of a scan code belonging to some new protocol), and also be able to decide whether the new event source is for it or not. Given that commodity home appliances manage not to be confused by multiple or multifunction remotes, decent software should be able to do so as well. [1] scan codes in the broadest possible sense, containing vendor, address and whatever, and only treating the case which is possible to handle in principle. -- Regards, Feri. -- 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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl jonsm...@gmail.com writes: On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus l...@bartelmus.de wrote: Maybe we decide to take the existing LIRC system as is and not integrate it into the input subsystem. But I think there is a window here to update the LIRC design to use the latest kernel features. If it ain't broke, don't fix it. [...] We already agreed last year that we can include an interface in lirc_dev that feeds the signal data to an in-kernel decoder if noone from userspace reads it. [...] I also understand that people want to avoid dependency on external userspace tools. All I can tell you is that the lirc tools already do support everything you need for IR control. And as it includes a lot of drivers that are implemented in userspace already, LIRC will just continue to do it's work even when there is an alternative in-kernel. Christoph, take what you know from all of the years of working on LIRC and design the perfect in-kernel system. Hi, I'm reading this thread with great interest. Thank you (plural) for the very informative conversation, I think I learnt a lot. But now I somehow lost the point, please correct me if the following is wrong. It looks like having lirc_dev (or a similar raw interface) is a must. It could be disguised as an input device, or changed in various ways, but is it worth the effort? As I understand Christoph, he does not want to do so, because he finds it wasted work, and also there's already a *single* user space daemon using it and doing everything users could want. Except for plugplay. On the other hand, a one-liner could make in-kernel decoding possible, so those who haven't got lircd running could have plugplay easily, if somebody writes the necessary in-kernel decoders to feed the input subsystem (which lircd also does, through uinput). But even if you can't find anybody at the moment to write those, this is still good stuff (I don't know about the code), which is hurt by being developed out of kernel. Is there any reason to keep this so? Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if somebody pointed me to some reading. -- Thanks, Feri. -- 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
