Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov a écrit : On Mon, Dec 07, 2009 at 06:54:39PM +0100, Emmanuel Fusté wrote: Mauro Carvalho Chehab wrote: In summary, While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes up to 16 bytes (since a read loop for 2^16 is not that expensive), the current approach won't scale with bigger scancode spaces. So, it is needed expand it to work with bigger scancode spaces, used by more recent IR protocols. I'm afraid that any tricks we may try to go around the current limits to still keep using the same ioctl definition will sooner or later cause big headaches. The better is to redesign it to allow using different scancode spaces. I second you: input layer events from drivers should be augmented with a protocol member, allowing us to define new ioctl and new ways to efficiently store and manage sparse scancode spaces (tree, hashtable ). Userspace has no business knowing how driver maps hardware data stream into a keycode, only what is being mapped to what. The way is is done can change from driver-to-driver, from release to release. If I come up with an super-smart or super-stupid way of storing key mapping I won't want to modify userpsace tools to support it. But this is the point for IR. Userspace need a stable and universal driver to driver way to represent the hardware data stream. This is needed for only one but very important application: creating and modifying exchangeable remote mappings. The way of storing in kernel key mapping should not have any impacts on usersapce tools. If this is the case, this is because the actual ioctl is too tied to the way these mapping are stored. These need to changed or be expanded for IR. It will allow us to abstract the scancode value and to use variable length scancode depending on the used protocol, and using the most appropriate scheme to store the scancode/keycode mapping per protocol. The today scancode space will be the legacy one, the default if not specified protocol. It will permit to progressively clean up the actual acceptable mess in the input layer and finally using real scancode - keycode mappings everywhere if it is cleaner/convenient. I am unable to parse this part, sorry. My bad, my English is awful, sorry. :-( Best regards, Emmanuel. -- 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
Jon Smirl wrote: On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote: ... Now I understand that if 2 remotes send completely identical signals we won't be able to separate them, but in cases when we can I think we should. I don't have a problem with that, if its a truly desired feature. But for the most part, I don't see the point. Generally, you go from having multiple remotes, one per device (where device is your TV, amplifier, set top box, htpc, etc), to having a single universal remote that controls all of those devices. But for each device (IR receiver), *one* IR command set. The desire to use multiple distinct remotes with a single IR receiver doesn't make sense to me. Perhaps I'm just not creative enough in my use of IR. :) Most universal remotes I'm familiar with emulate multiple remotes. I.e. my tv remote generates one set of scancodes for the numeric keys. The DVD remote generates a different set. The amplifier remote in tv mode generates the same codes as the tv remote, and in dvd mode the same codes as the dvd remote. From the perspective of the IR receiver there is no difference between having both the DVD and TV remotes, or using the aplifier remote to control both devices. Okay, in the above scenario, you've still got a single input device... Now, my aplifier remote has a number of modes. Some control devices I have, like vcr mode, and there is nothing I can do about that. Some, like md mode don't control devices I have. That means they are free to do things on the computer. Someone else with the same remote (or any number of remotes that use the same protocol and scancodes) might have different devices. So I want my computer to do stuff when I push JVC MD #xx keys, but ignore JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to opposite. Rather than force everyone to create custom keymaps, it's much easier if we can use the standard keymaps from a database of common remotes and simply tell mythtv to only use remote #xxx or not to use remote #yyy. Sure, but the key is that this can't be done automagically. The IR driver has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not there's a separate input device per remote though. You can use multiple remotes/protocols with a single input device or lirc device already (if the hardware doesn't have to be put explicitly into a mode to listen for that proto, of course, but then its a hardware decoding device feeding a single input device anyway, so...). It sounds like you're thinking of a receiver that came bundled with a remote and that's it. Not someone with a number of remotes that came with different pieces of AV gear that they want to use with their computer. No, I just pick *one* remote and use it for everything, not schizophrenically hopping from one remote to another, expecting them all the be able to control everything. :) Its a hell of a lot easier to find buttons w/o looking at the remote if you always use the same one for everything, for one. Anyway, I think I'm talking myself in circles. Supporting multiple remotes via multiple input devices (or even via a single input device) isn't at all interesting to me for my own use, but if there really is demand for such support (and it appears there is), then fine, lets do it. Simple use case: You have a multifunction remote. Press the CABLE key - it sends out commands that control the cable box, press the TV key - now the commands control the TV, press CD - now the CD player, etc. Now imagine a headless Linux box running a music server and a home automation app. Press the CD key - commands get routed to the music server, press the AUX key - commands get routed to the home automation app. This is accomplished by recognizing the device code part of the IR signal and figuring out that there are two different device codes in use. The commands of then routed to two evdev devices corresponding to the two different device codes. Using things like Alt-Tab to switch apps is impossible. There's no screen to look at. This usecase makes sense to me. With the risk of repeating myself, you don't have two physical remotes. The needed feature is a way to split one source of input events (that happens to be an infrared remote, but it could also be any other type of input device, like a bluetooth remote) into several different evdev interfaces, based on scancode groups. In real world you generally have two physical remote. In this particular case you simply have a sort of semi-universal remote, a two or tree in one remote. More particularly, you have a remote which is aimed at talking to two or tree different real devices or in our case different applications. If the application
Re: [RFC v2] Another approach to IR
Em Thu, 3 Dec 2009 11:50:04 -0500 Jon Smirl jonsm...@gmail.com escreveu: On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Ferenc Wagner wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Dmitry Torokhov wrote: 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). Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, etc. On those remotes, if you press TV and then press for example Channel UP and press Radio, then press Channel UP, the channel UP code will be the same. For example, on Hauppauge Grey IR, we have: TV [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c keycode 0x179 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=1 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 down=0 CHANNEL UP [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 Radio [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c keycode 0x181 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=1 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 down=0 CHANNEL UP [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 keycode 0x192 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=1 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 down=0 In this IR, the address is bogus: it is always 0x1e. This scenario is very common with the shipped IR's. The remote is treating everything as a single integrated device which is not inconsistent with what has been said. In this case there really is only one multi-function device not two independent ones. If you want to control two independent devices you need to buy a different remote. Remotes are cheap so that's not a big deal. If you really want to use this remote to control two independent devices you need user space scripting to split the single device into two devices and then inject new events into the input layer. This is a complex case and not in the goal of getting 90% of users to just work. This remote is a typical example of the IR's that are provided together with media boards. On all such IR's I know, it does generate one key event for TV, SAT, DVB, DVD... keys and this event doesn't change the status of subsequent keys. 100% of the users of such boards will have the shipped IR. Some amount will be happy of just using the provided IR to control different applications at their computer or embedded hardware, and some amount will prefer to buy a multi-purpose IR that will allow him to control not only his computer, but also, his TV, his Air conditioning, etc. Both usages should be supported. All I'm saying is that, in the case where people have only the shipped IR, if he wants to see TV, the produced keycode will be KEY_TV, and then to change a channel, it will receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, he will press KEY_DVB and then KEY_PLAY to play his movie. So, an application like MythTV should be able to work with those keys. Eeeerrrkkk, what a .. device . For such quirky device, we could imagine a special mapping support: We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the input layer to surcharge the vendor or device with a specific value/mask for following keypresses of such remote. The mask could be choose to generate out of bound value in regards of the used protocol for the vendor or the device part to not overlap with another existing remote. Generate a complete map and so a device for each special key and you're done. No special case on the application side. In kernel states are a bit ugly, but this particular case is not too complicated and your dumb shitty remote is promoted to first class one. Regards, Emmanuel. -- 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
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 codees like that. Yes, it seem that there is confusion here. Forget my proposition. It is a corner case that could be handled later if needed. Cheers, Emmanuel. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
It is perhaps time to resurrect Jon Smirl's work about In-kernel IR remote control support ? See http://marc.info/?l=linux-kernelm=122591465821297w=2 and all discussions around it. Regards, Emmanuel. --- Laposte.net fête ses 10 ans ! Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... vous aussi, pour votre adresse e-mail, choisissez laposte.net. Laposte.net, bien + qu'une messagerie -- 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
