On Mon, Feb 9, 2009 at 6:54 AM, Patrick Boettcher <patrick.boettcher@xxxxxxx> wrote: > Hi, > > On Sun, 8 Feb 2009, Michael Müller wrote: >>> >>> While I am indeed strongly in favor of integrating dib0700 with >>> ir_keymaps.c so it is consistent with the other drivers, I have been >>> tied up in another project and haven't had any cycles to do the work >>> required. >>> >>> By all means, if you want to propose a patch, I would be happy to >>> offer feedback/comments. >> >> Hi Devin, >> >> yes, it was my intention to offer some help. >> >> My hope was to find some similarities that I could use for dibcom. But >> everything looks different. And they deal with GPIO. So it looks much more >> complicated than just simply adding some keys to a table. ;-) >> >> Do you have an idea which of the modules listed above is closest to the >> dibcom module? Can you (easily) create a frame/template that I can use for a >> start and I add details and does the testing? >> >> Is the existing ir_keymaps approach already able to handle the case that I >> need to set dvb_usb_dib0700_ir_proto=0 (=> no NEC protocol) for my Elgato? > > If you are going to ir_keymap or any other superior solution (which I'm > for), please don't consider the dib0700-driver only, but think about the > whole dvb-usb-framework... Only the driver specific part can be found in the > drivers. The input-stuff is located in dvb-usb-remote.c > > Loading the ir-tables from userspace would be the preferred solution, like > that any IR-receiver on any device could handle any remote-control > (requiring a generic IR-decoder in the device's firmware) without changing > the kernel-module-driver... > > Is lirc already in-kernel now? Can the event-interface handle raw keys (so > that a user-space thing could translate them to their real meaning?) > > Patrick. > > -- > Mail: patrick.boettcher@xxxxxxx > WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ Hello, Just to be clear, I agree completely with Patrick and did not intend for it to come across that the solution should be dib0700 specific. I mentioned it in the context of dib0700 because that is the device the user is experiencing the issue with, as well as the only device in the dvb_usb framework I am personally familiar with. Regarding lirc, this is a challenging issue: On one hand, it is logical for the remote control definitions to be in userland, as this allows the user to change the keymaps easily, and the IR receiver could be seen by the kernel as "just another RC5 or RC6 receiver". On the other hand, the in-kernel management allows it to work as it did before without the need for lirc, as well as allowing the driver implementer to provide the "default keymap" associated with the remote control that ships with the product. If the keymaps were in the lirc userland package then the developer would have to ensure that the userland package got updated in all the distributions, as well as the users getting lircd to work properly (which given the debugging in the daemon, is an *enormous* challenge for most users). At this point, I think the goal should be to get as many of the drivers as possible centralized into ir_keymaps. This allows the drivers to behave consistently, and if we can come up with a userland solution then it can be supported for every device at the same time. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
