Re: [RFC v2] Another approach to IR

2009-12-04 Thread Ferenc Wagner
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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Andy Walls wrote: On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: ... (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Andy Walls wrote: On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: ... (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Jon Smirl wrote: On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Andy Walls
On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Both of those IR devices are/will be encapsulated in a v4l2_subdevice object internally. I

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Ferenc Wagner
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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
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).

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Jon Smirl
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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté
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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Dmitry Torokhov
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.

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté
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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté
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.

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Krzysztof Halasa
Jarod Wilson ja...@wilsonet.com writes: Perhaps we should clarify something here. Are we intending to auto-create a new input device for every IR command set we see arrive at the IR receiver? We don't want this, and we aren't really able to do this, because we never know if two different scan

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes: Btw, looking at that code, while it is not impossible to split the IR pulse/space measures from the NEC decoder itself, and make it generic to support other protocols, it is not a trivial task, and may result on a less stable driver. And it's

Re: [RFC v2] Another approach to IR

2009-12-03 Thread alhaz
Quoting Jon Smirl jonsm...@gmail.com: 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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Btw, looking at that code, while it is not impossible to split the IR pulse/space measures from the NEC decoder itself, and make it generic to support other protocols, it is not a trivial task, and may result on a

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Gerd Hoffmann
On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on is here: zweiblum kraxel

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Gerd Hoffmann wrote: On 12/01/09 22:05, Mauro Carvalho Chehab wrote: So, I would just add the IR sysfs parameters at the /sys/class/input, if the device is an IR (or create it is /sys/class/input/IR). No, you add it to the physical device node. The usb mouse on the system I'm working on

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 12:30:29PM -0500, Jon Smirl wrote: On Wed, Dec 2, 2009 at 12:10 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Dec 02, 2009 at 10:44:58AM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 07:05:49PM -0200, Mauro

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote transmitter that would be the best I think, but I

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver does not allow access to the raw stream - it will refuse binding to

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jon Smirl
On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: ... (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate by remote

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the remote itself), right? If we could separate

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jon Smirl
On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl jonsm...@gmail.com wrote: On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: The raw interface applies only to the devices that doesn't have a hardware decoder (something between 40%-60% of the currently supported devices). 50% is quite a number I think. But if driver

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming that,

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize).

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 03:42:13PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 3:14 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Jon Smirl wrote: IR devices transmit vendor/device/command triplets. They are easy to tell apart and create an evdev device corresponding to each vendor/device pair or something else along those lines. What they transmit depend on the used protocol. With NEC and RC5 (currently, the most

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Dmitry Torokhov
On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson 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

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Jon Smirl wrote: Some major use cases: using IR as a keyboard replacement, controlling X and apps with it in via mouse and keyboard emulation. using IR to control a headless embedded device possibly running multiple apps - like audio and home automation (my app) IR during boot when it is the

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
On Dec 2, 2009, at 3:48 PM, Dmitry Torokhov wrote: ... Personally, I've always considered the driver/interface to be the receiver, not the remote. The lirc drivers operate at the receiver level, anyway, and the distinction between different remotes is made by the lirc daemon. The fact

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Trent Piepho
On Wed, 2 Dec 2009, Jarod Wilson wrote: My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is actually coming from. Heh, right back

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 06:23:51PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: Now I understand that if 2 remotes send completely identical

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
On Dec 2, 2009, at 4:12 PM, Trent Piepho wrote: On Wed, 2 Dec 2009, Jarod Wilson wrote: My main point is that each of these devices has device ID that can be determined without having to first do some protocol analysis and table lookups to figure out which device some random IR input is

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jon Smirl
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize). I'm assuming

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Andy Walls
On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote: On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: ... (for each remote/substream that they can recognize). I'm assuming that, by remote, you're referring to a remote receiver (and not to the

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Andy Walls
On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: Didn't Jon posted his example whith programmable remote pretending to be several separate remotes (depending on the mode of operation) so that several devices/applications

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Mauro Carvalho Chehab
Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09 12:30 PM, Jon Smirl wrote: (for each remote/substream that they can recognize).

Re: [RFC v2] Another approach to IR

2009-12-02 Thread hermann pitton
Am Mittwoch, den 02.12.2009, 20:19 -0500 schrieb Andy Walls: On Wed, 2009-12-02 at 12:14 -0800, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 03:04:30PM -0500, Jarod Wilson wrote: Didn't Jon posted his example whith programmable remote pretending to be several separate remotes

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Trent Piepho
On Wed, 2 Dec 2009, Jon Smirl wrote: A bluetooth remote has a specific device ID that the receiver has to pair with. Your usb mouse and keyboard each have specific device IDs. A usb IR *receiver* has a specific device ID, the remotes do not. So there's the major difference from your

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jarod Wilson
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

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jon Smirl
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Jon Smirl wrote: On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote: On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote: On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote: On 12/2/09

Re: [RFC v2] Another approach to IR

2009-12-02 Thread Jon Smirl
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

[RFC v2] Another approach to IR

2009-12-01 Thread Jon Smirl
While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The first observation is that the IR profile of various devices are

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Maxim Levitsky
On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to eliminate it. The

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Jon Smirl
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Hi Jon, Jon Smirl wrote: On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Devin Heitmueller
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Patrick Boettcher
Hi, On Tue, 1 Dec 2009, Devin Heitmueller wrote: On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Maxim Levitsky wrote: On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: While reading all of these IR threads another way of handling IR occurred to me that pretty much eliminates the need for LIRC and configuration files in default cases. The best way to make everything just work is to

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Patrick Boettcher wrote: The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to it. I did

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Jon Smirl
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Due to the lack of an API for it, each driver has their own way to handle the protocols, but basically, on almost all drivers, even supporting different protocols, the driver limits the usage of just the protocol

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Dmitry Torokhov
On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime. Mauro, I

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote: Dmitry Torokhov wrote: On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote: For sure we need to add an EVIOSETPROTO ioctl to allow the driver to change the protocol in runtime.