Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: > On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab > wrote: > >> [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a >> software >> decoder, the IR IRQ might be used to wake, but this means that everything, >> even a glitch, would wake the hardware, so this won't work neither. > > On my embedded hardware there is 100KB of static RAM on the CPU die. > It is preserved even in deep sleep. An IR pulse can wake the CPU and > run code in this 100KB RAM. Then the CPU can decide whether it wants > to power on main RAM and restore the OS. But implementing this is > outside the scope of the Linux kernel. > > In someways this is how an MSMCE behaves in suspend. There is code > running on the MCU inside the MSMCE receiver. Too bad we can't tell it > a pattern to watch for and then trigger USB wake up. It is easy to > build a MSMCE clone, maybe someone will clone it and add the wakeup > pattern match. An enterprising hacker can probably change the firmware > in the existing devices. Waking up the entire hardware just because an IRQ was triggered doesn't seem a good idea on PC's. Here, I had to put the IR sensors behind the table to avoid receiving too many noise from my room's lamp. If I put it on the right place, I start receiving several of glitches per second. I doubt this would be useful for suspend/resume operations. -- Cheers, Mauro -- 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?
Hi! Am Freitag, den 09.04.2010, 20:32 -0300 schrieb Mauro Carvalho Chehab: > Andy Walls wrote: > > On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: > >> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab > >> wrote: > >>> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the > >>> machine. So, by > >>> associating some scancode to KEY_POWER via ir-core, the driver can > >>> program the hardware > >>> to wake up the machine with the corresponding scancode. I can't see a > >>> need for a change at > >>> ir-core to implement such behavior. Of course, some attributes at sysfs > >>> can be added > >>> to enable or disable this feature, and to control the associated logic, > >>> but we first > >>> need to implement the wakeup feature at the hardware driver, and then > >>> adding some logic > >>> at ir-core to add the non-hardware specific code there. > >> Really? Have you actually seen any hardware where a particular scan > >> code can be used to wake up the hardware? The only hardware I have > >> seen has the ability to unsuspend on arrival of IR traffic, but you > >> didn't have the granularity to dictate that it only wake up on > >> particular scancodes. > > > > The CX23888 and CX23102 can do it. Basically any IR pulse pattern your > > heart desires; within reason. And any carrier freq you want too; within > > reason. > > > > But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere > > near properly supporing suspend/resume for their main video and DMA > > functions, AFAIK. > > AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching > TV, > do a suspend and waking the hardware again, and you'll keep seeing the same > channel (I tested it some time ago, when the proper suspend code were added, > on analog mode, with alsa enabled). Other drivers can suspend/resume, but > they won't properly restore the video registers, so, you'll see artifacts when > it returns. Yes, that was Maxim with enough testers around and Matthias Schwarzott had fixes. To remind, we don't recover from suspend on DVB, needs to reload the driver once. We are also not MFE ready with mixed init calls through v4l and dvb. But yes, analog is on leading edge on that ;) Cheers, Hermann > So, yes, you're right: before any suspend/resume code on those drivers, we > first need to add some code to properly handle kernel threads and work queues > during suspend, and to restore all the registers to a sane state at resume, > before implementing IR wakeup on them. > > In the case of mceusb, as there is already an userspace code for it on lirc, > it would probably not be that hard to make this feature to work with ir-core. > > [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software > decoder, the IR IRQ might be used to wake, but this means that everything, > even a glitch, would wake the hardware, so this won't work neither. > -- 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?
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab wrote: > [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software > decoder, the IR IRQ might be used to wake, but this means that everything, > even a glitch, would wake the hardware, so this won't work neither. On my embedded hardware there is 100KB of static RAM on the CPU die. It is preserved even in deep sleep. An IR pulse can wake the CPU and run code in this 100KB RAM. Then the CPU can decide whether it wants to power on main RAM and restore the OS. But implementing this is outside the scope of the Linux kernel. In someways this is how an MSMCE behaves in suspend. There is code running on the MCU inside the MSMCE receiver. Too bad we can't tell it a pattern to watch for and then trigger USB wake up. It is easy to build a MSMCE clone, maybe someone will clone it and add the wakeup pattern match. An enterprising hacker can probably change the firmware in the existing devices. -- Jon Smirl jonsm...@gmail.com -- 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?
Andy Walls wrote: > On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: >> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab >> wrote: >>> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the >>> machine. So, by >>> associating some scancode to KEY_POWER via ir-core, the driver can program >>> the hardware >>> to wake up the machine with the corresponding scancode. I can't see a need >>> for a change at >>> ir-core to implement such behavior. Of course, some attributes at sysfs can >>> be added >>> to enable or disable this feature, and to control the associated logic, but >>> we first >>> need to implement the wakeup feature at the hardware driver, and then >>> adding some logic >>> at ir-core to add the non-hardware specific code there. >> Really? Have you actually seen any hardware where a particular scan >> code can be used to wake up the hardware? The only hardware I have >> seen has the ability to unsuspend on arrival of IR traffic, but you >> didn't have the granularity to dictate that it only wake up on >> particular scancodes. > > The CX23888 and CX23102 can do it. Basically any IR pulse pattern your > heart desires; within reason. And any carrier freq you want too; within > reason. > > But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere > near properly supporing suspend/resume for their main video and DMA > functions, AFAIK. AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV, do a suspend and waking the hardware again, and you'll keep seeing the same channel (I tested it some time ago, when the proper suspend code were added, on analog mode, with alsa enabled). Other drivers can suspend/resume, but they won't properly restore the video registers, so, you'll see artifacts when it returns. So, yes, you're right: before any suspend/resume code on those drivers, we first need to add some code to properly handle kernel threads and work queues during suspend, and to restore all the registers to a sane state at resume, before implementing IR wakeup on them. In the case of mceusb, as there is already an userspace code for it on lirc, it would probably not be that hard to make this feature to work with ir-core. [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software decoder, the IR IRQ might be used to wake, but this means that everything, even a glitch, would wake the hardware, so this won't work neither. -- Cheers, Mauro -- 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?
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote: > On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab > wrote: > > [1] Basically, a keycode (like KEY_POWER) could be used to wake up the > > machine. So, by > > associating some scancode to KEY_POWER via ir-core, the driver can program > > the hardware > > to wake up the machine with the corresponding scancode. I can't see a need > > for a change at > > ir-core to implement such behavior. Of course, some attributes at sysfs can > > be added > > to enable or disable this feature, and to control the associated logic, but > > we first > > need to implement the wakeup feature at the hardware driver, and then > > adding some logic > > at ir-core to add the non-hardware specific code there. > > Really? Have you actually seen any hardware where a particular scan > code can be used to wake up the hardware? The only hardware I have > seen has the ability to unsuspend on arrival of IR traffic, but you > didn't have the granularity to dictate that it only wake up on > particular scancodes. The CX23888 and CX23102 can do it. Basically any IR pulse pattern your heart desires; within reason. And any carrier freq you want too; within reason. But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere near properly supporing suspend/resume for their main video and DMA functions, AFAIK. Regards, Andy -- 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?
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab wrote: > [1] Basically, a keycode (like KEY_POWER) could be used to wake up the > machine. So, by > associating some scancode to KEY_POWER via ir-core, the driver can program > the hardware > to wake up the machine with the corresponding scancode. I can't see a need > for a change at > ir-core to implement such behavior. Of course, some attributes at sysfs can > be added > to enable or disable this feature, and to control the associated logic, but > we first > need to implement the wakeup feature at the hardware driver, and then adding > some logic > at ir-core to add the non-hardware specific code there. Really? Have you actually seen any hardware where a particular scan code can be used to wake up the hardware? The only hardware I have seen has the ability to unsuspend on arrival of IR traffic, but you didn't have the granularity to dictate that it only wake up on particular scancodes. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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?
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote: > If you're waiting for me to get that working, I'll advise you to plan on > getting off the couch and pushing the power switch for some time to > come. ;) :-) On Friday 09 April 2010 14:01:46 Mauro Carvalho Chehab wrote: > The additions at IR core, if needed [1], shouldn't be hard, but the main > changes should happen at the hardware driver level. There's no current > plans for it, at least from my side, but, let's see if some hardware > driver developers want to implement it on the corresponding driver. > > [1] Basically, a keycode (like KEY_POWER) could be used to wake up the > machine. So, by associating some scancode to KEY_POWER via ir-core, the > driver can program the hardware to wake up the machine with the > corresponding scancode. I can't see a need for a change at ir-core to > implement such behavior. Of course, some attributes at sysfs can be added > to enable or disable this feature, and to control the associated logic, > but we first need to implement the wakeup feature at the hardware driver, > and then adding some logic at ir-core to add the non-hardware specific > code there. Thanks for the info Mauro. Cheers James signature.asc Description: This is a digitally signed message part.
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi James, Andy Walls wrote: > On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: >> Hi, >> >> On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: >>> Comments? >> I haven't seen this mentioned yet, but are there any plans for a sysfs >> interface to set up waking from suspend/standby on a particular IR scancode >> (for hardware decoders that support masking of comparing of the IR data), >> kind >> of analagous to the rtc framework's wakealarm sysfs file? > > This requires support at the hardware level. (You can't have CPU code > running to decode IR pulses when your CPU is "asleep".) The additions at IR core, if needed [1], shouldn't be hard, but the main changes should happen at the hardware driver level. There's no current plans for it, at least from my side, but, let's see if some hardware driver developers want to implement it on the corresponding driver. [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by associating some scancode to KEY_POWER via ir-core, the driver can program the hardware to wake up the machine with the corresponding scancode. I can't see a need for a change at ir-core to implement such behavior. Of course, some attributes at sysfs can be added to enable or disable this feature, and to control the associated logic, but we first need to implement the wakeup feature at the hardware driver, and then adding some logic at ir-core to add the non-hardware specific code there. -- Cheers, Mauro -- 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?
On Fri, Apr 9, 2010 at 8:58 AM, Jarod Wilson wrote: > On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote: >> On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: >> > Hi, >> > >> > On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: >> > > Comments? >> > >> > I haven't seen this mentioned yet, but are there any plans for a sysfs >> > interface to set up waking from suspend/standby on a particular IR scancode >> > (for hardware decoders that support masking of comparing of the IR data), >> > kind >> > of analagous to the rtc framework's wakealarm sysfs file? >> >> This requires support at the hardware level. (You can't have CPU code >> running to decode IR pulses when your CPU is "asleep".) >> >> I know of two video chips supported under linux that provide such a >> function. >> >> Wake-up from IR for these chips will rely on the kernel PCIe or USB >> infrastructure supporting PCIe or USB Power Managment Events from >> hardware. It will take a huge amount of work and time to get the >> respective linux video drivers to properly support suspend/resume >> properly. >> >> If you're waiting for me to get that working, I'll advise you to plan on >> getting off the couch and pushing the power switch for some time to >> come. ;) >> >> >> >> >> The MCE-USB, I *speculate*, can perform wakes. It's driver would need >> to support that, if it can. > > Yep, it can perform wakes, and the current lirc_mceusb does support it, > though it requires some screwing around with echoing something into > somewhere in sysfs (for the usb controller its attached to) to enable it, You probably need to tell the USB system to leave the MSMCE's power turned on during suspend. Maybe the MSMCE driver can tell the USB subsystem to leave it powered across suspend when the driver loads. > from what I recall... Making it Just Work would be a good idea. > > -- > Jarod Wilson > ja...@redhat.com > > -- Jon Smirl jonsm...@gmail.com -- 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?
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote: > On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: > > Hi, > > > > On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: > > > Comments? > > > > I haven't seen this mentioned yet, but are there any plans for a sysfs > > interface to set up waking from suspend/standby on a particular IR scancode > > (for hardware decoders that support masking of comparing of the IR data), > > kind > > of analagous to the rtc framework's wakealarm sysfs file? > > This requires support at the hardware level. (You can't have CPU code > running to decode IR pulses when your CPU is "asleep".) > > I know of two video chips supported under linux that provide such a > function. > > Wake-up from IR for these chips will rely on the kernel PCIe or USB > infrastructure supporting PCIe or USB Power Managment Events from > hardware. It will take a huge amount of work and time to get the > respective linux video drivers to properly support suspend/resume > properly. > > If you're waiting for me to get that working, I'll advise you to plan on > getting off the couch and pushing the power switch for some time to > come. ;) > > > > > The MCE-USB, I *speculate*, can perform wakes. It's driver would need > to support that, if it can. Yep, it can perform wakes, and the current lirc_mceusb does support it, though it requires some screwing around with echoing something into somewhere in sysfs (for the usb controller its attached to) to enable it, from what I recall... Making it Just Work would be a good idea. -- Jarod Wilson ja...@redhat.com -- 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?
On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote: > Hi, > > On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: > > Comments? > > I haven't seen this mentioned yet, but are there any plans for a sysfs > interface to set up waking from suspend/standby on a particular IR scancode > (for hardware decoders that support masking of comparing of the IR data), > kind > of analagous to the rtc framework's wakealarm sysfs file? This requires support at the hardware level. (You can't have CPU code running to decode IR pulses when your CPU is "asleep".) I know of two video chips supported under linux that provide such a function. Wake-up from IR for these chips will rely on the kernel PCIe or USB infrastructure supporting PCIe or USB Power Managment Events from hardware. It will take a huge amount of work and time to get the respective linux video drivers to properly support suspend/resume properly. If you're waiting for me to get that working, I'll advise you to plan on getting off the couch and pushing the power switch for some time to come. ;) The MCE-USB, I *speculate*, can perform wakes. It's driver would need to support that, if it can. Regards, Andy -- 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?
Hi, On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote: > Comments? I haven't seen this mentioned yet, but are there any plans for a sysfs interface to set up waking from suspend/standby on a particular IR scancode (for hardware decoders that support masking of comparing of the IR data), kind of analagous to the rtc framework's wakealarm sysfs file? Cheers James signature.asc Description: This is a digitally signed message part.
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
David Härdeman wrote: > On Sun, Mar 28, 2010 at 09:51:17PM -0300, Mauro Carvalho Chehab wrote: >> I spoke too soon... removing the index causes a problem at the read ioctl: >> there's no way >> to retrieve just the non-sparsed values. >> >> There's one solution that would allow both read/write and compat to work >> nicely, >> but the API would become somewhat asymmetrical: >> >> At get (EVIOCGKEYCODEBIG): >> use index/len as input and keycode/scancode as output; >> >> At set (EVIOCSKEYCODEBIG): >> use scancode/keycode/len as input (and, optionally, index as output). >> > > This was exactly the approach I had in mind when I suggested using > indexes. Doesn't work perfectly. The asymmetry has a side effect on the internal logic: EVIOCGKEYCODEBIG should be implemented with a pseudo-code like: kt_entry = getkeycodebig_from_index(index); EVIOCSKEYCODEBIG should be implemented with a pseudo-code like: kt_entry = getkeycodebig_from_scan(scan, len); old_key = kt_entry->keycode; kt_entry->keycode = newkey; if (setkeycodebig(kt_entry) == 0) keyup(old_key); As you see, the input parameters for the getkeycodebig*() are different. So, this approach requires 3 ops instead of 2. Yet, as scancode->keycode is needed anyway, this doesn't actually hurts. I just added the patches that implement those two ioctls on my IR development tree. I tested only the original EVIOCGKEYCODE/EVIOSGKEYCODE and calling a clear_table function using EVIOCSKEYCODEBIG via emulation. My next step is to test the remaining ir-keytable functions via emulation, and then implement the *BIG ioctls at ir-core, for testing. I haven't test yet the *keycode*default methods. After having it fully tested, I'll submit the complete input ioctl patch via ML. -- Cheers, Mauro -- 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?
David Härdeman wrote: > On Sun, Mar 28, 2010 at 08:22:31PM -0300, Mauro Carvalho Chehab wrote: >> I also noticed another problem: kernel should have some way to report >> the expected >> size of the scancode to userspace, especially if we want to have the >> compatibility >> code (since, with compat, a scancode maximum size need to be 32 bits, >> otherwise >> the code won't work). >> >> I'll likely adding another control that returns the size of the scancode. > > And perhaps the interface should explicitly define that for the case > where userspace sends an undersized scancode, the real scancode will be > generated by zero-extending the undersized scancode into its expected > size. > > That way the interface will be binary-forwards-compatible even if > scancode sizes are increased at some later date. Makes sense. Padding an undersized scancode is endian-dependent. So, we'll likely need to add some padding functions. The better seems to add the logic at include/linux/byteorder/generic.h. -- Cheers, Mauro -- 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?
On Sun, Mar 28, 2010 at 08:22:31PM -0300, Mauro Carvalho Chehab wrote: > I also noticed another problem: kernel should have some way to report > the expected > size of the scancode to userspace, especially if we want to have the > compatibility > code (since, with compat, a scancode maximum size need to be 32 bits, > otherwise > the code won't work). > > I'll likely adding another control that returns the size of the scancode. And perhaps the interface should explicitly define that for the case where userspace sends an undersized scancode, the real scancode will be generated by zero-extending the undersized scancode into its expected size. That way the interface will be binary-forwards-compatible even if scancode sizes are increased at some later date. -- David Härdeman -- 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?
On Sun, Mar 28, 2010 at 09:51:17PM -0300, Mauro Carvalho Chehab wrote: > > I spoke too soon... removing the index causes a problem at the read ioctl: > there's no way > to retrieve just the non-sparsed values. > > There's one solution that would allow both read/write and compat to work > nicely, > but the API would become somewhat asymmetrical: > > At get (EVIOCGKEYCODEBIG): > use index/len as input and keycode/scancode as output; > > At set (EVIOCSKEYCODEBIG): > use scancode/keycode/len as input (and, optionally, index as output). > This was exactly the approach I had in mind when I suggested using indexes. > Having it asymmetrical doesn't sound good, but, on the other hand, > using index for > the set function also doesn't seem good, as the driver may reorder the > entries after > setting, for example to work with a binary tree or with hashes. I don't think the assymetry is really a problem. As I see it, there are basically two user cases: 1) Userspace wants scancode X to generate keypress Y (In which case userspace doesn't care one iota what the index is) 2) Userspace wants to get the current keytable from the kernel (In which case a loop with an index from 0 to n is appropriate) and, possibly: 3) Userspace wants to know what keycode (if any) scancode X generates (In which case approach 2 will work just as well, but this usecase seems a bit contrived anyway...) -- David Härdeman -- 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?
Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
>> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
>>> David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
>>10) extend keycode table replacement to support big/variable
>>sized scancodes;
> Pending.
>
> The current limit here is the scancode ioctl's are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2])
> /* get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2])
> /* set keycode */
>
> As int size is 32 bits, and we must pass both 64 (or even bigger)
> scancodes, associated
> with a keycode, there's not enough bits there for IR.
>
> The better approach seems to create an struct with an arbitrary long
> size, like:
>
> struct keycode_table_entry {
> unsigned keycode;
> char scancode[32]; /* 32 is just an arbitrary long array - maybe
> shorter */
> int len;
> }
>
> and re-define the ioctls. For example we might be doing:
>
> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
> keycode_table_entry)
> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
> keycode_table_entry)
> #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
>
> Provided that the size for struct keycode_table_entry is different, _IO
> will generate
> a different magic number for those.
>
> Or, instead of using 0x04, just use another sequential number at the 'E'
> namespace.
>
> An specific function to clear the table is needed with big scancode space,
> as already discussed.
>
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
>>> Makes sense.
>> Yes, I think so too. Just need a nice way to handle transition, I'd
>> like in the end to have drivers implement only the improved methods and
>> map legacy methods in evdev.
>
> See the attached RFC barely tested patch.
>
> On this patch, I'm using the following definitions for the ioctl:
>
> struct keycode_table_entry {
> __u32 keycode; /* e.g. KEY_A */
> __u32 index;/* Index for the given scan/key table */
> __u32 len; /* Lenght of the scancode */
> __u32 reserved[2]; /* Reserved for future usage */
> char *scancode; /* scancode, in machine-endian */
> };
>
> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry) /*
> get keycode */
> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry) /*
> set keycode */
>
>
> I tried to do the compat backport on a nice way, on both directions, e. g.:
>
> 1) an userspace app using EVIO[CS]GKEYCODEBIG to work with a legacy driver.
> 2) a driver implementing the new methods to accept the legacy
> EVIO[CS]GKEYCODE;
>
> For the test of (1), I implemented the following clear keytable code:
>
> struct keycode_table_entry kt;
> uint32_tscancode, i;
>
> memset(&kt, 0, sizeof(kt));
> kt.len = sizeof(scancode);
> kt.scancode = (char *)&scancode;
>
> for (i = 0; rc == 0; i++) {
> kt.index = i;
> kt.keycode = KEY_RESERVED;
> rc = ioctl(fd, EVIOCSKEYCODEBIG, &kt);
> }
> fprintf(stderr, "Cleaned %i keycode(s)\n", i - 1);
>
> It worked properly. I didn't test (2) yet.
>
> The read keytable would also be trivial. However, there are some troubles when
> implementing the code to add/replace a value at the table, in a way that it
> would allow the legacy drivers to work:
>
> - With a real CODEBIG support, the index number will be different than the
> scancode number. So, let's say that this is the driver table:
>
> index scancode keycode
>
> 0 0x1e00 KEY_0
> 1 0x1e01 KEY_1
> 2 0x1e02 KEY_2
> 3 0x1e03 KEY_3
> 4 0x1e04 KEY_4
> 5 0x1e05 KEY_5
> 6 0x1e06 KEY_6
> 7 0x1e07 KEY_7
> 8 0x1e08 KEY_8
> 9 0x1e09 KEY_9
>
> Let's suppose that the user wants to overwrite the entry 5, attributing a new
> scancode/keycode
> to entry 5 (for example, associating 0x1e0a with KEY-A).
>
> A valid EVIOCSKEYCODEBIG call to change this code would be:
>
> kt->index = 5;
> *(uint32_t *)kt->scancode = 0x1e0a;
> *(uin
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Dmitry Torokhov wrote:
> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
>> David Härdeman wrote:
>>> On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
>10) extend keycode table replacement to support big/variable
>sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
set keycode */
As int size is 32 bits, and we must pass both 64 (or even bigger)
scancodes, associated
with a keycode, there's not enough bits there for IR.
The better approach seems to create an struct with an arbitrary long size,
like:
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
and re-define the ioctls. For example we might be doing:
#define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
keycode_table_entry)
#define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
keycode_table_entry)
#define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
Provided that the size for struct keycode_table_entry is different, _IO
will generate
a different magic number for those.
Or, instead of using 0x04, just use another sequential number at the 'E'
namespace.
An specific function to clear the table is needed with big scancode space,
as already discussed.
>>> I'd suggest:
>>>
>>> struct keycode_table_entry {
>>> unsigned keycode;
>>> unsigned index;
>>> unsigned len;
>>> char scancode[];
>>> };
>>>
>>> Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
>>> ignored), that way no special function to clear the table is necessary,
>>> instead you do a loop with:
>>>
>>> EVIOCGKEYCODEBIG (with index 0)
>>> EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
>>> keycode = KEY_RESERVED)
>>>
>>> until EVIOCGKEYCODEBIG returns an error.
>> Makes sense.
>
> Yes, I think so too. Just need a nice way to handle transition, I'd
> like in the end to have drivers implement only the improved methods and
> map legacy methods in evdev.
See the attached RFC barely tested patch.
On this patch, I'm using the following definitions for the ioctl:
struct keycode_table_entry {
__u32 keycode; /* e.g. KEY_A */
__u32 index;/* Index for the given scan/key table */
__u32 len; /* Lenght of the scancode */
__u32 reserved[2]; /* Reserved for future usage */
char *scancode; /* scancode, in machine-endian */
};
#define EVIOCGKEYCODEBIG_IOR('E', 0x04, struct keycode_table_entry) /*
get keycode */
#define EVIOCSKEYCODEBIG_IOW('E', 0x04, struct keycode_table_entry) /*
set keycode */
I tried to do the compat backport on a nice way, on both directions, e. g.:
1) an userspace app using EVIO[CS]GKEYCODEBIG to work with a legacy driver.
2) a driver implementing the new methods to accept the legacy EVIO[CS]GKEYCODE;
For the test of (1), I implemented the following clear keytable code:
struct keycode_table_entry kt;
uint32_tscancode, i;
memset(&kt, 0, sizeof(kt));
kt.len = sizeof(scancode);
kt.scancode = (char *)&scancode;
for (i = 0; rc == 0; i++) {
kt.index = i;
kt.keycode = KEY_RESERVED;
rc = ioctl(fd, EVIOCSKEYCODEBIG, &kt);
}
fprintf(stderr, "Cleaned %i keycode(s)\n", i - 1);
It worked properly. I didn't test (2) yet.
The read keytable would also be trivial. However, there are some troubles when
implementing the code to add/replace a value at the table, in a way that it
would allow the legacy drivers to work:
- With a real CODEBIG support, the index number will be different than the
scancode number. So, let's say that this is the driver table:
index scancode keycode
0 0x1e00 KEY_0
1 0x1e01 KEY_1
2 0x1e02 KEY_2
3 0x1e03 KEY_3
4 0x1e04 KEY_4
5 0x1e05 KEY_5
6 0x1e06 KEY_6
7 0x1e07 KEY_7
8 0x1e08 KEY_8
9 0x1e09 KEY_9
Let's suppose that the user wants to overwrite the entry 5, attributing a new
scancode/keycode
to entry 5 (for example, associating 0x1e0a with KEY-A).
A valid EVIOCSKEYCODEBIG call to change this code would be:
kt->index = 5;
*(uint32_t *)kt->scancode = 0x1e0a;
*(uint32_t *)kt->keycode = KEY_A;
rc = ioctl(fd, EVIOCSKEYCODEBIG, &kt);
With EVIOCSKEYCODE, this requires two separate operations:
int codes[2];
code[0] = 0x1e05;
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 06:37:41PM -0400, Jon Smirl wrote: > On Fri, Mar 26, 2010 at 1:22 PM, Mauro Carvalho Chehab > wrote: > > 2) create a read/write sysfs node that would indicate the number of > > event/keymaps > > associated with a given IR. By writing a bigger number, it would create new > > devices. > > By writing a smaller number, it will delete some maps. There's an issue > > though: > > what criteria would be used to delete? The newly created ones? > > This is normally handled a sysfs node on the core, something like > 'adddev'. You echo '1' to this node and a new interface is created. > > Each interface has a sysfs node, make a 'remove' attribute in it. Echo > '1' to remove to make it disappear. > > You have to implement the code behind these interfaces but this > convention is used in other subsubsystems. > > BTW - you're recreating everything the configfs interface did. it > achieved the same results with mkdir/rmdir. I liked the configfs > scheme since there are no obscure commands to learn. Everybody can > make files and directories. I've looked at your configfs interface, it was the inspiration for suggesting that each irrcv device should have more than one keymap with one input device for each keytable. However, I don't agree that the configfs interface would somehow be more user-friendly than an ioctl based one. Getting the correct "scancode" (e.g, protocol, device, function values), finding a corresponding keycode (is it KEY_0, no wait, it's KEY_NUMERIC_0), etc are bigger hurdles than mkdir/rmdir/echo or calling a tool similar to input-utils which does the ioctl. mount -t configfs blabla /somewhere (distros don't seem to mount configfs per default) cd /somewhere/somewhere-else mkdir something echo gibberish1 > yada1 echo gibberish2 > yada2 echo gibberish3 > yada3 Doesn't seem all that much less obscure than the command line interface to an ioctl based interface: ir-util load_keytable /usr/share/remotes/blah or ir-util load_keyentry "gibberish1,gibberish2 = gibberish3" Assume the user provides an invalid (e.g. out-of-bounds value for the device field of a RC5 ir command) scancode. With the configfs approach the user will get a standard perror reply from echo/cat. With a dedicated tool the user can get a much more informative error message. But in the end, the majority of users are going to use some GUI to do all of this anyway (and they'll only do it once)start GUI, ask user to press all keys on remote one by one, provide them with a list of possible descriptions (i.e. input.h type keycodes) for each detected key on the remote (something like the keymapping interface most quake-like computer games provide). Once done, save keymap. Load keymap at boot. Configfs or ioctl or sysfs or netlink or blorkfs is a detail which won't matter to those users. -- David Härdeman -- 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?
Hi! > > Anyway, one simple way to avoid > > resetting the hardware for every new parameter change would be to use a > > timer > > for reset. This way, an userspace application or script that is touching on > > several parameters would just send the complete RX init sequence and > > after some dozens of milliseconds, the hardware will load the new > > parameters. > > And I do not think that sounds like a good interface. Yep. Having artifical delay is ugly, racy and error prone. (If application is swapped out, you'll set the hardware to middle state, anyway). Better solution would be to have "COMMIT" command that actually does the setup, or interface that allows all parameters at once... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
On Fri, Mar 26, 2010 at 1:22 PM, Mauro Carvalho Chehab
wrote:
> Dmitry Torokhov wrote:
>> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
>>> David Härdeman wrote:
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
>> 10) extend keycode table replacement to support big/variable
>> sized scancodes;
> Pending.
>
> The current limit here is the scancode ioctl's are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2])
> /* get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2])
> /* set keycode */
>
> As int size is 32 bits, and we must pass both 64 (or even bigger)
> scancodes, associated
> with a keycode, there's not enough bits there for IR.
>
> The better approach seems to create an struct with an arbitrary long
> size, like:
>
> struct keycode_table_entry {
> unsigned keycode;
> char scancode[32]; /* 32 is just an arbitrary long array - maybe
> shorter */
> int len;
> }
>
> and re-define the ioctls. For example we might be doing:
>
> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
> keycode_table_entry)
> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
> keycode_table_entry)
> #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, void)
>
> Provided that the size for struct keycode_table_entry is different, _IO
> will generate
> a different magic number for those.
>
> Or, instead of using 0x04, just use another sequential number at the 'E'
> namespace.
>
> An specific function to clear the table is needed with big scancode space,
> as already discussed.
>
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
>>> Makes sense.
>>
>> Yes, I think so too. Just need a nice way to handle transition, I'd
>> like in the end to have drivers implement only the improved methods and
>> map legacy methods in evdev.
>
> Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
> also handle the legacy methods, and post for review.
>
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input device
created per keytable. That way you can have one input device per remote
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
evdev IOCTL since there's an N-1 mapping between input devices and irrcv
devices.
>>> I don't think that an ioctl over one /dev/input/event should be the proper
>>> way
>>> to ask kernel to create another filtered /dev/input/event. As it were
>>> commented
>>> that the multimedia keys on some keyboards could benefit on having a filter
>>> capability, maybe we may have a sysfs node at class input that would allow
>>> the creation/removal of the filtered event interface.
>>
>> No, if you want separate event devices just create a new instance of
>> input device for every keymap and have driver/irrcv class route events
>> to proper input device.
>
> This don't solve the issue about how to signalize to kernel that more than one
> input device is needed.
>
> As the userspace will request the creation of those keymaps, we need some way
> to receive such requests from userspace.
>
> I can see a few ways for doing it:
>
> 1) create a control device for the irrcv device as a hole,
> that would handle such requests via ioctl (/dev/irctl[0-9]* ?)
>
> 2) create a read/write sysfs node that would indicate the number of
> event/keymaps
> associated with a given IR. By writing a bigger number, it would create new
> devices.
> By writing a smaller number, it will delete some maps. There's an issue
> though:
> what criteria would be used to delete? The newly created ones?
This is normally handled a sysfs node on the core, something like
'adddev'. You echo '1' to this node and a new interface is created.
Each interface has a sysfs node, make a 'remove' attribute in it. Echo
'1' to remove to make it disappear.
You have to implement the code behind these interfaces but this
convention is used in other subsubsystems.
BTW - you're recreating everything the configfs interface did. it
achieved the same results with mkdir/rmdir. I liked the configfs
scheme since there are no obscure commands to learn. Everybody can
make files and directories.
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 12:17:34PM -0300, Mauro Carvalho Chehab wrote: > David Härdeman wrote: > > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: > >>>2) add current_protocol support on other drivers; > >> Done. Patch were already merged upstream. > >> > >> The current_protocol attribute shows the protocol(s) that the device is > >> accepting > >> and allows changing it to another protocol. > >> > >> In the case of the em28xx hardware, only one protocol can be active, since > >> the decoder > >> is inside the hardware. > >> > >> On the raw IR decode implementation I've done at the saa7134, all raw > >> pulse events are > >> sent to all registered decoders, so I'm thinking on using this sysfs node > >> to allow > >> disabling the standard behavior of passing the IR codes to all decoders, > >> routing it > >> to just one decoder. > >> > >> Another alternative would be to show current_protocol only for devices > >> with hardware > >> decoder, and create one sysfs node for each decoder, allowing > >> enabling/disabling each > >> decoder individually. > > > > You're eventually going to want to add ioctl's to set a lot of TX or RX > > parameters in one go (stuff like active receiver(s) and transmitter(s), > > carrier frequency, duty cycle, timeouts, filter levels and resolution - > > all of which would need to be set in one operation since some hardware > > will need to be reset after each parameter is changed). > > TX is a completely different history. It has nothing to do with input event > subsystem. So, another approach should be taken for it. I suggest (though I might not have been clear on that point) that irrcv devices create a char node...ir specifics are handled via that node (with read/write/ioctl...see the other mail I just send). > I haven't seen yet a hardware decoder with such parameters, but maybe I just > don't have enough specs here to adjust them. The entire idea is to have a common API for hardware decoders and decoders which provide raw pulse/space timings. That, to me, is one of the major points of having in-kernel IR decoders - being able to provide a consistent interface for both hardware decoders and pulse/space hardware. > Anyway, one simple way to avoid > resetting the hardware for every new parameter change would be to use a timer > for reset. This way, an userspace application or script that is touching on > several parameters would just send the complete RX init sequence and > after some dozens of milliseconds, the hardware will load the new parameters. And I do not think that sounds like a good interface. > > Then you'll end up with a few things being controlled via sysfs and some > > being controlled via ioctls. Maybe it's a good idea to have a bitmask of > > supported and enabled protocols in those ioctls instead? > > There's an interesting discussion about bitmasks x a list of enumerated values > as a way to represent a bitmask into a series of values on sysfs, > at http://lwn.net/Articles/378219/ (see "A critical look at sysfs attribute > values" > article there). Not really relevant...that's just the minor detail of how a sysfs file might be represented. > That's said, I'm starting to think that the better is to have some > differentiation > there between hardware and software decoders. IMO, software decoders are > better > handled with an "enabled" attribute, per software decoder, inside each irrcv. I think we can create an interface which obscures the differences: Software decoders will export all in-kernel IR decoders in a bitmask in the "supported_protocols" sysfs file or ioctl struct member. Hardware decoders will export the hardware supported protocol(s) in the same file/member. In addition, a sysfs file or ioctl member for "enabled_protocols" will control either the enabled in-kernel IR decoders or hardware decoder(s). As should be quite obvious by now...I suggest ioctls (on a irrcv specific chardev) for controlling this :) -- David Härdeman -- 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?
On Fri, Mar 26, 2010 at 02:22:51PM -0300, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
> >> David Härdeman wrote:
> >>> I'd suggest:
> >>>
> >>> struct keycode_table_entry {
> >>> unsigned keycode;
> >>> unsigned index;
> >>> unsigned len;
> >>> char scancode[];
> >>> };
> >>>
> >>> Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
> >>> ignored), that way no special function to clear the table is necessary,
> >>> instead you do a loop with:
> >>>
> >>> EVIOCGKEYCODEBIG (with index 0)
> >>> EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
> >>> keycode = KEY_RESERVED)
> >>>
> >>> until EVIOCGKEYCODEBIG returns an error.
> >> Makes sense.
> >
> > Yes, I think so too. Just need a nice way to handle transition, I'd
> > like in the end to have drivers implement only the improved methods and
> > map legacy methods in evdev.
>
> Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
> also handle the legacy methods, and post for review.
If EVIOCGKEYCODEBIG is going to be used as a superset of the old ioctl,
might it be a good idea change the proposed struct to:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned type;
unsigned len;
char scancode[];
};
Where "type" is used to give a hint of how the scancode[] member should
be interpreted?
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input
device created per keytable. That way you can have one input device
per remote control. This implies that EVIOCLEARKEYCODEBIG is a bit
misplaced as an evdev IOCTL since there's an N-1 mapping between
input devices and irrcv devices.
>>> I don't think that an ioctl over one /dev/input/event should be the
>>> proper way
>>> to ask kernel to create another filtered /dev/input/event. As it
>>> were commented
>>> that the multimedia keys on some keyboards could benefit on having a
>>> filter
>>> capability, maybe we may have a sysfs node at class input that would
>>> allow
>>> the creation/removal of the filtered event interface.
>>
>> No, if you want separate event devices just create a new instance
>> of
>> input device for every keymap and have driver/irrcv class route
>> events
>> to proper input device.
I fully agree!
> This don't solve the issue about how to signalize to kernel that more than one
> input device is needed.
>
> As the userspace will request the creation of those keymaps, we need some way
> to receive such requests from userspace.
>
> I can see a few ways for doing it:
>
> 1) create a control device for the irrcv device as a hole,
> that would handle such requests via ioctl (/dev/irctl[0-9]* ?)
>
> 2) create a read/write sysfs node that would indicate the number of
> event/keymaps
> associated with a given IR. By writing a bigger number, it would create new
> devices.
> By writing a smaller number, it will delete some maps. There's an issue
> though:
> what criteria would be used to delete? The newly created ones?
This won't work for the reason you've already set out...which keymap
should be deleted?
> 3) create a fixed number of event devices, and add a sysfs attribute to enable
> or disable it;
You really seem to prefer sysfs over ioctls :)
> 4) create a fixed number of sysfs attributes to represent the keymaps. For
> example:
> /sys/class/irrcv/irrcv0/keymap0/enabled
> ...
> /sys/class/irrcv/irrcv0/keymap7/enabled
>
> The input/event node will be created only when the enabled=1.
This sounds like 3)
> I don't like (2) or (3), because removing a table with (2) may end by
> removing the wrong
> table, and (3) will create more event interfaces than probably needed by the
> majority
> of IR users.
>
> maybe (4) is the better one.
Personally I think 1) is the best approach. Having a device for the
irrcv device allows for three kinds of operations:
read
which corresponds to RX...you're eventually going to want to let
userspace devices read IR commands which have no entries in a keytable
yet in order to create keytables for new remotes, the same interface can
also be used for lirc-type user-space apps which want to access the raw
pulse/space timings for userspace decoding.
write
-
which would correspond to TX...I'd suggest a stream of s32 integers to
imply pulse/space timings.
ioctl
-
for controlling the RX/TX parameters, creating/destroying additional
keytables, etc...
Basically, we'll end up with a lirc_dev 2.0. And the "irrcv" class name
will be misleading since it will be irrcv + irsnd :)
--
David Härdeman
--
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?
Dmitry Torokhov wrote:
> On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
>> David Härdeman wrote:
>>> On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
>10) extend keycode table replacement to support big/variable
>sized scancodes;
Pending.
The current limit here is the scancode ioctl's are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
get keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
set keycode */
As int size is 32 bits, and we must pass both 64 (or even bigger)
scancodes, associated
with a keycode, there's not enough bits there for IR.
The better approach seems to create an struct with an arbitrary long size,
like:
struct keycode_table_entry {
unsigned keycode;
char scancode[32]; /* 32 is just an arbitrary long array - maybe
shorter */
int len;
}
and re-define the ioctls. For example we might be doing:
#define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
keycode_table_entry)
#define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
keycode_table_entry)
#define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
Provided that the size for struct keycode_table_entry is different, _IO
will generate
a different magic number for those.
Or, instead of using 0x04, just use another sequential number at the 'E'
namespace.
An specific function to clear the table is needed with big scancode space,
as already discussed.
>>> I'd suggest:
>>>
>>> struct keycode_table_entry {
>>> unsigned keycode;
>>> unsigned index;
>>> unsigned len;
>>> char scancode[];
>>> };
>>>
>>> Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
>>> ignored), that way no special function to clear the table is necessary,
>>> instead you do a loop with:
>>>
>>> EVIOCGKEYCODEBIG (with index 0)
>>> EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
>>> keycode = KEY_RESERVED)
>>>
>>> until EVIOCGKEYCODEBIG returns an error.
>> Makes sense.
>
> Yes, I think so too. Just need a nice way to handle transition, I'd
> like in the end to have drivers implement only the improved methods and
> map legacy methods in evdev.
Ok. I'll prepare the patches for adding the new ioctl, in a way that it will
also handle the legacy methods, and post for review.
>>> On a related note, I really think the interface would benefit from
>>> allowing more than one keytable per irrcv device with an input device
>>> created per keytable. That way you can have one input device per remote
>>> control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
>>> evdev IOCTL since there's an N-1 mapping between input devices and irrcv
>>> devices.
>> I don't think that an ioctl over one /dev/input/event should be the proper
>> way
>> to ask kernel to create another filtered /dev/input/event. As it were
>> commented
>> that the multimedia keys on some keyboards could benefit on having a filter
>> capability, maybe we may have a sysfs node at class input that would allow
>> the creation/removal of the filtered event interface.
>
> No, if you want separate event devices just create a new instance of
> input device for every keymap and have driver/irrcv class route events
> to proper input device.
This don't solve the issue about how to signalize to kernel that more than one
input device is needed.
As the userspace will request the creation of those keymaps, we need some way
to receive such requests from userspace.
I can see a few ways for doing it:
1) create a control device for the irrcv device as a hole,
that would handle such requests via ioctl (/dev/irctl[0-9]* ?)
2) create a read/write sysfs node that would indicate the number of
event/keymaps
associated with a given IR. By writing a bigger number, it would create new
devices.
By writing a smaller number, it will delete some maps. There's an issue though:
what criteria would be used to delete? The newly created ones?
3) create a fixed number of event devices, and add a sysfs attribute to enable
or disable it;
4) create a fixed number of sysfs attributes to represent the keymaps. For
example:
/sys/class/irrcv/irrcv0/keymap0/enabled
...
/sys/class/irrcv/irrcv0/keymap7/enabled
The input/event node will be created only when the enabled=1.
I don't like (2) or (3), because removing a table with (2) may end by removing
the wrong
table, and (3) will create more event interfaces than probably needed by the
majority
of IR users.
maybe (4) is the better one.
--
Cheers,
Mauro
--
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/majo
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Fri, Mar 26, 2010 at 11:40:41AM -0300, Mauro Carvalho Chehab wrote:
> David Härdeman wrote:
> > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
> >>>10) extend keycode table replacement to support big/variable
> >>>sized scancodes;
> >> Pending.
> >>
> >> The current limit here is the scancode ioctl's are defined as:
> >>
> >> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
> >> get keycode */
> >> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
> >> set keycode */
> >>
> >> As int size is 32 bits, and we must pass both 64 (or even bigger)
> >> scancodes, associated
> >> with a keycode, there's not enough bits there for IR.
> >>
> >> The better approach seems to create an struct with an arbitrary long size,
> >> like:
> >>
> >> struct keycode_table_entry {
> >>unsigned keycode;
> >>char scancode[32]; /* 32 is just an arbitrary long array - maybe
> >> shorter */
> >>int len;
> >> }
> >>
> >> and re-define the ioctls. For example we might be doing:
> >>
> >> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
> >> keycode_table_entry)
> >> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
> >> keycode_table_entry)
> >> #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
> >>
> >> Provided that the size for struct keycode_table_entry is different, _IO
> >> will generate
> >> a different magic number for those.
> >>
> >> Or, instead of using 0x04, just use another sequential number at the 'E'
> >> namespace.
> >>
> >> An specific function to clear the table is needed with big scancode space,
> >> as already discussed.
> >>
> >
> > I'd suggest:
> >
> > struct keycode_table_entry {
> > unsigned keycode;
> > unsigned index;
> > unsigned len;
> > char scancode[];
> > };
> >
> > Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
> > ignored), that way no special function to clear the table is necessary,
> > instead you do a loop with:
> >
> > EVIOCGKEYCODEBIG (with index 0)
> > EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
> > keycode = KEY_RESERVED)
> >
> > until EVIOCGKEYCODEBIG returns an error.
>
> Makes sense.
Yes, I think so too. Just need a nice way to handle transition, I'd
like in the end to have drivers implement only the improved methods and
map legacy methods in evdev.
>
> > This also allows you to get all the current mappings from the kernel
> > without having to blindly search through an arbitrarily large keyspace.
> >
> > Also, EVIOCLEARKEYCODEBIG should be:
> >
> > #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
> >
> > That way a user space application can simply call EVIOCLEARKEYCODEBIG,
> > ask the user for an appropriate keycode, fill in the keycode member of
> > the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
>
> By using the index concept, I don't think we need another ioctl. Also,
> there's no way for kernel to handle it, as it will be using the same
> magic number of EVIOCGKEYCODEBIG.
>
> > On a related note, I really think the interface would benefit from
> > allowing more than one keytable per irrcv device with an input device
> > created per keytable. That way you can have one input device per remote
> > control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
> > evdev IOCTL since there's an N-1 mapping between input devices and irrcv
> > devices.
>
> I don't think that an ioctl over one /dev/input/event should be the proper way
> to ask kernel to create another filtered /dev/input/event. As it were
> commented
> that the multimedia keys on some keyboards could benefit on having a filter
> capability, maybe we may have a sysfs node at class input that would allow
> the creation/removal of the filtered event interface.
No, if you want separate event devices just create a new instance of
input device for every keymap and have driver/irrcv class route events
to proper input device.
Thanks.
--
Dmitry
--
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?
David Härdeman wrote: > On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: >>>2) add current_protocol support on other drivers; >> Done. Patch were already merged upstream. >> >> The current_protocol attribute shows the protocol(s) that the device is >> accepting >> and allows changing it to another protocol. >> >> In the case of the em28xx hardware, only one protocol can be active, since >> the decoder >> is inside the hardware. >> >> On the raw IR decode implementation I've done at the saa7134, all raw pulse >> events are >> sent to all registered decoders, so I'm thinking on using this sysfs node to >> allow >> disabling the standard behavior of passing the IR codes to all decoders, >> routing it >> to just one decoder. >> >> Another alternative would be to show current_protocol only for devices with >> hardware >> decoder, and create one sysfs node for each decoder, allowing >> enabling/disabling each >> decoder individually. > > You're eventually going to want to add ioctl's to set a lot of TX or RX > parameters in one go (stuff like active receiver(s) and transmitter(s), > carrier frequency, duty cycle, timeouts, filter levels and resolution - > all of which would need to be set in one operation since some hardware > will need to be reset after each parameter is changed). TX is a completely different history. It has nothing to do with input event subsystem. So, another approach should be taken for it. I haven't seen yet a hardware decoder with such parameters, but maybe I just don't have enough specs here to adjust them. Anyway, one simple way to avoid resetting the hardware for every new parameter change would be to use a timer for reset. This way, an userspace application or script that is touching on several parameters would just send the complete RX init sequence and after some dozens of milliseconds, the hardware will load the new parameters. > Then you'll end up with a few things being controlled via sysfs and some > being controlled via ioctls. Maybe it's a good idea to have a bitmask of > supported and enabled protocols in those ioctls instead? There's an interesting discussion about bitmasks x a list of enumerated values as a way to represent a bitmask into a series of values on sysfs, at http://lwn.net/Articles/378219/ (see "A critical look at sysfs attribute values" article there). That's said, I'm starting to think that the better is to have some differentiation there between hardware and software decoders. IMO, software decoders are better handled with an "enabled" attribute, per software decoder, inside each irrcv. In the case of hardware decoders, just one attribute is enough to control it. I think it should be a bitmask parameter, but presented with their aliases, like for example: $cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors ondemand conservative performance This is clearly a bitmask, but it is presented as textual values, instead of a magic number. So, we may have /sys/class/irrcv/irrcv0/supported_protocols as, for example: RC-5 NEC and allow setting current_protocol as just "RC-5" or, if the hardware supports more than one decoder at the same time, as "RC-5 NEC". -- Cheers, Mauro -- 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?
David Härdeman wrote:
> On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
>>>10) extend keycode table replacement to support big/variable
>>>sized scancodes;
>> Pending.
>>
>> The current limit here is the scancode ioctl's are defined as:
>>
>> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
>> get keycode */
>> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
>> set keycode */
>>
>> As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes,
>> associated
>> with a keycode, there's not enough bits there for IR.
>>
>> The better approach seems to create an struct with an arbitrary long size,
>> like:
>>
>> struct keycode_table_entry {
>> unsigned keycode;
>> char scancode[32]; /* 32 is just an arbitrary long array - maybe
>> shorter */
>> int len;
>> }
>>
>> and re-define the ioctls. For example we might be doing:
>>
>> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct
>> keycode_table_entry)
>> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct
>> keycode_table_entry)
>> #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
>>
>> Provided that the size for struct keycode_table_entry is different, _IO will
>> generate
>> a different magic number for those.
>>
>> Or, instead of using 0x04, just use another sequential number at the 'E'
>> namespace.
>>
>> An specific function to clear the table is needed with big scancode space,
>> as already discussed.
>>
>
> I'd suggest:
>
> struct keycode_table_entry {
> unsigned keycode;
> unsigned index;
> unsigned len;
> char scancode[];
> };
>
> Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
> ignored), that way no special function to clear the table is necessary,
> instead you do a loop with:
>
> EVIOCGKEYCODEBIG (with index 0)
> EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
> keycode = KEY_RESERVED)
>
> until EVIOCGKEYCODEBIG returns an error.
Makes sense.
> This also allows you to get all the current mappings from the kernel
> without having to blindly search through an arbitrarily large keyspace.
>
> Also, EVIOCLEARKEYCODEBIG should be:
>
> #define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
>
> That way a user space application can simply call EVIOCLEARKEYCODEBIG,
> ask the user for an appropriate keycode, fill in the keycode member of
> the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
By using the index concept, I don't think we need another ioctl. Also,
there's no way for kernel to handle it, as it will be using the same
magic number of EVIOCGKEYCODEBIG.
> On a related note, I really think the interface would benefit from
> allowing more than one keytable per irrcv device with an input device
> created per keytable. That way you can have one input device per remote
> control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
> evdev IOCTL since there's an N-1 mapping between input devices and irrcv
> devices.
I don't think that an ioctl over one /dev/input/event should be the proper way
to ask kernel to create another filtered /dev/input/event. As it were commented
that the multimedia keys on some keyboards could benefit on having a filter
capability, maybe we may have a sysfs node at class input that would allow
the creation/removal of the filtered event interface.
>
> ioctl's to set/get keycodes for ir should also take a flag parameter in
> the struct to allow special properties to be set/returned for a given
> keycode mapping (I'm thinking of keycodes which powers on the computer
> for instance, that should be exposed to userspace somehow).
>
> With all of that, the struct might need to be something like:
>
> struct keycode_table_entry {
> unsigned keycode; /* e.g. KEY_A */
> unsigned table; /* Table index, for multiple keytables */
> unsigned index; /* Index in the given keytable */
> unsigned flags; /* For additional functionality */
> unsigned len; /* Of the struct */
> char scancode[]; /* Per-protocol scancode data follows */
> };
>
I don't see the need for a table index. If we have 3 input event interfaces
for a given IR, each will have its own private keycode table.
> Finally, I think irrcv should create a chardev of its own with ioctl's
> like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's). The
> same chardev can be used for IR blasting (by writing data to it once TX
> parameters have been set).
There are several different things mixed above. It may be a good idea
to allow extending the ioctls from the input event device to other input
classes. Yet, I'm currently not seeing any usage for it.
In the specific case of EVIOCGKEYCODEBIG/EVIOCSKEYCODEBIG, those are needed
for all input devices whose scancode is bigger than 32 bits. It is not
specific to IR.
I don't t
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote:
> >10) extend keycode table replacement to support big/variable
> >sized scancodes;
>
> Pending.
>
> The current limit here is the scancode ioctl's are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
> get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
> set keycode */
>
> As int size is 32 bits, and we must pass both 64 (or even bigger) scancodes,
> associated
> with a keycode, there's not enough bits there for IR.
>
> The better approach seems to create an struct with an arbitrary long size,
> like:
>
> struct keycode_table_entry {
> unsigned keycode;
> char scancode[32]; /* 32 is just an arbitrary long array - maybe
> shorter */
> int len;
> }
>
> and re-define the ioctls. For example we might be doing:
>
> #define EVIOCGKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
> #define EVIOCSKEYCODEBIG _IOW('E', 0x04, struct keycode_table_entry)
> #define EVIOCLEARKEYCODEBIG_IOR('E', 0x04, void)
>
> Provided that the size for struct keycode_table_entry is different, _IO will
> generate
> a different magic number for those.
>
> Or, instead of using 0x04, just use another sequential number at the 'E'
> namespace.
>
> An specific function to clear the table is needed with big scancode space,
> as already discussed.
>
I'd suggest:
struct keycode_table_entry {
unsigned keycode;
unsigned index;
unsigned len;
char scancode[];
};
Use index in EVIOCGKEYCODEBIG to look up a keycode (all other fields are
ignored), that way no special function to clear the table is necessary,
instead you do a loop with:
EVIOCGKEYCODEBIG (with index 0)
EVIOCSKEYCODEBIG (with the returned struct from EVIOCGKEYCODEBIG and
keycode = KEY_RESERVED)
until EVIOCGKEYCODEBIG returns an error.
This also allows you to get all the current mappings from the kernel
without having to blindly search through an arbitrarily large keyspace.
Also, EVIOCLEARKEYCODEBIG should be:
#define EVIOCLEARKEYCODEBIG _IOR('E', 0x04, struct keycode_table_entry)
That way a user space application can simply call EVIOCLEARKEYCODEBIG,
ask the user for an appropriate keycode, fill in the keycode member of
the struct returned from EVIOCLEARKEYCODEBIG and call EVIOCSKEYCODEBIG.
On a related note, I really think the interface would benefit from
allowing more than one keytable per irrcv device with an input device
created per keytable. That way you can have one input device per remote
control. This implies that EVIOCLEARKEYCODEBIG is a bit misplaced as an
evdev IOCTL since there's an N-1 mapping between input devices and irrcv
devices.
ioctl's to set/get keycodes for ir should also take a flag parameter in
the struct to allow special properties to be set/returned for a given
keycode mapping (I'm thinking of keycodes which powers on the computer
for instance, that should be exposed to userspace somehow).
With all of that, the struct might need to be something like:
struct keycode_table_entry {
unsigned keycode; /* e.g. KEY_A */
unsigned table; /* Table index, for multiple keytables */
unsigned index; /* Index in the given keytable */
unsigned flags; /* For additional functionality */
unsigned len; /* Of the struct */
char scancode[]; /* Per-protocol scancode data follows */
};
Finally, I think irrcv should create a chardev of its own with ioctl's
like EVIOCLEARKEYCODEBIG (and RX/TX parameter setting ioctl's). The
same chardev can be used for IR blasting (by writing data to it once TX
parameters have been set).
--
David Härdeman
--
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?
On Thu, Mar 25, 2010 at 11:42:33AM -0300, Mauro Carvalho Chehab wrote: >>2) add current_protocol support on other drivers; > > Done. Patch were already merged upstream. > > The current_protocol attribute shows the protocol(s) that the device is > accepting > and allows changing it to another protocol. > > In the case of the em28xx hardware, only one protocol can be active, since > the decoder > is inside the hardware. > > On the raw IR decode implementation I've done at the saa7134, all raw pulse > events are > sent to all registered decoders, so I'm thinking on using this sysfs node to > allow > disabling the standard behavior of passing the IR codes to all decoders, > routing it > to just one decoder. > > Another alternative would be to show current_protocol only for devices with > hardware > decoder, and create one sysfs node for each decoder, allowing > enabling/disabling each > decoder individually. You're eventually going to want to add ioctl's to set a lot of TX or RX parameters in one go (stuff like active receiver(s) and transmitter(s), carrier frequency, duty cycle, timeouts, filter levels and resolution - all of which would need to be set in one operation since some hardware will need to be reset after each parameter is changed). Then you'll end up with a few things being controlled via sysfs and some being controlled via ioctls. Maybe it's a good idea to have a bitmask of supported and enabled protocols in those ioctls instead? -- David Härdeman -- 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?
On Thu, Mar 25, 2010 at 07:32:59PM +0100, Pavel Machek wrote:
> struct keycode_table_entry {
> unsigned keycode;
> int len;
> char scancode[];
> }
>
> ? gcc extension, but commonly used around kernel.
Flexible array members are ok in C99, aren't they?
--
David Härdeman
--
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?
Pavel Machek wrote:
> Hi!
>
>> This were the original plan we've discussed, back in December:
>
>
> Seems sane.
>
>> struct keycode_table_entry {
>> unsigned keycode;
>> char scancode[32]; /* 32 is just an arbitrary long array - maybe
>> shorter */
>> int len;
>> }
>
> What about
>
> struct keycode_table_entry {
> unsigned keycode;
> int len;
> char scancode[];
> }
>
> ? gcc extension, but commonly used around kernel.
Seems fine. Maybe we could just use "char *scancode" to avoid using a
gcc extension on a public interface.
--
Cheers,
Mauro
--
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?
Hi!
> This were the original plan we've discussed, back in December:
Seems sane.
> struct keycode_table_entry {
> unsigned keycode;
> char scancode[32]; /* 32 is just an arbitrary long array - maybe
> shorter */
> int len;
> }
What about
struct keycode_table_entry {
unsigned keycode;
int len;
char scancode[];
}
? gcc extension, but commonly used around kernel.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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?
I got some progress about the IR redesign.
I didn't followed the exact order of the tasks, but I think I've reached an
interesting
point where it is now possible to merge lirc_dev driver and to add the decoders
to ir-core.
I've setup an experimental tree with upstream+V4L/DVB development and some
patches
I did for IR. The RFC patches are available at:
http://git.linuxtv.org/mchehab/ir.git
This were the original plan we've discussed, back in December:
> On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab
>
>1) Port DVB drivers to use ir-core, removing the duplicated (and
> incomplete
> - as table size can't change on DVB's implementation) code that
> exists there;
Pending.
>
>2) add current_protocol support on other drivers;
Done. Patch were already merged upstream.
The current_protocol attribute shows the protocol(s) that the device is
accepting
and allows changing it to another protocol.
In the case of the em28xx hardware, only one protocol can be active, since the
decoder
is inside the hardware.
On the raw IR decode implementation I've done at the saa7134, all raw pulse
events are
sent to all registered decoders, so I'm thinking on using this sysfs node to
allow
disabling the standard behavior of passing the IR codes to all decoders,
routing it
to just one decoder.
Another alternative would be to show current_protocol only for devices with
hardware
decoder, and create one sysfs node for each decoder, allowing
enabling/disabling each
decoder individually.
Comments?
>
>3) link the corresponding input/evdev interfaces with
> /sys/class/irrcv/irrcv*;
Done. Input devices are created as part of irrcv class.
They basically create one IR class device for each IR driver. For example, my
test machine
has one saa7134 and one em28xx device, each with a different IR:
$ tree /sys/class/irrcv/
/sys/class/irrcv/
|-- irrcv0 -> ../../devices/pci:00/:00:10.0/:04:08.0/irrcv/irrcv0
`-- irrcv1 -> ../../devices/pci:00/:00:0b.1/usb1/1-3/irrcv/irrcv1
$ ls /sys/class/irrcv/irrcv0/ /sys/class/irrcv/irrcv1/
/sys/class/irrcv/irrcv0/:
current_protocol device input34 power subsystem uevent
/sys/class/irrcv/irrcv1/:
current_protocol device input35 power subsystem uevent
>
>4) make the keytable.c application aware of the sysfs vars;
Almost done. The application were re-designed, but it still needs to handle
the current_protocol. It is easy, but I want to work more at the raw decoders
before adding it to the application.
The new ir-keycode program that allows replacing the scancode/keycode table is
now at:
http://git.linuxtv.org/v4l-utils.git
under utils/keycode dir. Replacing a table at irrcv0
is as simple as doing:
./ir-keytable -c -w keycodes/avermedia_m135a
If you just want to add another table, just remove the "-c" from the above line
command.
>
>5) add an attribute to uniquely identify a remote controller;
Done. The uevent has the driver name and the IR name:
$ cat /sys/class/irrcv/irrcv0/uevent
NAME="aver-m135a-RM-JX"
DRV_NAME="saa7134"
The idea is to use those identifiers to allow replacing the IR table.
>6) write or convert an existing application to load IR tables at
> runtime;
Pending.
>
>7) get the complete 16-bit scancodes used by V4L drivers;
This is a long time task. A few maps got converted already.
>
>8) add decoder/lirc_dev glue to ir-core;
Done. Each decoder is a module that registers into ir-core. The core will call
all
registered decoders (or lirc_dev) when a raw input event occurs.
Adding a new decoder or lirc_dev is very simple.
For example, to add lirc_dev, all that is needed, from ir-core POV, is:
1) add a code like this at ir-core.h:
/* from lirc-dev.c */
#ifdef CONFIG_IR_LIRC_DEV
#define load_lirc_dev() request_module("lirc-dev")
#else
#define load_lirc_dev() 0
#endif
2) Add a call to load_lirc_dev() function at init_decoders(), on ir-raw-event.c,
in order to allow it to be automatically loaded by ir-core.
3) at the lirc-dev.c code, add:
static int lirc_decode(struct input_dev *input_dev,
struct ir_raw_event *evs, int len)
{
/* Lirc code to output data */
}
static struct ir_raw_handler lirc_handler = {
.decode = lirc_decode,
};
static int __init lirc_init(void)
{
ir_raw_handler_register(&lirc_handler);
return 0;
}
static void __exit lirc_exit(void)
{
ir_raw_handler_unregister(&lirc_handler);
}
With this glue, when ir-core is loaded, it will automatically load
lirc_dev (if compiled).
For sure, a few more callbacks will be needed for lirc to create/delete
the raw interfaces. I'll be adding register/unregister callbacks
that will allow this usage, and also the creation of per-protocol sysfs
attributes that may need for example to adjust IR timings.
>
>9) add lirc_dev module and in-kernel decoders;
Partially done. I've implemented one decoder f
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl wrote: > On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek wrote: >> Untrue. Like ethernets and wifis, bluetooth devices have unique >> addresses. Communication is bidirectional. I read a little about how Bluetooth remotes work. Correct me if I get things wrong They create pairings between the remote and the device. Each of these pairings is assigned a device type. Multiple devices in the same room are handled by the remote remembering the pairings and sending directed packets instead of broadcast. That lets you have two TVs in the same room. Bluetooth devices need to advertise what profiles they support. So on the Linux box you'd run a command to load the Bluetooth profile for TV. This command would create an evdev subdevice, load the Bluetooth keymap for TV, and tell the networking stack to advertise TV support. Next you initiate the pairing from the Bluetooth remote and pick the Linux box. This causes a pairing established exchange which tells the Linux box to make the pairing persistent. I believe the Bluetooth remote profile is handled in user space by the BlueZ stack. BlueZ should be aware of the remote pairings. When it decodes a button press it would need to inject the scancode into the correct evdev subdevice. Evdev would translate it in the keymap and create the keyevent. This is the same mechanism LIRC is using. At a more general level we're missing a way for something like Myth to declare that it is a DVR device. Myth should load, say I'm a DVR, and then the remote control subsystem should automatically create a Bluetooth DVR profile, load an IR profile for Motorola DVR on a universal remote if the box has Bluetooth, IR or 802.15.4. The whole concept of a remote control subsystem seems like it needs more design work done. We keep coming up with big areas that no one has thought about. -- Jon Smirl jonsm...@gmail.com -- 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?
On Tue 2009-12-15 15:45:14, Jon Smirl wrote: > On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek wrote: > > On Tue 2009-12-15 15:29:51, Jon Smirl wrote: > >> On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote: > >> > On Tue 2009-12-15 15:14:02, Jon Smirl wrote: > >> >> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote: > >> >> > Hi! > >> >> > > >> >> >> (11) if none is against renaming IR as RC, I'll do it on a > >> >> >> next patch; > >> >> > > >> >> > Call it irc -- infrared remote control. Bluetooth remote controls will > >> >> > have very different characteristics. > >> >> > >> >> How are they different after the scancode is extracted from the > >> >> network packet? The scancode still needs to be passed to the input > >> >> system, go through a keymap, and end up on an evdev device. > >> >> > >> >> I would expect the code for extracting the scancode to live in the > >> >> networking stack, but after it is recovered the networking code would > >> >> use the same API as IR to submit it to input. > >> > > >> > For one thing, bluetooth (etc) has concept of devices (and reliable > >> > transfer). If you have two same bluetooth remotes, you can tell them > >> > apart, unlike IR. > >> > >> IR has the same concept of devices. That's what those codes you enter > >> into a universal remote do - they set the device. > > > > They set the device _model_. > > > >> There are three classes of remotes.. > >> Fixed function - the device is hardwired > >> Universal - you can change the device > >> Multi-function - a universal that can be multiple devices - TV, cable, > >> audio, etc > >> > >> If you set two Bluetooth remotes both to the same device you can't > >> tell them apart either. > > > > Untrue. Like ethernets and wifis, bluetooth devices have unique > > addresses. Communication is bidirectional. > > I agree with that, but the 802.15.4 remote control software I've > worked with ignores the MAC address. You set your remote to send codes > for a specific device. The mac address of the remote is ignored so > that any remote can control the device. You don't need to pair > 802.15.4 remotes like Bluetooth devices need to be paired. > > I haven't played around with a Bluetooth remote. Nothing I own can > send the signals. How can a Bluetooth remote control multiple devices > in the same room if it needs to be paired? I'd guess that bluetooth remote would be very similar to bluetooth keyboard, and present itself in a very similar way. I still believe infrared is different -- it is essentially light with very little protocol above. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek wrote: > On Tue 2009-12-15 15:29:51, Jon Smirl wrote: >> On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote: >> > On Tue 2009-12-15 15:14:02, Jon Smirl wrote: >> >> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote: >> >> > Hi! >> >> > >> >> >> (11) if none is against renaming IR as RC, I'll do it on a next >> >> >> patch; >> >> > >> >> > Call it irc -- infrared remote control. Bluetooth remote controls will >> >> > have very different characteristics. >> >> >> >> How are they different after the scancode is extracted from the >> >> network packet? The scancode still needs to be passed to the input >> >> system, go through a keymap, and end up on an evdev device. >> >> >> >> I would expect the code for extracting the scancode to live in the >> >> networking stack, but after it is recovered the networking code would >> >> use the same API as IR to submit it to input. >> > >> > For one thing, bluetooth (etc) has concept of devices (and reliable >> > transfer). If you have two same bluetooth remotes, you can tell them >> > apart, unlike IR. >> >> IR has the same concept of devices. That's what those codes you enter >> into a universal remote do - they set the device. > > They set the device _model_. > >> There are three classes of remotes.. >> Fixed function - the device is hardwired >> Universal - you can change the device >> Multi-function - a universal that can be multiple devices - TV, cable, >> audio, etc >> >> If you set two Bluetooth remotes both to the same device you can't >> tell them apart either. > > Untrue. Like ethernets and wifis, bluetooth devices have unique > addresses. Communication is bidirectional. I agree with that, but the 802.15.4 remote control software I've worked with ignores the MAC address. You set your remote to send codes for a specific device. The mac address of the remote is ignored so that any remote can control the device. You don't need to pair 802.15.4 remotes like Bluetooth devices need to be paired. I haven't played around with a Bluetooth remote. Nothing I own can send the signals. How can a Bluetooth remote control multiple devices in the same room if it needs to be paired? If it doesn't use this API, how does a Bluetooth remote turn a button press into a Linux keycode on an evdev device? > > Imagine wifi connected bluetooth. It is very different from infrared. > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- Jon Smirl jonsm...@gmail.com -- 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?
On Tue 2009-12-15 15:29:51, Jon Smirl wrote: > On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote: > > On Tue 2009-12-15 15:14:02, Jon Smirl wrote: > >> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote: > >> > Hi! > >> > > >> >> (11) if none is against renaming IR as RC, I'll do it on a next > >> >> patch; > >> > > >> > Call it irc -- infrared remote control. Bluetooth remote controls will > >> > have very different characteristics. > >> > >> How are they different after the scancode is extracted from the > >> network packet? The scancode still needs to be passed to the input > >> system, go through a keymap, and end up on an evdev device. > >> > >> I would expect the code for extracting the scancode to live in the > >> networking stack, but after it is recovered the networking code would > >> use the same API as IR to submit it to input. > > > > For one thing, bluetooth (etc) has concept of devices (and reliable > > transfer). If you have two same bluetooth remotes, you can tell them > > apart, unlike IR. > > IR has the same concept of devices. That's what those codes you enter > into a universal remote do - they set the device. They set the device _model_. > There are three classes of remotes.. > Fixed function - the device is hardwired > Universal - you can change the device > Multi-function - a universal that can be multiple devices - TV, cable, > audio, etc > > If you set two Bluetooth remotes both to the same device you can't > tell them apart either. Untrue. Like ethernets and wifis, bluetooth devices have unique addresses. Communication is bidirectional. Imagine wifi connected bluetooth. It is very different from infrared. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
On Tue, Dec 15, 2009 at 3:19 PM, Pavel Machek wrote: > On Tue 2009-12-15 15:14:02, Jon Smirl wrote: >> On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote: >> > Hi! >> > >> >> (11) if none is against renaming IR as RC, I'll do it on a next >> >> patch; >> > >> > Call it irc -- infrared remote control. Bluetooth remote controls will >> > have very different characteristics. >> >> How are they different after the scancode is extracted from the >> network packet? The scancode still needs to be passed to the input >> system, go through a keymap, and end up on an evdev device. >> >> I would expect the code for extracting the scancode to live in the >> networking stack, but after it is recovered the networking code would >> use the same API as IR to submit it to input. > > For one thing, bluetooth (etc) has concept of devices (and reliable > transfer). If you have two same bluetooth remotes, you can tell them > apart, unlike IR. IR has the same concept of devices. That's what those codes you enter into a universal remote do - they set the device. There are three classes of remotes.. Fixed function - the device is hardwired Universal - you can change the device Multi-function - a universal that can be multiple devices - TV, cable, audio, etc If you set two Bluetooth remotes both to the same device you can't tell them apart either. Two identical fixed function remotes can be distinguished and they shouldn't be distinguishable. To distinguish between universal remotes just change the device being emulated. > > So yes, keymapping is the same, but that's pretty much it. Decoding > will not be the same (IR is special), etc... > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- Jon Smirl jonsm...@gmail.com -- 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?
On Tue 2009-12-15 15:14:02, Jon Smirl wrote: > On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote: > > Hi! > > > >> (11) if none is against renaming IR as RC, I'll do it on a next > >> patch; > > > > Call it irc -- infrared remote control. Bluetooth remote controls will > > have very different characteristics. > > How are they different after the scancode is extracted from the > network packet? The scancode still needs to be passed to the input > system, go through a keymap, and end up on an evdev device. > > I would expect the code for extracting the scancode to live in the > networking stack, but after it is recovered the networking code would > use the same API as IR to submit it to input. For one thing, bluetooth (etc) has concept of devices (and reliable transfer). If you have two same bluetooth remotes, you can tell them apart, unlike IR. So yes, keymapping is the same, but that's pretty much it. Decoding will not be the same (IR is special), etc... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
On Tue, Dec 15, 2009 at 2:58 PM, Pavel Machek wrote: > Hi! > >> (11) if none is against renaming IR as RC, I'll do it on a next patch; > > Call it irc -- infrared remote control. Bluetooth remote controls will > have very different characteristics. How are they different after the scancode is extracted from the network packet? The scancode still needs to be passed to the input system, go through a keymap, and end up on an evdev device. I would expect the code for extracting the scancode to live in the networking stack, but after it is recovered the networking code would use the same API as IR to submit it to input. -- Jon Smirl jonsm...@gmail.com -- 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?
Hi! > (11) if none is against renaming IR as RC, I'll do it on a next patch; Call it irc -- infrared remote control. Bluetooth remote controls will have very different characteristics. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 wrote: > On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab > wrote: >> Pavel Machek wrote: > That is why I think we should go the other way around - introduce the > core which receivers could plug into and decoder framework and once it > is ready register lirc-dev as one of the available decoders. > I've committed already some IR restruct code on my linux-next -git tree: http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git The code there basically moves the input/evdev registering code and scancode/keycode management code into a separate ir-core module. To make my life easy, I've moved the code temporarily into drivers/media/IR. This way, it helps me to move V4L specific code outside ir-core and to later use it for DVB. After having it done, probably the better is to move it to be under /drivers or /drivers/input. >>> Well, -next is for stuff to be merged into 2.6.34. You are quite an >>> optimist. >>> Pavel >> Well, we need those changes anyway for the in-kernel drivers, and I'm not >> seeing >> on the current patches any reason for not having them for 2.6.34. >> >> I've added all the ir-core patches I did so far at linux-next. This helps >> people >> to review and contribute. >> >> The patches are already working with the in-kernel em28xx driver, allowing to >> replace the keycode table and the protocol used by the hardware IR decoder. >> I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC >> based IR table (Terratec Cinergy XS remote controller). >> >> The current Remote Controller core module (ir-core) is currently doing: >> >>- Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing >> memory >> dynamically, based on the needed size for scancode/keycode table; >> >>- scancodes can be up to 16 bits currently; >> >>- sysfs is registering /sys/class/irrcv and creating one branch for >> each >> different RC receiver, numbering from irrcv0 to irrcv255; >> >>- one irrcv note is created: current_protocol; >> >>- reading /sys/class/irrcv/irrcv*/current_protocol returns the >> protocol >> currently used by the driver; >> >>- writing to /sys/class/irrcv/irrcv*/current_protocol changes the >> protocol >> to a new one, by calling a callback, asking the driver to change the >> protocol. If >> the protocol is not support, it returns -EINVAL; >> >>- all V4L drivers are already using ir-core; >> >>- em28xx driver is implementing current_protocol show/store support. >> >> TODO: > > I'd add a pulse based receiver like a MSMCE to make sure the core API is > right. > MSME has transmit hardware too. Makes sense. This can be done after having the lirc_dev integrated. > What about creating multiple evdev devices with their own keymaps off > from a single receiver? That's a key part of making multi-function > remotes work. I was sure I missed something at the TODO :) > > >>1) Port DVB drivers to use ir-core, removing the duplicated (and >> incomplete >> - as table size can't change on DVB's implementation) code that >> exists there; >> >>2) add current_protocol support on other drivers; >> >>3) link the corresponding input/evdev interfaces with >> /sys/class/irrcv/irrcv*; >> >>4) make the keytable.c application aware of the sysfs vars; >> >>5) add an attribute to uniquely identify a remote controller; >> >>6) write or convert an existing application to load IR tables at >> runtime; >> >>7) get the complete 16-bit scancodes used by V4L drivers; >> >>8) add decoder/lirc_dev glue to ir-core; >> >>9) add lirc_dev module and in-kernel decoders; >> >>10) extend keycode table replacement to support big/variable sized >> scancodes; >> >>11) rename IR->RC; >> >>12) redesign or remove ir-common module. It currently handles >> in-kernel >>keycode tables and a few helper routines for raw pulse/space >> decode; >> >>13) move drivers/media/IR to a better place; >> So, we have also at the todo list: 14) add pulse based drivers; 15) make in-kernel pulse-based devices to use lirc_dev; 16) add an API to dynamically create evdev interfaces for scancode filtering; >> >> comments: >> >>Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's >> spare >> time for it; >> >>(7) is probably the more complex task, since it requires to re-test >> all in-kernel >> supported remote controlle scancode/keycode tables, to get the complete IR >> keycode >> and rewrite the getkeycode functions that are currently masking the IR code >> into 7 bits. >> We'll need users help on this task, but this can be done gradually, like I >> did with >> two RC keytables on em28xx driver, whi
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Tue, Dec 15, 2009 at 8:33 AM, Mauro Carvalho Chehab wrote: > Pavel Machek wrote: That is why I think we should go the other way around - introduce the core which receivers could plug into and decoder framework and once it is ready register lirc-dev as one of the available decoders. >>> I've committed already some IR restruct code on my linux-next -git tree: >>> >>> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git >>> >>> The code there basically moves the input/evdev registering code and >>> scancode/keycode management code into a separate ir-core module. >>> >>> To make my life easy, I've moved the code temporarily into drivers/media/IR. >>> This way, it helps me to move V4L specific code outside ir-core and to later >>> use it for DVB. After having it done, probably the better is to move it to >>> be under /drivers or /drivers/input. >> >> Well, -next is for stuff to be merged into 2.6.34. You are quite an >> optimist. >> Pavel > > Well, we need those changes anyway for the in-kernel drivers, and I'm not > seeing > on the current patches any reason for not having them for 2.6.34. > > I've added all the ir-core patches I did so far at linux-next. This helps > people > to review and contribute. > > The patches are already working with the in-kernel em28xx driver, allowing to > replace the keycode table and the protocol used by the hardware IR decoder. > I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC > based IR table (Terratec Cinergy XS remote controller). > > The current Remote Controller core module (ir-core) is currently doing: > > - Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing > memory > dynamically, based on the needed size for scancode/keycode table; > > - scancodes can be up to 16 bits currently; > > - sysfs is registering /sys/class/irrcv and creating one branch for > each > different RC receiver, numbering from irrcv0 to irrcv255; > > - one irrcv note is created: current_protocol; > > - reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol > currently used by the driver; > > - writing to /sys/class/irrcv/irrcv*/current_protocol changes the > protocol > to a new one, by calling a callback, asking the driver to change the > protocol. If > the protocol is not support, it returns -EINVAL; > > - all V4L drivers are already using ir-core; > > - em28xx driver is implementing current_protocol show/store support. > > TODO: I'd add a pulse based receiver like a MSMCE to make sure the core API is right. MSME has transmit hardware too. What about creating multiple evdev devices with their own keymaps off from a single receiver? That's a key part of making multi-function remotes work. > 1) Port DVB drivers to use ir-core, removing the duplicated (and > incomplete > - as table size can't change on DVB's implementation) code that > exists there; > > 2) add current_protocol support on other drivers; > > 3) link the corresponding input/evdev interfaces with > /sys/class/irrcv/irrcv*; > > 4) make the keytable.c application aware of the sysfs vars; > > 5) add an attribute to uniquely identify a remote controller; > > 6) write or convert an existing application to load IR tables at > runtime; > > 7) get the complete 16-bit scancodes used by V4L drivers; > > 8) add decoder/lirc_dev glue to ir-core; > > 9) add lirc_dev module and in-kernel decoders; > > 10) extend keycode table replacement to support big/variable sized > scancodes; > > 11) rename IR->RC; > > 12) redesign or remove ir-common module. It currently handles in-kernel > keycode tables and a few helper routines for raw pulse/space > decode; > > 13) move drivers/media/IR to a better place; > > > comments: > > Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's > spare > time for it; > > (7) is probably the more complex task, since it requires to re-test > all in-kernel > supported remote controlle scancode/keycode tables, to get the complete IR > keycode > and rewrite the getkeycode functions that are currently masking the IR code > into 7 bits. > We'll need users help on this task, but this can be done gradually, like I > did with > two RC keytables on em28xx driver, while preserving the other keytables as-is. > > (8) I suggest that this glue will be submitted together with lirc_dev > patch > series, as the biggest client for it is lirc. In principle, kfifo seems the > better > interface for lirc_dev -> decoders interface. For the decoders -> RC core > interface, > there's an interface already used on V4L drivers, provided by ir-common, > using evdev > kernel API. This may need some review. > > (9) depends on lirc API discusions. My proposal is that peo
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Pavel Machek wrote: >>> That is why I think we should go the other way around - introduce the >>> core which receivers could plug into and decoder framework and once it >>> is ready register lirc-dev as one of the available decoders. >>> >> I've committed already some IR restruct code on my linux-next -git tree: >> >> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git >> >> The code there basically moves the input/evdev registering code and >> scancode/keycode management code into a separate ir-core module. >> >> To make my life easy, I've moved the code temporarily into drivers/media/IR. >> This way, it helps me to move V4L specific code outside ir-core and to later >> use it for DVB. After having it done, probably the better is to move it to >> be under /drivers or /drivers/input. > > Well, -next is for stuff to be merged into 2.6.34. You are quite an > optimist. > Pavel Well, we need those changes anyway for the in-kernel drivers, and I'm not seeing on the current patches any reason for not having them for 2.6.34. I've added all the ir-core patches I did so far at linux-next. This helps people to review and contribute. The patches are already working with the in-kernel em28xx driver, allowing to replace the keycode table and the protocol used by the hardware IR decoder. I tested here by replacing an RC-5 based IR table (Hauppauge Grey) by a NEC based IR table (Terratec Cinergy XS remote controller). The current Remote Controller core module (ir-core) is currently doing: - Implementation of the existing EVIO[G|S]KEYCODE, expanding/feeing memory dynamically, based on the needed size for scancode/keycode table; - scancodes can be up to 16 bits currently; - sysfs is registering /sys/class/irrcv and creating one branch for each different RC receiver, numbering from irrcv0 to irrcv255; - one irrcv note is created: current_protocol; - reading /sys/class/irrcv/irrcv*/current_protocol returns the protocol currently used by the driver; - writing to /sys/class/irrcv/irrcv*/current_protocol changes the protocol to a new one, by calling a callback, asking the driver to change the protocol. If the protocol is not support, it returns -EINVAL; - all V4L drivers are already using ir-core; - em28xx driver is implementing current_protocol show/store support. TODO: 1) Port DVB drivers to use ir-core, removing the duplicated (and incomplete - as table size can't change on DVB's implementation) code that exists there; 2) add current_protocol support on other drivers; 3) link the corresponding input/evdev interfaces with /sys/class/irrcv/irrcv*; 4) make the keytable.c application aware of the sysfs vars; 5) add an attribute to uniquely identify a remote controller; 6) write or convert an existing application to load IR tables at runtime; 7) get the complete 16-bit scancodes used by V4L drivers; 8) add decoder/lirc_dev glue to ir-core; 9) add lirc_dev module and in-kernel decoders; 10) extend keycode table replacement to support big/variable sized scancodes; 11) rename IR->RC; 12) redesign or remove ir-common module. It currently handles in-kernel keycode tables and a few helper routines for raw pulse/space decode; 13) move drivers/media/IR to a better place; comments: Tasks (1) to (6) for sure can happen to 2.6.34, depending on people's spare time for it; (7) is probably the more complex task, since it requires to re-test all in-kernel supported remote controlle scancode/keycode tables, to get the complete IR keycode and rewrite the getkeycode functions that are currently masking the IR code into 7 bits. We'll need users help on this task, but this can be done gradually, like I did with two RC keytables on em28xx driver, while preserving the other keytables as-is. (8) I suggest that this glue will be submitted together with lirc_dev patch series, as the biggest client for it is lirc. In principle, kfifo seems the better interface for lirc_dev -> decoders interface. For the decoders -> RC core interface, there's an interface already used on V4L drivers, provided by ir-common, using evdev kernel API. This may need some review. (9) depends on lirc API discusions. My proposal is that people submit an RFC with the lirc API reviewed to the ML's, for people to ack/nack/comment. After that, re-submit the lirc_dev module integrating it into ir-core and with the reviewed API; (10) depends on EVIO[G|S]KEYCODE discussions we've already started. I did a proposal about it. I'll review, based on the comments and re-submit it; (11) if none is against renaming IR as RC, I'll do it on a next patch; (12) depends on having lirc_dev added, for the removal of ir-fu
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
> > This sounds like "merge first, think later"... > > > > The question is why we need to merge lirc interface right now, before we > > agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev > > yet and, looking at the way things are shaping, no drivers will be > > _directly_ using it after it is complete. So, even if we merge it right > > away, the code will have to be restructured and reworked. Unfortunately, > > just merging what Jarod posted, will introduce sysfs hierarchy which > > is userspace interface as well (although we not as good maintaining it > > at times) and will add more constraints on us. > > > > That is why I think we should go the other way around - introduce the > > core which receivers could plug into and decoder framework and once it > > is ready register lirc-dev as one of the available decoders. > > > > I've committed already some IR restruct code on my linux-next -git tree: > > http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git > > The code there basically moves the input/evdev registering code and > scancode/keycode management code into a separate ir-core module. > > To make my life easy, I've moved the code temporarily into drivers/media/IR. > This way, it helps me to move V4L specific code outside ir-core and to later > use it for DVB. After having it done, probably the better is to move it to > be under /drivers or /drivers/input. Well, -next is for stuff to be merged into 2.6.34. You are quite an optimist. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
On Sun 2009-12-06 12:59:00, Christoph Bartelmus wrote: > Hi Dmitry, > > on 05 Dec 09 at 22:55, Dmitry Torokhov wrote: > [...] > > I do not believe you are being realistic. Sometimes we just need to say > > that the device is a POS and is just not worth it. Remember, there is > > still "lirc hole" for the hard core people still using solder to produce > > something out of the spare electronic components that may be made to > > work (never mind that it causes the CPU constantly poll the device, not > > letting it sleep and wasting electricity as a result - just hypotetical > > example here). > > The still seems to be is a persistent misconception that the home-brewn > receivers need polling or cause heavy CPU load. No they don't. All of them > are IRQ based. I have at least one that needs polling/signal processing... somewhere. IR LED connected to mic input. Anyway, clearly hacked-up devices like that are better left for userland solutions. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
Dmitry Torokhov wrote:
> On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
>> Jon Smirl writes:
>>
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
>>> I'd like to see a semi-complete design for an in-kernel IR system
>>> before anything is merged from any source.
>> This is a way to nowhere, there is no logical dependency between LIRC
>> and input layer IR.
>>
>> There is only one thing which needs attention before/when merging LIRC:
>> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and,
>> actually, making a correct IR core design without the LIRC merged can be
>> only harder.
>
> This sounds like "merge first, think later"...
>
> The question is why we need to merge lirc interface right now, before we
> agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev
> yet and, looking at the way things are shaping, no drivers will be
> _directly_ using it after it is complete. So, even if we merge it right
> away, the code will have to be restructured and reworked. Unfortunately,
> just merging what Jarod posted, will introduce sysfs hierarchy which
> is userspace interface as well (although we not as good maintaining it
> at times) and will add more constraints on us.
>
> That is why I think we should go the other way around - introduce the
> core which receivers could plug into and decoder framework and once it
> is ready register lirc-dev as one of the available decoders.
>
I've committed already some IR restruct code on my linux-next -git tree:
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git
The code there basically moves the input/evdev registering code and
scancode/keycode management code into a separate ir-core module.
To make my life easy, I've moved the code temporarily into drivers/media/IR.
This way, it helps me to move V4L specific code outside ir-core and to later
use it for DVB. After having it done, probably the better is to move it to
be under /drivers or /drivers/input.
The enclosed patch just adds a skeleton for the new sysfs class for remote
controllers and registers an yet unused ir_protocol attribute, creating this
tree:
/sys/class/irrcv/
|-- irrcv0
| |-- ir_protocol
| |-- power
| | `-- wakeup
| |-- subsystem -> ../../irrcv
| `-- uevent
`-- irrcv1
|-- ir_protocol
|-- power
| `-- wakeup
|-- subsystem -> ../../irrcv
`-- uevent
While writing the code, it occurred to me that calling it as "IR" is not the
better way,
since there's nothing on the code that is related to infra-red, but, instead, is
is related to remote controller.
So, if it is ok for everybudy, IMO, we should use, instead "rc" meaning remote
controller,
naming the core module as "rc-core", putting it into drivers/rc.
Also, since the same rc chip can have a receiver and a transmitter, maybe we
can create the
class as:
/sys/class/rc
rcrcv0/
rcrcv1/
...
rctx0/
rctx1/
...
Comments?
---
linux/drivers/media/IR/Makefile |2
linux/drivers/media/IR/ir-keytable.c | 17 +-
linux/drivers/media/IR/ir-sysfs.c| 94 +++
linux/include/media/ir-core.h| 12 +++-
4 files changed, 119 insertions(+), 6 deletions(-)
--- master.orig/linux/drivers/media/IR/Makefile
+++ master/linux/drivers/media/IR/Makefile
@@ -1,5 +1,5 @@
ir-common-objs := ir-functions.o ir-keymaps.o
-ir-core-objs := ir-keytable.o
+ir-core-objs := ir-keytable.o ir-sysfs.o
obj-$(CONFIG_IR_CORE) += ir-core.o
obj-$(CONFIG_VIDEO_IR) += ir-common.o
--- master.orig/linux/drivers/media/IR/ir-keytable.c
+++ master/linux/drivers/media/IR/ir-keytable.c
@@ -448,12 +448,21 @@ int ir_input_register(struct input_dev *
input_set_drvdata(input_dev, ir_dev);
rc = input_register_device(input_dev);
+ if (rc < 0)
+ goto err;
+
+ rc = ir_register_class(input_dev);
if (rc < 0) {
- kfree(rc_tab->scan);
- kfree(ir_dev);
- input_set_drvdata(input_dev, NULL);
+ input_unregister_device(input_dev);
+ goto err;
}
+ return 0;
+
+err:
+ kfree(rc_tab->scan);
+ kfree(ir_dev);
+ input_set_drvdata(input_dev, NULL);
return rc;
}
EXPORT_SYMBOL_GPL(ir_input_register);
@@ -473,6 +482,8 @@ void ir_input_unregister(struct input_de
kfree(rc_tab->scan);
rc_tab->scan = NULL;
+ ir_unregister_class(dev);
+
kfree(ir_dev);
input_unregister_device(dev);
}
--- /dev/null
+++ master/linux/drivers/media/IR/ir-sysfs.c
@@ -0,0 +1,94 @@
+/* ir-register.c - handle IR scancode->keycode tables
+ *
+ * Copyright (C) 2009 by Mauro Carvalho Chehab
+ *
+ * This program is free software; yo
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sat 2009-11-28 21:21:57, Krzysztof Halasa wrote: > Jon Smirl writes: > > > We have one IR receiver device and multiple remotes. How does the > > input system know how many devices to create corresponding to how many > > remotes you have? There is no current mechanism to do that. You need > > an input device for each remote so that you can do the EVIOCSKEYCODE > > against it. Some type of "create subdevice" IOCTL will need to be > > built. > > Thinking about it, I'm not sure. Why do we want multiple remote devices? > (not multiple remotes, that's clear). Computer in the basement, one ir receiver + usb speakers in kitchen, second ir receiver + speakers + monitor in living room. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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?
On Sun, 6 Dec 2009, Krzysztof Halasa wrote: Andy Walls writes: Yes, I agree. I do not know what percentage of current Linux users are technical vs non-technical, so I cannot gauge the current improtance. I can see the trend line though: as time goes by, the percentage of all linux users that have a technical bent will only get smaller. This IMHO shouldn't matter. If users can configure their keymaps for e.g. games with a graphical utility (and they easily can), they can do the same with their remotes, at least with these using common sane protocols. The only thing needed is a good GUI utility. Ergo - it's not a kernel issue. The "default bundled", or PnP, won't work well in comparison to a GUI utility, I wouldn't worry about it too much (though adding it to udev and co is trivial and we should do it - even if not PnP but asking first about the actual remote used). how is this problem any different from figuring out the keymap of a keyboard? there are many defined keymaps (including cases where keys are labled different things on the keyboard but send identical codes) currently in linux distros the user can either select the keymap, or the installer will ask the user to press specific keys (or indicate that they don't exist) until the installer can guess the keymap to use. why would this not work for IR remotes as well? and just like linux has some default keymaps that it uses that mostly work for the common case, there could be default IR keymaps that map the common keys for all remotes to the appropriate keycodes. it will mean that by default you won't see a difference between a DVD, VCR, DVR, etc play button, but it will mean that someone picking up a random remote and pointing it at the linux box will probably get minimal functionality. then with a utility to tweak the keymap (or load a more specific one) the user can do better. this would also integrate very nicely with they 'multimedia keyboards' that have lots of buttons on them as well, unless you tell it otherwise, play is play is play no matter which play button is pressed. David Lang -- 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?
On Tue, 2009-12-08 at 23:30 +0100, Christoph Bartelmus wrote: > Hi Andy, > > on 07 Dec 09 at 23:10, Andy Walls wrote: > [...] > > (Christoph can correct me if I get anything wrong.) > > Just a few additions. Christoph, Thanks for the corrections and additions. :) > [...] > > I know that the hardware I work with has sub 100 ns resolution, > > Highest IR carrier frequency I know is 500kHz. usec resolution is enough > even for raw modulated IR pulses. But you only look at the signal after it > has been demodulated by the IR chip, so higher resolution would be > overkill. Yes, it's overkill. It is more of a side effect of how I set up the hardware to uses as much of the bits in the pulse width measurement counter as possible for the longest expected valid measurment width. The LSB of the hardware pulse width measurement counter can convey a time change of as little as 74 ns depending on the setup of the Conexant integrated IR controller. > [...] > >> How do you define the start and stop of sequences? > > > For the end of Rx signalling: > > > > Well with the Conexant hardware I can set a maximum pulse (mark or > > space) width, and the hardware will generate an Rx Timeout interrupt to > > signal the end of Rx when a space ends up longer than that max pulse > > width. The hardware also puts a special marker in the hardware pulse > > widht measurement FIFO (in band signalling essentially). > > > > I'm not sure anything like that gets communicated to userspace via > > lirc_dev, and I'm too tired to doublecheck right now. > > There is no such thing in the protocol. Some devices cannot provide any > end of signal marker, so lircd handles this using timers. > > If there is some interest, the MODE2 protocol can be extended. We still > have 7 bits unused... As I thought about this more, I could just pass up a space the length of the pulse width measurment timeout from the kernel up to LIRC. LIRC's decoders should know that the space is too long as well. No changes needed - I think. > [...] > >> Is transmitting synchronous or queued? > > > kfifo's IIRC. > > No, it's synchronous. > > >> How big is the transmit queue? > > No queue. Oops, thanks for the correction. > [...] > > My particular gripes about the current LIRC interface: > > 2. I have hardware where I can set max_pulse_width so I can optimize > > pulse timer resolution and have the hardware time out rapidly on end of > > RX. I also have hardware where I can set a min_pulse_width to set a > > hardware low-pass/glitch filter. Currently LIRC doesn't have any way to > > set these, but it would be nice to have. > > Should be really easy to add these. The actual values could be derived > from the config files easily. Good. I thought it would be so. > > In band signalling of a > > hardware detected "end of Rx" may also make sense then too. > > See above. > > > 3. As I mentioned before, it would be nice if LIRC could set a batch of > > parameters atomically somehow, instead of with a series of ioctl()s. I > > can work around this in kernel though. > > Is there any particular sequence that you are concerned about? > Setting carrier frequency and then duty cycle is a bit problematic. > Currently it's solved by resetting the duty cycle to 50% each time you > change the carrier frequency. > But as the LIRC interface is "one user only", I don't see a real problem. The case I worry about is enabling the IR Rx hardware without the low pass filter properly set up to be consistent with the minimum expected Rx pulse width and the desired Rx carrier window or maximum expected Rx pulse width. The result could be a lot of useless interrupts from IR "glitch" measurements in bad ambient light conditions until all the parameters are consistent. Regards, Andy > Christoph -- 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?
Hi Andy, on 07 Dec 09 at 23:10, Andy Walls wrote: [...] > (Christoph can correct me if I get anything wrong.) Just a few additions. [...] >> What is the time standard for the data, where does it come from? > I think it is usec, IIRC. Yes, it is. > I know that the hardware I work with has sub 100 ns resolution, Highest IR carrier frequency I know is 500kHz. usec resolution is enough even for raw modulated IR pulses. But you only look at the signal after it has been demodulated by the IR chip, so higher resolution would be overkill. [...] >> How do you define the start and stop of sequences? > For the end of Rx signalling: > > Well with the Conexant hardware I can set a maximum pulse (mark or > space) width, and the hardware will generate an Rx Timeout interrupt to > signal the end of Rx when a space ends up longer than that max pulse > width. The hardware also puts a special marker in the hardware pulse > widht measurement FIFO (in band signalling essentially). > > I'm not sure anything like that gets communicated to userspace via > lirc_dev, and I'm too tired to doublecheck right now. There is no such thing in the protocol. Some devices cannot provide any end of signal marker, so lircd handles this using timers. If there is some interest, the MODE2 protocol can be extended. We still have 7 bits unused... > If you have determined the protocol you are after, it's easy to know > what the pulse count should be and what the max pulse width should be (+ > slop for crappy hardware) so finding the end of an Rx isn't hard. The > button repeats intervals are *very* large. I've never seen a remote > rapid fire codes back to back. I did. There are some protocols that have a gap of only 6000 us between signals. And the settop boxes are very picky about this. If you make it too long, they won't accept the command. [...] >> Is transmitting synchronous or queued? > kfifo's IIRC. No, it's synchronous. >> How big is the transmit queue? No queue. [...] > My particular gripes about the current LIRC interface: > > 1. The one thing that I wish were documented better were the distinction > between LIRC_MODE_PULSE, LIRC_MODE_RAW, and LIRC_MODE2 modes of > operation. I think I've figured it out, but I had to look at a lot of > LIRC drivers to do so. No driver uses RAW until now and lircd does not support it. PULSE is used on the transmit path, MODE2 on the receive path. There is no special reasoning for that, it's rather historic. MODE2 makes sense on the receive path because you can easily distinguish between pulse/space. > 2. I have hardware where I can set max_pulse_width so I can optimize > pulse timer resolution and have the hardware time out rapidly on end of > RX. I also have hardware where I can set a min_pulse_width to set a > hardware low-pass/glitch filter. Currently LIRC doesn't have any way to > set these, but it would be nice to have. Should be really easy to add these. The actual values could be derived from the config files easily. > In band signalling of a > hardware detected "end of Rx" may also make sense then too. See above. > 3. As I mentioned before, it would be nice if LIRC could set a batch of > parameters atomically somehow, instead of with a series of ioctl()s. I > can work around this in kernel though. Is there any particular sequence that you are concerned about? Setting carrier frequency and then duty cycle is a bit problematic. Currently it's solved by resetting the duty cycle to 50% each time you change the carrier frequency. But as the LIRC interface is "one user only", I don't see a real problem. Christoph -- 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?
Hi Jon, on 08 Dec 09 at 08:34, Jon Smirl wrote: [...] > The point of those design review questions was to illustrate that the > existing LIRC system is only partially designed. Subsystems need to be > fully designed before they get merged. I'd say that a system that has proven itself in real world applications for >10 years, does not deserve to be called partially designed. > For example 36-40K and 56K IR signals are both in use. It is a simple > matter to design a receiver (or buy two receivers) that would support > both these frequencies. But the current LIRC model only supports a > single IR receiver. Adjusting it to support two receivers is going to > break the ABI. Really? When we added support for multiple transmitters, we somehow managed to do without breaking the ABI. Do I miss something? Your example could even now be solved by using the LIRC_SET_REC_CARRIER ioctl. The driver would have to choose the receiver that best fits the requested frequency. [...] > We need to think about all of these use cases before designing the > ABI. Only after we think we have a good ABI design should code start > being merged. Of course we may make mistakes and have to fix the ABI, > but there is nothing to be gained by merging the existing ABI if we > already know it has problems. The point is that we did not get up this morning and started to think about how the LIRC interface should look like. That happened 10 years ago. I'm not saying that the interface is the nicest thing ever invented, but it works and is extendable. If you see that something is missing please bring it up. Christoph -- 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?
Hi Dmitry, on 06 Dec 09 at 23:51, Dmitry Torokhov wrote: [...] >>> I suppose we could add MSC_SCAN_END event so that we can transmit >>> "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by >>> MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 >>> bit. >> >> And I set a timeout to know that no MSC_SCAN_END will arrive? This is >> broken design IMHO. >> > EV_SYN signals the end of state transmission. >> Furthermore lircd needs to know the length of the scan code in bits, not >> as a multiple of 32. > I really do not think that LIRCD is the type of application that should > be using evdev interface, but rather other way around. Well, all I'm asking is that lircd can keep using the LIRC interface for getting the scan codes. ;-) Christoph -- 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?
On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote: > Dmitry Torokhov writes: > > > Why woudl we want to do this? Quite often there is a need for "observer" > > that maybe does not act on data but allows capturing it. Single-user > > inetrfaces are PITA. > > Lircd can work as a multiplexer. What this has to do with my statement? Did you mean retransmitter of sorts? Also I may explicitely not want the data stream to be multiplexed... > IMHO single-open lirc interface is ok, > though we obviously need simultaneous operation of in-kernel decoders. Why is the distinction? -- Dmitry -- 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?
On Tue, Dec 08, 2009 at 09:17:42AM -0200, Mauro Carvalho Chehab wrote: > Jon Smirl wrote: > > On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab > > wrote: > > >>> Where is the documentation for the protocol? > >> I'm not sure what you're meaning here. I've started a doc about IR at the > >> media > > > > What is the format of the pulse stream data coming out of the lirc device? > > AFAIK, it is at: > http://www.lirc.org/html/index.html > > It would be nice to to add it to DocBook after integrating the API in kernel. > > >> docbook. This is currently inside the kernel Documents/DocBook. If you want > >> to browse, it is also available as: > >> > >>http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html > >> > >> For sure we need to better document the IR's, and explain the API's there. > >> > >>> Is it a device interface or something else? > >> lirc_dev should create a device interface. > >> > >>> What about capabilities of the receiver, what frequencies? > >>> If a receiver has multiple frequencies, how do you report what > >>> frequency the data came in on? > >> IMO, via sysfs. > > > > Say you have a hardware device with two IR diodes, one at 38K and one > > at 56K. Both of these receivers can get pulses. How do we tell the > > user space app which frequency the pulses were received on? Seems to > > me like there has to be a header on the pulse data indicating the > > received carrier frequency. There is also baseband signaling. sysfs > > won't work for this because of the queuing latency. > > Simply create two interfaces. One for each IR receiver. At sysfs, you'll > have /sys/class/irrcv/irrcv0 for the first one and /sys/class/irrcv/irrcv1. Yes, please. Distinct hardware - distinct representation in the kernel. This is the most sane way. ... > >> > >>> What is the interface for attaching an in-kernel decoder? > >> IMO, it should use the kfifo for it. However, if we allow both raw data and > >> in-kernel decoders to read data there, we'll need a spinlock to protect the > >> kfifo. Probably we should do what input layer does - the data is pushed into all handlers that are signed up for it and they can deal with it at their leisure. > >> > >>> If there is an in-kernel decoder should the pulse data stop being > >>> reported, partially stopped, something else? > >> I don't have a strong opinion here, but, from the previous discussions, it > >> seems that people want it to be double-reported by default. If so, I think > >> we need to implement a command at the raw interface to allow disabling the > >> in-kernel decoder, while the raw interface is kept open. > > > > Data could be sent to the in-kernel decoders first and then if they > > don't handle it, send it to user space. You do not know what userspace wants to do with the data. They may want to simply observe it, store or do something else. Since we do provide interface for such raw[ish] data we just need to transmit it to userpsace as long as there are users (i.e. interface is open). > > Hmm... like adding a delay if the raw userspace is open and, if the raw > userspace > doesn't read all pulse data, it will send via in-kernel decoder instead? This > can > work, but I'm not sure if this is the better way, and will require some logic > to > synchronize lirc_dev and IR core modules. Also, doing it key by key will > introduce > some delay. > > If you're afraid of having the userspace app hanged and having no IR output, > it would be simpler to just close the raw interface if an available data > won't be > read after a bigger timeout (3 seconds? 5 seconds?). We can not foresee all use cases. Just let all parties signed up for the data get and process it, do not burden the core with heuristics. -- Dmitry -- 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?
On Tue, Dec 08, 2009 at 09:58:53AM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote: > > >>> What about capabilities of the receiver, what frequencies? > >>> If a receiver has multiple frequencies, how do you report what > >>> frequency the data came in on? > >> IMO, via sysfs. > > > > We probably need to think what exactly we report through sysfs siunce it > > is ABI of sorts. > > Yes, sure. > > Probably, the exact needs will popup only when we start to actually writing > that > part of the core. > > My intention for now is to just create a /sys/class/irrcv, with one node > per each IR receiver and adding a protocol enumeration/selection node > there, and add some capabilities for the in-kernel decoders and lirc_dev > to create new nodes under that class. > > When the decoders/lirc_dev patches popup, we'll need to review those sysfs > API's. > > >>> What about multiple apps simultaneously using the pulse data? > >> IMO, the better is to limit the raw interface to just one open. > >> > > > > Why woudl we want to do this? Quite often there is a need for "observer" > > that maybe does not act on data but allows capturing it. Single-user > > inetrfaces are PITA. > > That should work fine as well, but I'm not sure how we'll detect overrun with > several kfifo readers. > Push the data into readers so they can do te decoding at their own pace. Some can do it in interrupt context, some will need workqueue/thread. They can also regilate the depth of the buffer, according to their needs. > >>> How big is the receive queue? > >> It should be big enough to receive at least one keycode event. Considering > >> that > >> the driver will use kfifo (IMO, it is a good strategy, especially since you > >> won't need any lock if just one open is allowed), it will require a power > >> of two size. > >> > > > > Would not it be wither driver- or protocol-specific? > > Probably. > > > > >>> How does access work, root only or any user? > >> IMO, it should be the same requirement as used by an input interface. > >> > >>> How are capabilities exposed, sysfs, etc? > >> IMO, sysfs. > >> > >>> What is the interface for attaching an in-kernel decoder? > >> IMO, it should use the kfifo for it. However, if we allow both raw data and > >> in-kernel decoders to read data there, we'll need a spinlock to protect the > >> kfifo. > >> > > > > I think Jon meant userspace interface for attaching particular decoder. > > I don't think we need an userspace interface for the in-kernel decoders. All > it needs is to enable/disable the protocol decoders, imo via sysfs interface. > > >>> If there is an in-kernel decoder should the pulse data stop being > >>> reported, partially stopped, something else? > >> I don't have a strong opinion here, but, from the previous discussions, it > >> seems that people want it to be double-reported by default. If so, I think > >> we need to implement a command at the raw interface to allow disabling the > >> in-kernel decoder, while the raw interface is kept open. > > > > Why don't you simply let consumers decide where they will get their data? > > How? > You end up with N evdev devices. Let application (MythTV) say "I want to use /dev/input/event1" (well, it will need persistent udev rule, but that's a detail). Another application will chose another event node. User can decide she'd rather use lircd - and so configire applications to use event5. Any maybe turned off the in-kernel decoders if they are of no use and there is a concern that they consume too mcuh resoures. Won't this work? -- Dmitry -- 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?
On Tue, Dec 8, 2009 at 10:49 AM, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab writes: >> >>> If you use a kfifo to store the event (space_or_mark, timestamp), >>> the IRQ handler can return immediately, and a separate kernel thread >>> can do the decode without needing to touch at the IRQ. >> >> But the decoding itself is a really simple thing, why complicate it? >> There is no need for the kernel thread if the handler is fast (and it >> is). > > The decoding of just one protocol may be fast, but having several decoders > serialized (without kthreads, you're serializing the decoders) will possibly > not be that fast. > > Also, you don't need wake the decoders kthreads for every event, but wait Just wake the default kthread on each event. If you wake the default thread multiple times it is the same as waking it once. The default kthread doesn't schedule very fast. If you get 120 events and call wake 120 times, the thread is only going to visit your driver one or two times not 120 times. > for some number of events to happen before waking it. For example, > 16 pulse/space events correspond to 8 bits of data on most protocols, > so you can wake the kthread only after 16 events for really simple decoders, > or if a timeout event is detected. The number of events to wake may be > customized > per decoder. > > Cheers, > Mauro. > -- Jon Smirl jonsm...@gmail.com -- 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?
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> If you use a kfifo to store the event (space_or_mark, timestamp), >> the IRQ handler can return immediately, and a separate kernel thread >> can do the decode without needing to touch at the IRQ. > > But the decoding itself is a really simple thing, why complicate it? > There is no need for the kernel thread if the handler is fast (and it > is). The decoding of just one protocol may be fast, but having several decoders serialized (without kthreads, you're serializing the decoders) will possibly not be that fast. Also, you don't need wake the decoders kthreads for every event, but wait for some number of events to happen before waking it. For example, 16 pulse/space events correspond to 8 bits of data on most protocols, so you can wake the kthread only after 16 events for really simple decoders, or if a timeout event is detected. The number of events to wake may be customized per decoder. Cheers, Mauro. -- 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?
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> The enable/disable protocol decoder enable/disable interface is needed >> anyway, >> due to the needs for the hardware IR decoders > > Why do they need it exactly? > The key tables say all they need I hope? You can't upload a key for an unsupported protocol. Also, provided that hardware decoders in general don't support decoding multiple protocols at the same time, it is needed to select what protocol it will be decoding. So, userspace needs to: - retrieve the list of the supported protocols; - identify if a given IR is capable of multiple protocols; - be able to select what protocol(s) decoder(s) will be enabled. Cheers, Mauro. -- 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?
Mauro Carvalho Chehab writes: > If you use a kfifo to store the event (space_or_mark, timestamp), > the IRQ handler can return immediately, and a separate kernel thread > can do the decode without needing to touch at the IRQ. But the decoding itself is a really simple thing, why complicate it? There is no need for the kernel thread if the handler is fast (and it is). Userspace is obviously different. -- Krzysztof Halasa -- 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?
Mauro Carvalho Chehab writes: > The enable/disable protocol decoder enable/disable interface is needed anyway, > due to the needs for the hardware IR decoders Why do they need it exactly? The key tables say all they need I hope? -- Krzysztof Halasa -- 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?
Dmitry Torokhov writes: > No, the IR core responsible for registering receivers and decoders. Well. This makes me think now that LIRC can be just "another decoder". >> Those are simple things. The only part which needs to be stable is the >> (in this case LIRC) kernel-user interface. > > For which some questions are still open. I believe Jon just oulined some > of them. Those are rather "how does it work", not "let's change something because it's not optimal". > No we do not. We do not merge something that we expect to rework almost > completely (no, not the lirc-style device userspace inetrface, although > even it is not completely finalized I believe, but the rest of the > subsystem). I don't think we need to rework it almost completely. Perhaps we need to change a hook here or there. > No, not at all. You merge core subsystem code, then start addig > decoders... You must have at least one common decoder merged with the core code, otherwise you don't know if the core is adequate. And you have to have at least one common input device. But perhaps it is a workable idea after all, given the "another decoder". -- Krzysztof Halasa -- 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 wrote: > On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab > wrote: >> Jon Smirl wrote: >>> On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab >>> wrote: > Where is the documentation for the protocol? I'm not sure what you're meaning here. I've started a doc about IR at the media >>> What is the format of the pulse stream data coming out of the lirc device? >> AFAIK, it is at: >>http://www.lirc.org/html/index.html >> >> It would be nice to to add it to DocBook after integrating the API in kernel. >> > > The point of those design review questions was to illustrate that the > existing LIRC system is only partially designed. Ah, ok. > Subsystems need to be > fully designed before they get merged. True. > For example 36-40K and 56K IR signals are both in use. It is a simple > matter to design a receiver (or buy two receivers) that would support > both these frequencies. But the current LIRC model only supports a > single IR receiver. Adjusting it to support two receivers is going to > break the ABI. > > My choice would be to just tell the person with the 56K remote to just > buy a new 38K remote, but other people are against that choice. That > forces us into designing a system that can handle multiple receivers. > There is a parallel problem with baseband encoded IR signals. > > We need to think about all of these use cases before designing the > ABI. Only after we think we have a good ABI design should code start > being merged. Of course we may make mistakes and have to fix the ABI, > but there is nothing to be gained by merging the existing ABI if we > already know it has problems. I have here machines with 3 or 4 IR receivers (well, in a matter of fact, I don't use all of them at the same time). Nothing stops someone to use all IR receivers at the same. I've seen some interesting applications developed for students, where just one computer running Linux is splitted into 4 different consoles. Nothing stops that, on such usages, you may have 4 different IR transceivers working at the same time. In order to keep supporting the in-kernel drivers, we should create one lirc device per each IR transceiver. Cheers, Mauro. -- 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?
On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab writes: >> What is the interface for attaching an in-kernel decoder? >>> IMO, it should use the kfifo for it. However, if we allow both raw data and >>> in-kernel decoders to read data there, we'll need a spinlock to protect the >>> kfifo. >> >> This may be an option, but I think we should be able to attach protocol >> decoders in parallel, directly to the IRQ handler. At least with RC-5 >> (that's what I personally use) it means reliable decoding, no need for >> any timeouts, the code is clean, fast (can be a part of hard IRQ >> handler) and simple. >> >> The decoder needs something like >> rc5_signal_change(ptr, space_or_mark, microseconds). >> >> At least mark->space or space->mark events must be reported. For better >> reliability, both of them. > > If you use a kfifo to store the event (space_or_mark, timestamp), > the IRQ handler can return immediately, and a separate kernel thread > can do the decode without needing to touch at the IRQ. It also helps to > have a decoder independent of the kernel driver. The first version of my code ran the decoders from the IRQ. That wasn't a good model for sharing decoders between drivers. So I switched to using a kernel thread. There is also the problem of handing decoded events off up the chain. You can't do that from IRQ context. If I remember correctly the kernel thread would run approximately two times per IR message received. But sometimes it would only run once. It's a random function of the load on the system. The kernel thread empties the FIFO and sends the pulses in parallel to the decoders. Code for doing this is in the patches I posted. I wasn't aware of kfifo when I wrote them so I coded my own fifo. -- Jon Smirl jonsm...@gmail.com -- 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?
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> I don't think we need an userspace interface for the in-kernel >> decoders. > > Of course we need it, to set (and probably retrieve) scancode-keycode > mappings. This could probably be, ATM, the existing input layer channel. This is the standard/extended evdev interface already discussed. > >> All >> it needs is to enable/disable the protocol decoders, imo via sysfs interface. > > This isn't IMHO needed at all. The protocol is enabled when at least one > key using it is configured, otherwise it's disabled. We probably need > some "wildcard" as well, to capture decoded scancodes (through the input > layer). > This is BTW pure optimization, the protocol could stay enabled all the > time, only wasting the cycles. The enable/disable protocol decoder enable/disable interface is needed anyway, due to the needs for the hardware IR decoders (and the legacy IR decoders, while we don't convert all of them to the generic ones). So, IMO, the interface will be cleaner if we use it also for the generic IR decoders. Cheers, Mauro. -- 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?
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >>> What is the interface for attaching an in-kernel decoder? >> IMO, it should use the kfifo for it. However, if we allow both raw data and >> in-kernel decoders to read data there, we'll need a spinlock to protect the >> kfifo. > > This may be an option, but I think we should be able to attach protocol > decoders in parallel, directly to the IRQ handler. At least with RC-5 > (that's what I personally use) it means reliable decoding, no need for > any timeouts, the code is clean, fast (can be a part of hard IRQ > handler) and simple. > > The decoder needs something like > rc5_signal_change(ptr, space_or_mark, microseconds). > > At least mark->space or space->mark events must be reported. For better > reliability, both of them. If you use a kfifo to store the event (space_or_mark, timestamp), the IRQ handler can return immediately, and a separate kernel thread can do the decode without needing to touch at the IRQ. It also helps to have a decoder independent of the kernel driver. Cheers, Mauro. -- 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?
Mauro Carvalho Chehab writes: > Yes, an opaque type for scancode at the userspace API can be better, but > passing a pointer to kernel will require some compat32 logic (as pointer > size is different on 32 and 64 bits). Yes. I think we can't avoid that, but it's a single compat handler, I wouldn't worry about it too much. We don't need it in every driver fortunately. > We may use something like an u8[] with an arbitrary large number of > bytes. Yes. All of this pointed to by the pointer. > In this case, we need to take some care to avoid LSB/MSB troubles. Sure. -- Krzysztof Halasa -- 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?
Mauro Carvalho Chehab writes: > I don't think we need an userspace interface for the in-kernel > decoders. Of course we need it, to set (and probably retrieve) scancode-keycode mappings. This could probably be, ATM, the existing input layer channel. > All > it needs is to enable/disable the protocol decoders, imo via sysfs interface. This isn't IMHO needed at all. The protocol is enabled when at least one key using it is configured, otherwise it's disabled. We probably need some "wildcard" as well, to capture decoded scancodes (through the input layer). This is BTW pure optimization, the protocol could stay enabled all the time, only wasting the cycles. -- Krzysztof Halasa -- 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?
Dmitry Torokhov writes: > Why woudl we want to do this? Quite often there is a need for "observer" > that maybe does not act on data but allows capturing it. Single-user > inetrfaces are PITA. Lircd can work as a multiplexer. IMHO single-open lirc interface is ok, though we obviously need simultaneous operation of in-kernel decoders. -- Krzysztof Halasa -- 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 writes: > Data could be sent to the in-kernel decoders first and then if they > don't handle it, send it to user space. Nope. It should be sent to all of them, they aren't dependent. -- Krzysztof Halasa -- 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?
Mauro Carvalho Chehab writes: >> What is the interface for attaching an in-kernel decoder? > > IMO, it should use the kfifo for it. However, if we allow both raw data and > in-kernel decoders to read data there, we'll need a spinlock to protect the > kfifo. This may be an option, but I think we should be able to attach protocol decoders in parallel, directly to the IRQ handler. At least with RC-5 (that's what I personally use) it means reliable decoding, no need for any timeouts, the code is clean, fast (can be a part of hard IRQ handler) and simple. The decoder needs something like rc5_signal_change(ptr, space_or_mark, microseconds). At least mark->space or space->mark events must be reported. For better reliability, both of them. -- Krzysztof Halasa -- 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?
On Tue, Dec 8, 2009 at 6:17 AM, Mauro Carvalho Chehab wrote: > Jon Smirl wrote: >> On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab >> wrote: > Where is the documentation for the protocol? >>> I'm not sure what you're meaning here. I've started a doc about IR at the >>> media >> >> What is the format of the pulse stream data coming out of the lirc device? > > AFAIK, it is at: > http://www.lirc.org/html/index.html > > It would be nice to to add it to DocBook after integrating the API in kernel. > The point of those design review questions was to illustrate that the existing LIRC system is only partially designed. Subsystems need to be fully designed before they get merged. For example 36-40K and 56K IR signals are both in use. It is a simple matter to design a receiver (or buy two receivers) that would support both these frequencies. But the current LIRC model only supports a single IR receiver. Adjusting it to support two receivers is going to break the ABI. My choice would be to just tell the person with the 56K remote to just buy a new 38K remote, but other people are against that choice. That forces us into designing a system that can handle multiple receivers. There is a parallel problem with baseband encoded IR signals. We need to think about all of these use cases before designing the ABI. Only after we think we have a good ABI design should code start being merged. Of course we may make mistakes and have to fix the ABI, but there is nothing to be gained by merging the existing ABI if we already know it has problems. -- Jon Smirl jonsm...@gmail.com -- 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?
Dmitry Torokhov wrote: > On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote: >>> What about capabilities of the receiver, what frequencies? >>> If a receiver has multiple frequencies, how do you report what >>> frequency the data came in on? >> IMO, via sysfs. > > We probably need to think what exactly we report through sysfs siunce it > is ABI of sorts. Yes, sure. Probably, the exact needs will popup only when we start to actually writing that part of the core. My intention for now is to just create a /sys/class/irrcv, with one node per each IR receiver and adding a protocol enumeration/selection node there, and add some capabilities for the in-kernel decoders and lirc_dev to create new nodes under that class. When the decoders/lirc_dev patches popup, we'll need to review those sysfs API's. >>> What about multiple apps simultaneously using the pulse data? >> IMO, the better is to limit the raw interface to just one open. >> > > Why woudl we want to do this? Quite often there is a need for "observer" > that maybe does not act on data but allows capturing it. Single-user > inetrfaces are PITA. That should work fine as well, but I'm not sure how we'll detect overrun with several kfifo readers. >>> How big is the receive queue? >> It should be big enough to receive at least one keycode event. Considering >> that >> the driver will use kfifo (IMO, it is a good strategy, especially since you >> won't need any lock if just one open is allowed), it will require a power of >> two size. >> > > Would not it be wither driver- or protocol-specific? Probably. > >>> How does access work, root only or any user? >> IMO, it should be the same requirement as used by an input interface. >> >>> How are capabilities exposed, sysfs, etc? >> IMO, sysfs. >> >>> What is the interface for attaching an in-kernel decoder? >> IMO, it should use the kfifo for it. However, if we allow both raw data and >> in-kernel decoders to read data there, we'll need a spinlock to protect the >> kfifo. >> > > I think Jon meant userspace interface for attaching particular decoder. I don't think we need an userspace interface for the in-kernel decoders. All it needs is to enable/disable the protocol decoders, imo via sysfs interface. >>> If there is an in-kernel decoder should the pulse data stop being >>> reported, partially stopped, something else? >> I don't have a strong opinion here, but, from the previous discussions, it >> seems that people want it to be double-reported by default. If so, I think >> we need to implement a command at the raw interface to allow disabling the >> in-kernel decoder, while the raw interface is kept open. > > Why don't you simply let consumers decide where they will get their data? How? Cheers, Mauro. -- 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 wrote: > On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov > wrote: >> That is why I think we should go the other way around - introduce the >> core which receivers could plug into and decoder framework and once it >> is ready register lirc-dev as one of the available decoders. > > The core needs to allow for RF remotes too. > > -Bluetooth remotes are already in kernel somehow, I don't know how they work, > -RF4CE, the 802.15.4 stack has been recently merged, the remotes use a > protocol on top of that. These remotes will hit the consumer market > next year. Sony, Panasonic and other big names are behind this. > -Zwave, the Harmony remotes use Zwave. There is no Zwave support in > the kernel that I am aware of. Zwave is proprietary. > > After these protocols are decoded you end up with scancodes. The > scancodes need to get injected into input somehow and then flow > through the mapping process. Decoding down to the scancodes probably > happens over in the networking code. > > After an in-kernel IR decoder runs it needs to hand off the scancodes > into the input subsystem. This same API can be used by the networking > code to hand off RF scancodes. > Yes, the same core should be able to work with non infra red remotes, but, depending on how the device is implemented. Cheers, Mauro. -- 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 wrote: > On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab > wrote: >>> Where is the documentation for the protocol? >> I'm not sure what you're meaning here. I've started a doc about IR at the >> media > > What is the format of the pulse stream data coming out of the lirc device? AFAIK, it is at: http://www.lirc.org/html/index.html It would be nice to to add it to DocBook after integrating the API in kernel. >> docbook. This is currently inside the kernel Documents/DocBook. If you want >> to browse, it is also available as: >> >>http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html >> >> For sure we need to better document the IR's, and explain the API's there. >> >>> Is it a device interface or something else? >> lirc_dev should create a device interface. >> >>> What about capabilities of the receiver, what frequencies? >>> If a receiver has multiple frequencies, how do you report what >>> frequency the data came in on? >> IMO, via sysfs. > > Say you have a hardware device with two IR diodes, one at 38K and one > at 56K. Both of these receivers can get pulses. How do we tell the > user space app which frequency the pulses were received on? Seems to > me like there has to be a header on the pulse data indicating the > received carrier frequency. There is also baseband signaling. sysfs > won't work for this because of the queuing latency. Simply create two interfaces. One for each IR receiver. At sysfs, you'll have /sys/class/irrcv/irrcv0 for the first one and /sys/class/irrcv/irrcv1. > > How is over-run signaled to the app? You'd get an over-run if the app > is too slow at reading the data out of the FIFO. If you ignore > over-run you'll be processing bad data because part of the message was > lost. An over-run signal tell the abort to abort the signal and start > over. The API should provide that info. Maybe it is already solved. >>> What about multiple apps simultaneously using the pulse data? >> IMO, the better is to limit the raw interface to just one open. >> >>> How big is the receive queue? >> It should be big enough to receive at least one keycode event. Considering >> that >> the driver will use kfifo (IMO, it is a good strategy, especially since you >> won't need any lock if just one open is allowed), it will require a power of >> two size. > > How is end of a pulse train detected? timeout? without decoding the > protocol there is no way to tell the end of signal other than timeout. The API should provide that info. Provided that lirc works, I'm assuming that this is already solved. >>> How does access work, root only or any user? >> IMO, it should be the same requirement as used by an input interface. >> >>> How are capabilities exposed, sysfs, etc? >> IMO, sysfs. >> >>> What is the interface for attaching an in-kernel decoder? >> IMO, it should use the kfifo for it. However, if we allow both raw data and >> in-kernel decoders to read data there, we'll need a spinlock to protect the >> kfifo. >> >>> If there is an in-kernel decoder should the pulse data stop being >>> reported, partially stopped, something else? >> I don't have a strong opinion here, but, from the previous discussions, it >> seems that people want it to be double-reported by default. If so, I think >> we need to implement a command at the raw interface to allow disabling the >> in-kernel decoder, while the raw interface is kept open. > > Data could be sent to the in-kernel decoders first and then if they > don't handle it, send it to user space. Hmm... like adding a delay if the raw userspace is open and, if the raw userspace doesn't read all pulse data, it will send via in-kernel decoder instead? This can work, but I'm not sure if this is the better way, and will require some logic to synchronize lirc_dev and IR core modules. Also, doing it key by key will introduce some delay. If you're afraid of having the userspace app hanged and having no IR output, it would be simpler to just close the raw interface if an available data won't be read after a bigger timeout (3 seconds? 5 seconds?). Cheers, Mauro. -- 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?
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] What are the goals for the architecture of an in-kernel IR system?
On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote: > Let me add my view for those questions. > > Jon Smirl wrote: > > On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote: > >> Jon Smirl writes: > >> > Once again: how about agreement about the LIRC interface > (kernel-userspace) and merging the actual LIRC code first? In-kernel > decoding can wait a bit, it doesn't change any kernel-user interface. > >>> I'd like to see a semi-complete design for an in-kernel IR system > >>> before anything is merged from any source. > >> This is a way to nowhere, there is no logical dependency between LIRC > >> and input layer IR. > >> > >> There is only one thing which needs attention before/when merging LIRC: > >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, > >> actually, making a correct IR core design without the LIRC merged can be > >> only harder. > > > > Here's a few design review questions on the LIRC drivers that were > > posted > > > > How is the pulse data going to be communicated to user space? > > lirc_dev will implement a revised version of the lirc API. I'm assuming that > Jerod and Christoph will do this review, in order to be sure that it is stable > enough for kernel inclusion (as proposed by Gerd). > > > Can the pulse data be reported via an existing interface without > > creating a new one? > > Raw pulse data should be reported only via lirc_dev, but it can be converted > into a keycode and reported via evdev as well, via an existing interface. > > > Where is the documentation for the protocol? > > I'm not sure what you're meaning here. I've started a doc about IR at the > media > docbook. This is currently inside the kernel Documents/DocBook. If you want > to browse, it is also available as: > > http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html > > For sure we need to better document the IR's, and explain the API's there. > > > Is it a device interface or something else? > > lirc_dev should create a device interface. > > > What about capabilities of the receiver, what frequencies? > > If a receiver has multiple frequencies, how do you report what > > frequency the data came in on? > > IMO, via sysfs. We probably need to think what exactly we report through sysfs siunce it is ABI of sorts. > > > What about multiple apps simultaneously using the pulse data? > > IMO, the better is to limit the raw interface to just one open. > Why woudl we want to do this? Quite often there is a need for "observer" that maybe does not act on data but allows capturing it. Single-user inetrfaces are PITA. > > How big is the receive queue? > > It should be big enough to receive at least one keycode event. Considering > that > the driver will use kfifo (IMO, it is a good strategy, especially since you > won't need any lock if just one open is allowed), it will require a power of > two size. > Would not it be wither driver- or protocol-specific? > > How does access work, root only or any user? > > IMO, it should be the same requirement as used by an input interface. > > > How are capabilities exposed, sysfs, etc? > > IMO, sysfs. > > > What is the interface for attaching an in-kernel decoder? > > IMO, it should use the kfifo for it. However, if we allow both raw data and > in-kernel decoders to read data there, we'll need a spinlock to protect the > kfifo. > I think Jon meant userspace interface for attaching particular decoder. > > If there is an in-kernel decoder should the pulse data stop being > > reported, partially stopped, something else? > > I don't have a strong opinion here, but, from the previous discussions, it > seems that people want it to be double-reported by default. If so, I think > we need to implement a command at the raw interface to allow disabling the > in-kernel decoder, while the raw interface is kept open. Why don't you simply let consumers decide where they will get their data? > > > What is the mechanism to make sure both system don't process the same > > pulses? > > I don't see a good way to avoid it. > > > Does it work with poll, epoll, etc? > > What is the time standard for the data, where does it come from? > > How do you define the start and stop of sequences? > > Is receiving synchronous or queued? > > What about transmit, how do you get pulse data into the device? > > Transmitter frequencies? > > Multiple transmitters? > > Is transmitting synchronous or queued? > > How big is the transmit queue? > > I don't have a clear answer for those. I'll let those to LIRC developers to > answer. > -- Dmitry -- 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?
On Sun, 2009-12-06 at 16:23 -0500, Jon Smirl wrote: > On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote: > > Jon Smirl writes: > > > >>> Once again: how about agreement about the LIRC interface > >>> (kernel-userspace) and merging the actual LIRC code first? In-kernel > >>> decoding can wait a bit, it doesn't change any kernel-user interface. > >> > >> I'd like to see a semi-complete design for an in-kernel IR system > >> before anything is merged from any source. > > > > This is a way to nowhere, there is no logical dependency between LIRC > > and input layer IR. > > > > There is only one thing which needs attention before/when merging LIRC: > > the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, > > actually, making a correct IR core design without the LIRC merged can be > > only harder. > > Here's a few design review questions on the LIRC drivers that were posted I will answer based on my understanding of LIRC as it exists today, but I'm tired and am not going to dig into too many details I can't find easily. (Christoph can correct me if I get anything wrong.) An architecture drawing can be found here: http://www.lirc.org/html/technical.html > How is the pulse data going to be communicated to user space? Currently that is via lirc_dev which shows up as /dev/lircN (IIRC) in userspace. "The lirc_dev module is a helper and abstraction layer for other modules. It registers /dev/lirc device in a system (including support for devfs) and waits for plugin registration. After that it serves device requests (open, read, poll, ioctl, close) and if needed calls callback functions from plugin(s) to communicate with the physical device." The function call for hardware drivers to register with lirc_dev from within kernel space is lirc_register_driver() which requires a structure with points to hardware specifi operations, IIRC. > Can the pulse data be reported via an existing interface without > creating a new one? Yes. > Where is the documentation for the protocol? http://www.lirc.org/html/technical.html > Is it a device interface or something else? Device for a kernelspace driver/plugin registering with lirc_dev. > Does it work with poll, epoll, etc? lirc_dev has an function irctl_poll() that will call a hardware specifi poll operation if it exists, otherwise it has default poll logic. > What is the time standard for the data, where does it come from? I think it is usec, IIRC. I know that the hardware I work with has sub 100 ns resolution, so that's what is used as the basis for v4l2_subdev_ir_ops time values in kernel. The conversion to usec is rather trivial. The hardware I work with is very configurable, but I always use the BT.656 video pixel clock of of 13.5 MHz * 8 = 108 MHz as the master frequency reference for all the pulse width measurement circuitry. > How do you define the start and stop of sequences? For the end of Rx signalling: Well with the Conexant hardware I can set a maximum pulse (mark or space) width, and the hardware will generate an Rx Timeout interrupt to signal the end of Rx when a space ends up longer than that max pulse width. The hardware also puts a special marker in the hardware pulse widht measurement FIFO (in band signalling essentially). I'm not sure anything like that gets communicated to userspace via lirc_dev, and I'm too tired to doublecheck right now. If you have determined the protocol you are after, it's easy to know what the pulse count should be and what the max pulse width should be (+ slop for crappy hardware) so finding the end of an Rx isn't hard. The button repeats intervals are *very* large. I've never seen a remote rapid fire codes back to back. For the start of a sequence: Easy, the first mark after a *very* long (10's of msec) space. You could also look for very long mark header which many protocols (NEC, RC-6, ...) have to help the IR hardware's AGC get set. > What about capabilities of the receiver, what frequencies? LIRC's API has a LIRC_GET_FEATURES ioctl(). > If a receiver has multiple frequencies, how do you report what > frequency the data came in on? I'm not sure most hardware can pick up a pulse on an arbitrary freq. Usually you set a desired carrier and a window. The windows can be very generous on some hardware: Fc * 16/20 to Fc * 16/12 (e.g. for 38 kHz that's 30.4 kHz to 50.667 kHz). Hardware can have a special "learn mode" to really make fine measurements about the waveform without a specified carrier, but usually requires some special setup and the user being prompted to take action to get a good measurement. > What about multiple apps simultaneously using the pulse data? LIRC multiplexes a single device node with a daemon in userspace. > Is receiving synchronous or queued? kfifo's in lirc_dev IIRC. > How big is the receive queue? Device HW FIFO's can have a depth of 1 to 16. My software queues for CX2388[58] devices are 512 pulse measurments deep -- overkill exc
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov wrote: > That is why I think we should go the other way around - introduce the > core which receivers could plug into and decoder framework and once it > is ready register lirc-dev as one of the available decoders. The core needs to allow for RF remotes too. -Bluetooth remotes are already in kernel somehow, I don't know how they work, -RF4CE, the 802.15.4 stack has been recently merged, the remotes use a protocol on top of that. These remotes will hit the consumer market next year. Sony, Panasonic and other big names are behind this. -Zwave, the Harmony remotes use Zwave. There is no Zwave support in the kernel that I am aware of. Zwave is proprietary. After these protocols are decoded you end up with scancodes. The scancodes need to get injected into input somehow and then flow through the mapping process. Decoding down to the scancodes probably happens over in the networking code. After an in-kernel IR decoder runs it needs to hand off the scancodes into the input subsystem. This same API can be used by the networking code to hand off RF scancodes. -- Jon Smirl jonsm...@gmail.com -- 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?
On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab wrote: > Let me add my view for those questions. > > Jon Smirl wrote: >> On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote: >>> Jon Smirl writes: >>> > Once again: how about agreement about the LIRC interface > (kernel-userspace) and merging the actual LIRC code first? In-kernel > decoding can wait a bit, it doesn't change any kernel-user interface. I'd like to see a semi-complete design for an in-kernel IR system before anything is merged from any source. >>> This is a way to nowhere, there is no logical dependency between LIRC >>> and input layer IR. >>> >>> There is only one thing which needs attention before/when merging LIRC: >>> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, >>> actually, making a correct IR core design without the LIRC merged can be >>> only harder. >> >> Here's a few design review questions on the LIRC drivers that were posted >> >> How is the pulse data going to be communicated to user space? > > lirc_dev will implement a revised version of the lirc API. I'm assuming that > Jarod and Christoph will do this review, in order to be sure that it is stable > enough for kernel inclusion (as proposed by Gerd). > >> Can the pulse data be reported via an existing interface without >> creating a new one? > > Raw pulse data should be reported only via lirc_dev, but it can be converted > into a keycode and reported via evdev as well, via an existing interface. > >> Where is the documentation for the protocol? > > I'm not sure what you're meaning here. I've started a doc about IR at the > media What is the format of the pulse stream data coming out of the lirc device? > docbook. This is currently inside the kernel Documents/DocBook. If you want > to browse, it is also available as: > > http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html > > For sure we need to better document the IR's, and explain the API's there. > >> Is it a device interface or something else? > > lirc_dev should create a device interface. > >> What about capabilities of the receiver, what frequencies? >> If a receiver has multiple frequencies, how do you report what >> frequency the data came in on? > > IMO, via sysfs. Say you have a hardware device with two IR diodes, one at 38K and one at 56K. Both of these receivers can get pulses. How do we tell the user space app which frequency the pulses were received on? Seems to me like there has to be a header on the pulse data indicating the received carrier frequency. There is also baseband signaling. sysfs won't work for this because of the queuing latency. How is over-run signaled to the app? You'd get an over-run if the app is too slow at reading the data out of the FIFO. If you ignore over-run you'll be processing bad data because part of the message was lost. An over-run signal tell the abort to abort the signal and start over. >> What about multiple apps simultaneously using the pulse data? > > IMO, the better is to limit the raw interface to just one open. > >> How big is the receive queue? > > It should be big enough to receive at least one keycode event. Considering > that > the driver will use kfifo (IMO, it is a good strategy, especially since you > won't need any lock if just one open is allowed), it will require a power of > two size. How is end of a pulse train detected? timeout? without decoding the protocol there is no way to tell the end of signal other than timeout. > >> How does access work, root only or any user? > > IMO, it should be the same requirement as used by an input interface. > >> How are capabilities exposed, sysfs, etc? > > IMO, sysfs. > >> What is the interface for attaching an in-kernel decoder? > > IMO, it should use the kfifo for it. However, if we allow both raw data and > in-kernel decoders to read data there, we'll need a spinlock to protect the > kfifo. > >> If there is an in-kernel decoder should the pulse data stop being >> reported, partially stopped, something else? > > I don't have a strong opinion here, but, from the previous discussions, it > seems that people want it to be double-reported by default. If so, I think > we need to implement a command at the raw interface to allow disabling the > in-kernel decoder, while the raw interface is kept open. Data could be sent to the in-kernel decoders first and then if they don't handle it, send it to user space. > >> What is the mechanism to make sure both system don't process the same pulses? > > I don't see a good way to avoid it. > >> Does it work with poll, epoll, etc? >> What is the time standard for the data, where does it come from? >> How do you define the start and stop of sequences? >> Is receiving synchronous or queued? >> What about transmit, how do you get pulse data into the device? >> Transmitter frequencies? >> Multiple transmitters? >> Is transmitting synchronous or queued? >> How big is the transmit queue? > > I don't have a clear answer fo
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> struct input_keytable_entry {
>> u16 index;
>> u64 scancode;
>> u32 keycode;
>> } __attribute__ ((packed));
>>
>> (the attribute packed avoids needing a compat for 64 bits)
>
> Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
> bit better, no alignment problems and we could eventually change
> "reserved" into something useful.
>
> But I think, if we are going to redesign it, we better use scancodes of
> arbitrary length (e.g. protocol-dependent length). It should be opaque
> except for the protocol handler.
Yes, an opaque type for scancode at the userspace API can be better, but
passing a pointer to kernel will require some compat32 logic (as pointer
size is different on 32 and 64 bits).
We may use something like an u8[] with an arbitrary large number of bytes.
In this case, we need to take some care to avoid LSB/MSB troubles.
Cheers,
Mauro.
--
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?
Christoph Bartelmus wrote: > Hi Jon, > > on 04 Dec 09 at 19:28, Jon Smirl wrote: >>> BTW, I just came across a XMP remote that seems to generate 3x64 bit >>> scan codes. Anyone here has docs on the XMP protocol? >> Assuming a general purpose receiver (not one with fixed hardware >> decoding), is it important for Linux to receive IR signals from all >> possible remotes no matter how old or obscure? Or is it acceptable to > [...] >> Of course transmitting is a completely different problem, but we >> haven't been talking about transmitting. I can see how we would need >> to record any IR protocol in order to retransmit it. But that's in the >> 5% of users world, not the 90% that want MythTV to "just work". Use >> something like LIRC if you want to transmit. > > I don't think anyone here is in the position to be able to tell what is > 90% or 5%. True. Yet, cases like IR devices made by someone's own use is something that we don't need to care to have an in-kernel driver. > Personally I use LIRC exclusively for transmit to my settop box > using an old and obscure RECS80 protocol. > No, I won't replace my setup just because it's old and obscure. > > Cable companies tend to provide XMP based boxes to subscribers more often > these days. Simply not supporting these setups is a no-go for me. I don't see any reason why not supporting STB protocols. Several such hardware use Linux, anyway. So, eventually the STB manufacturers may send us decoders that work with their IR's. Cheers, Mauro. -- 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?
Let me add my view for those questions. Jon Smirl wrote: > On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote: >> Jon Smirl writes: >> Once again: how about agreement about the LIRC interface (kernel-userspace) and merging the actual LIRC code first? In-kernel decoding can wait a bit, it doesn't change any kernel-user interface. >>> I'd like to see a semi-complete design for an in-kernel IR system >>> before anything is merged from any source. >> This is a way to nowhere, there is no logical dependency between LIRC >> and input layer IR. >> >> There is only one thing which needs attention before/when merging LIRC: >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, >> actually, making a correct IR core design without the LIRC merged can be >> only harder. > > Here's a few design review questions on the LIRC drivers that were posted > > How is the pulse data going to be communicated to user space? lirc_dev will implement a revised version of the lirc API. I'm assuming that Jerod and Christoph will do this review, in order to be sure that it is stable enough for kernel inclusion (as proposed by Gerd). > Can the pulse data be reported via an existing interface without > creating a new one? Raw pulse data should be reported only via lirc_dev, but it can be converted into a keycode and reported via evdev as well, via an existing interface. > Where is the documentation for the protocol? I'm not sure what you're meaning here. I've started a doc about IR at the media docbook. This is currently inside the kernel Documents/DocBook. If you want to browse, it is also available as: http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html For sure we need to better document the IR's, and explain the API's there. > Is it a device interface or something else? lirc_dev should create a device interface. > What about capabilities of the receiver, what frequencies? > If a receiver has multiple frequencies, how do you report what > frequency the data came in on? IMO, via sysfs. > What about multiple apps simultaneously using the pulse data? IMO, the better is to limit the raw interface to just one open. > How big is the receive queue? It should be big enough to receive at least one keycode event. Considering that the driver will use kfifo (IMO, it is a good strategy, especially since you won't need any lock if just one open is allowed), it will require a power of two size. > How does access work, root only or any user? IMO, it should be the same requirement as used by an input interface. > How are capabilities exposed, sysfs, etc? IMO, sysfs. > What is the interface for attaching an in-kernel decoder? IMO, it should use the kfifo for it. However, if we allow both raw data and in-kernel decoders to read data there, we'll need a spinlock to protect the kfifo. > If there is an in-kernel decoder should the pulse data stop being > reported, partially stopped, something else? I don't have a strong opinion here, but, from the previous discussions, it seems that people want it to be double-reported by default. If so, I think we need to implement a command at the raw interface to allow disabling the in-kernel decoder, while the raw interface is kept open. > What is the mechanism to make sure both system don't process the same pulses? I don't see a good way to avoid it. > Does it work with poll, epoll, etc? > What is the time standard for the data, where does it come from? > How do you define the start and stop of sequences? > Is receiving synchronous or queued? > What about transmit, how do you get pulse data into the device? > Transmitter frequencies? > Multiple transmitters? > Is transmitting synchronous or queued? > How big is the transmit queue? I don't have a clear answer for those. I'll let those to LIRC developers to answer. Cheers, Mauro -- 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?
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, Yeah, I added the protocol type info inside the internal representation of the IR table. As I managed to do all the work inside one file (ir-keytable.c), changing it to use arbitrary sized scancode lengths will be trivial (currently, it is u16 just because just because it currently enough for the in-kernel drivers, but this will be changed when integrating with lirc): http://linuxtv.org/hg/v4l-dvb/rev/7b983cd30f0f > allowing us to define new ioctl and new ways to > efficiently store and manage sparse scancode spaces (tree, hashtable > ). 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. True. > 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. Yes. By purpose, I added IR_TYPE_UNKNOWN as 0. This way, all tables that don't specify a protocol can be considered legacy. Cheers, Mauro. -- 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?
Dmitry Torokhov wrote: > On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote: >> >>> Scancodes in input system never been real scancodes. Even if you look >>> into atkbd it uses some synthetic data composed out of real scancodes >>> sent to the keyboard, and noone cares. If you are unsatisfied with >>> mapping you fire up evtest, press the key, take whatever the driver >>> [mis]represents as a scancode and use it to load the new definition. And >>> you don't care at all whether the thing that driver calls cancode makes >>> any sense to the hardware device. >> We used a mis-represented scancode, but this proofed to be a broken design >> along the time. >> >> For users, whatever the scancode "cookie" means, the same IR device should >> provide the same "cookie" no matter what IR receiver is used, since the same >> IR may be found on different devices, or the user can simply buy a new card >> and opt to use their old IR (there are very good reasons for that, since >> several new devices are now coming with small IR's that has half of the >> keys of the ones available at the older models). > > OK, this is a fair point. We need to keep the "scancodes" stable across > receivers. > > However I am not sure if the "index" approach is the best - it will not > work well if driver decides to implement the keymap using data structure > different from array, let's say linked list or a hash table. Lists by > their nature do not have a stable index and even if we were to generate > one "on fly" we could not rely on it for subsequent EVIOSKEYCODE: some > other program may cause insertion or deletion of an element making the > artificial index refer to another entry in the map. Any addition/deletion of an element will cause problems, even with a simple table. I don't think we should consider a case where two applications are changing the table at the same time. The end result will likely be different than what's expected anyway. Btw, while an index for EVIOGSKEYCODE is really important, except for symmetry, there are no other reasons why we can't use scancode as the primary key for EVIOSKEYCODE. We can't allow two identical scancodes anyway at the scancode/keycode table. So, we can define the EVIOSKEYCODE without an index. > While extending scancode size is pretty straightforward (well, almost > ;) ) I am not sure what is the best way to enumerate keymap for a given > device. > Btw, if you want to take a look, I've finished to implement the table insert/delete logic. Extending/reducing space at the table required some care, but it is working fine: http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=87d73cbd33235b162e8da62305ba8b5926a1fbf8 The code is not optimized by using a hash table or a binary search yet (patches to improve are welcome), but it is already working as expected. Cheers, Mauro. -- 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?
On Mon, Dec 07, 2009 at 09:08:57PM +0100, Krzysztof Halasa wrote: > Dmitry Torokhov writes: > > >> There is only one thing which needs attention before/when merging LIRC: > >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, > >> actually, making a correct IR core design without the LIRC merged can be > >> only harder. > > > > This sounds like "merge first, think later"... > > I'd say "merge the sane agreed and stable things first and think later > about improvements". > > > The question is why we need to merge lirc interface right now, before we > > agreed on the sybsystem architecture? > > Because we need the features and we can't improve something which is > outside the kernel. What "subsystem architecture" do you want to > discuss? Unrelated (input layer) interface? > No, the IR core responsible for registering receivers and decoders. > Those are simple things. The only part which needs to be stable is the > (in this case LIRC) kernel-user interface. For which some questions are still open. I believe Jon just oulined some of them. > > > Noone _in kernel_ user lirc-dev > > yet and, looking at the way things are shaping, no drivers will be > > _directly_ using it after it is complete. So, even if we merge it right > > away, the code will have to be restructured and reworked. > > Sure. We do this constantly to every part of the kernel. No we do not. We do not merge something that we expect to rework almost completely (no, not the lirc-style device userspace inetrface, although even it is not completely finalized I believe, but the rest of the subsystem). > > > Unfortunately, > > just merging what Jarod posted, will introduce sysfs hierarchy which > > is userspace interface as well (although we not as good maintaining it > > at times) and will add more constraints on us. > > Then perhaps it should be skipped, leaving only the things udev needs to > create /dev/ entries. They don't have to be particularly stable. > Perhaps it should go to the staging first. We can't work with the code > outside the kernel, staging has not such limitation. OK, say we add this to staging as is. What is next? Who will be using this code that is now in staging? Do we encougrage driver's writers to hook into it (given that we intend on redoing it soon)? Do something else? > > > That is why I think we should go the other way around - introduce the > > core which receivers could plug into and decoder framework and once it > > is ready register lirc-dev as one of the available decoders. > > That means all the work has to be kept and then merged "atomically", > it seems there is a lack of manpower for this. No, not at all. You merge core subsystem code, then start addig decoders... In the meantime driver-writers could start preparing their drivers to plug into it. In the mean time out-of-tree LIRC can be used by consumers undisturbed. -- Dmitry -- 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?
Dmitry Torokhov writes: >> There is only one thing which needs attention before/when merging LIRC: >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, >> actually, making a correct IR core design without the LIRC merged can be >> only harder. > > This sounds like "merge first, think later"... I'd say "merge the sane agreed and stable things first and think later about improvements". > The question is why we need to merge lirc interface right now, before we > agreed on the sybsystem architecture? Because we need the features and we can't improve something which is outside the kernel. What "subsystem architecture" do you want to discuss? Unrelated (input layer) interface? Those are simple things. The only part which needs to be stable is the (in this case LIRC) kernel-user interface. > Noone _in kernel_ user lirc-dev > yet and, looking at the way things are shaping, no drivers will be > _directly_ using it after it is complete. So, even if we merge it right > away, the code will have to be restructured and reworked. Sure. We do this constantly to every part of the kernel. > Unfortunately, > just merging what Jarod posted, will introduce sysfs hierarchy which > is userspace interface as well (although we not as good maintaining it > at times) and will add more constraints on us. Then perhaps it should be skipped, leaving only the things udev needs to create /dev/ entries. They don't have to be particularly stable. Perhaps it should go to the staging first. We can't work with the code outside the kernel, staging has not such limitation. > That is why I think we should go the other way around - introduce the > core which receivers could plug into and decoder framework and once it > is ready register lirc-dev as one of the available decoders. That means all the work has to be kept and then merged "atomically", it seems there is a lack of manpower for this. -- Krzysztof Halasa -- 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?
On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote: > Jon Smirl writes: > > >> Once again: how about agreement about the LIRC interface > >> (kernel-userspace) and merging the actual LIRC code first? In-kernel > >> decoding can wait a bit, it doesn't change any kernel-user interface. > > > > I'd like to see a semi-complete design for an in-kernel IR system > > before anything is merged from any source. > > This is a way to nowhere, there is no logical dependency between LIRC > and input layer IR. > > There is only one thing which needs attention before/when merging LIRC: > the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, > actually, making a correct IR core design without the LIRC merged can be > only harder. This sounds like "merge first, think later"... The question is why we need to merge lirc interface right now, before we agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev yet and, looking at the way things are shaping, no drivers will be _directly_ using it after it is complete. So, even if we merge it right away, the code will have to be restructured and reworked. Unfortunately, just merging what Jarod posted, will introduce sysfs hierarchy which is userspace interface as well (although we not as good maintaining it at times) and will add more constraints on us. That is why I think we should go the other way around - introduce the core which receivers could plug into and decoder framework and once it is ready register lirc-dev as one of the available decoders. -- Dmitry -- 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?
On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote: > > > Scancodes in input system never been real scancodes. Even if you look > > into atkbd it uses some synthetic data composed out of real scancodes > > sent to the keyboard, and noone cares. If you are unsatisfied with > > mapping you fire up evtest, press the key, take whatever the driver > > [mis]represents as a scancode and use it to load the new definition. And > > you don't care at all whether the thing that driver calls cancode makes > > any sense to the hardware device. > > We used a mis-represented scancode, but this proofed to be a broken design > along the time. > > For users, whatever the scancode "cookie" means, the same IR device should > provide the same "cookie" no matter what IR receiver is used, since the same > IR may be found on different devices, or the user can simply buy a new card > and opt to use their old IR (there are very good reasons for that, since > several new devices are now coming with small IR's that has half of the > keys of the ones available at the older models). OK, this is a fair point. We need to keep the "scancodes" stable across receivers. However I am not sure if the "index" approach is the best - it will not work well if driver decides to implement the keymap using data structure different from array, let's say linked list or a hash table. Lists by their nature do not have a stable index and even if we were to generate one "on fly" we could not rely on it for subsequent EVIOSKEYCODE: some other program may cause insertion or deletion of an element making the artificial index refer to another entry in the map. While extending scancode size is pretty straightforward (well, almost ;) ) I am not sure what is the best way to enumerate keymap for a given device. -- Dmitry -- 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?
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 ). 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. 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] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: > On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa wrote: >> Once again: how about agreement about the LIRC interface >> (kernel-userspace) and merging the actual LIRC code first? That's fine for me. >> In-kernel >> decoding can wait a bit, it doesn't change any kernel-user interface. This may occur in parallel, but, as we've been discussing, there are still some needs there that will require kernel-user interfaces. > I'd like to see a semi-complete design for an in-kernel IR system > before anything is merged from any source. There are some tasks there that are independent of any API design. For example, I'm currently doing some cleanups and improvements at the existing IR in-kernel code to create a common IR core that replaces the already existing feature of handling 7-bits scancode/keycode table to use the complete scancodes found at the current in-kernel drivers. This approach works for the current drivers, as none of them currently support any protocol that requires more than 16 bits for scancodes. However, the current EVIOGKEYCODE implementation won't scale with bigger scancode spaces. This code is written to be generic enough to be used by V4L, DVB and LIRC drivers. So, after having this work done, it should be easy to connect the lirc_dev to a decoder and to this core support. There are already some in-kernel decoders that can be used for some protocols, but the better is to review the decoders in the light of lirc. I expect that the lirc decoders will be in a better shape. While I'm here, I intend also to create the sysfs bits to create sys/class/irrcv, as already discussed and submit the patch here for discussions. Of course, after writing different API's to control the IR tables, we'll need to improve it, but this depends on the results of the architecture discussions. Cheers, Mauro -- 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?
Dmitry Torokhov wrote:
> On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
>> Dmitry Torokhov wrote:
>>> On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
Em Fri, 4 Dec 2009 02:06:42 -0800
Dmitry Torokhov escreveu:
> evdev does not really care what you use as scancode. So nobody stops
> your driver to report index as a scancode and accept index from the
> ioctl. The true "scancode" will thus be competely hidden from userspace.
> In fact a few drivers do just that.
Let me better express here. It is all about how we'll expand the limits of
those
ioctls to fulfill the needs.
The point is that we'll have, let's say something like to 50-500
scancode/keycode tuples
sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure
if is there any
IR protocol/code with a bigger scancode).
On such universe if we want to get all keycodes with the current ioctls
for a scancode in
the range of 32 bits, we need to do something like:
u32 code;
int codes[2];
for (code = 0; code <= (unsigned u32) - 1; code++) {
codes[0] = (int)code;
if (!ioctl(fd, EVIOCGKEYCODE, codes))
printf("scancode 0x%08x = keycode 0x%08x\n", codes[0],
codes[1]);
}
So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE
ioctl to
read the complete scancode space, to get those 50-500 useful codes.
>>> Right, currently there is no need to query all scancodes defined by
>>> device. Quite often drivers don't even know what scancodes device
>>> actually generates (ex AT keyboard).
>>>
>>> Could you describe in more detail how you are using this data?
>> It is useful if you want to dump the keycode maps into file with the current
>> scancode attribution, in order to modify some keystrokes.
>>
>> Right now, programs like dumpkeys (from kbd package) allow you to dump for
>> example
>> the attribution keys from your keyboard.
>>
>> In the case of IR's this functionality is very important.
>>
>> For example, you may need to replace the scancode/KEY_CHANNELUP tuple by
>> scancode/KEY_UP,
>> in order to make your IR to work with some applications that don't recognize
>> the IR
>> specific keycodes.
>>
>> In practice, with such applications, you'll need to replace several
>> different scancodes.
>>
>> So, you may end by having different scancodes producing the same keycode, as
>> such applications
>> aren't capable of differentiating an UP key from a CHANNELUP key. This is
>> the case, for example
>> of the popular tvtime application.
>>
>> The better way is to just generate a dump file, modify the needed entries
>> and reload the
>> table by calling EVIOSKEYCODE, in order to use the new table.
>>
>> I wrote a small application that just do the above, and I use to load some
>> special tables
>> to work with some applications like tvtime and mplayer. (with mplayer, you
>> need to map
>> as KEY_H and as KEY_K).
>>
>> I hope that, after we finish addressing IR's, we'll finally have media
>> applications handling
>> directly the proper keycodes, but people may still need to write different
>> keycodes to do
>> other things. I used to have a keymap file in order to use an IR to control
>> the slide show
>> with openoffice.
>>
Due to the current API limit, we don't have any way to use the full 64bits
space for scancodes.
>>> Can we probably reduce the "scancode" space? ARe all 64 bits in
>>> protocols used to represent keypresses or some are used for some kind of
>>> addressing?
>> All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for
>> NEC extended protocol).
>> However, currently, the drivers were getting only 7 bits, due to the old way
>> to implement
>> EVIO[S|G]KEYCODE.
>>
>> I know, however, one i2c chip that returns a 5 byte scancode when you press
>> a key.
>> We're currently just discarding the remaining bits, so I'm not really sure
>> what's there.
>>
>>
>> The usage of 7 bits, in practice, were meaning that it weren't possible to
>> use
>> a different remote than the one provided by the device manufacturer, as the
>> scancodes produced
>> by other remotes differ on more than 7 bits. Also, this means that, if your
>> TV and your PC
>> are using the same protocol, like RC5, if you press a button on your TV
>> remote, the PC will
>> also get it.
>>
>> I know, however, one IR driver that produces 6 bytes when you press a key.
>> We're currently just discarding the remaining bits, so I'm not really sure
>> what else is there. Some badly optimized protocol? a bigger scancode? a
>> protocol indication?
>>
>> In general, the scancode contains 8 or 16 bits for address, and 8 bits for
>> command.
>>
>> However, the scancode table needs to handle the address as well, since we
>> don't want that a
>> scancode meant to go to your TV to be handled by the
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 06, 2009 at 12:58:00PM +0100, Christoph Bartelmus wrote: > Hi Dmitry, > > on 04 Dec 09 at 15:15, Dmitry Torokhov wrote: > [...] > >> http://lirc.sourceforge.net/remotes/lg/6711A20015N > >> > >> This is an air-conditioner remote. > >> The entries that you see in this config file are not really separate > >> buttons. Instead the remote just sends the current settings for e.g. > >> temperature encoded in the protocol when you press some up/down key. > >> You really don't want to map all possible temperature settings to KEY_* > >> events. For such cases it would be nice to have access at the raw scan > >> codes from user space to do interpretation of the data. > >> The default would still be to pass the data to the input layer, but it > >> won't hurt to have the possibility to access the raw data somehow. > > > Interesting. IMHO, the better would be to add an evdev ioctl to return > > the scancode for such cases, instead of returning the keycode. > > That means you would have to set up a pseudo keymap, so that you can get > the key event which you could than react on with a ioctl. Or are you > generating KEY_UNKNOWN for every scancode that is not mapped? > What if different scan codes are mapped to the same key event? How do you > retrieve the scan code for the key event? > I don't think it can work this way. > > >> > >>> EV_MSC/MSC_SCAN. > >> > >> How would I get the 64 bit scan codes that the iMON devices generate? > >> How would I know that the scan code is 64 bit? > >> input_event.value is __s32. > >> > > > I suppose we could add MSC_SCAN_END event so that we can transmit > > "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by > > MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 > > bit. > > And I set a timeout to know that no MSC_SCAN_END will arrive? This is > broken design IMHO. > EV_SYN signals the end of state transmission. > Furthermore lircd needs to know the length of the scan code in bits, not > as a multiple of 32. I really do not think that LIRCD is the type of application that should be using evdev interface, but rather other way around. > > > FWIW there is MSC_RAW as well. > > It took me some time to convice people that this is not the right way to > handle raw timing data. > > Christoph -- Dmitry -- 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?
On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
> Dmitry Torokhov wrote:
> > On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
> >> Em Fri, 4 Dec 2009 02:06:42 -0800
> >> Dmitry Torokhov escreveu:
> >>
> >>> evdev does not really care what you use as scancode. So nobody stops
> >>> your driver to report index as a scancode and accept index from the
> >>> ioctl. The true "scancode" will thus be competely hidden from userspace.
> >>> In fact a few drivers do just that.
> >> Let me better express here. It is all about how we'll expand the limits of
> >> those
> >> ioctls to fulfill the needs.
> >>
> >> The point is that we'll have, let's say something like to 50-500
> >> scancode/keycode tuples
> >> sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure
> >> if is there any
> >> IR protocol/code with a bigger scancode).
> >>
> >> On such universe if we want to get all keycodes with the current ioctls
> >> for a scancode in
> >> the range of 32 bits, we need to do something like:
> >>
> >> u32 code;
> >> int codes[2];
> >> for (code = 0; code <= (unsigned u32) - 1; code++) {
> >>codes[0] = (int)code;
> >>if (!ioctl(fd, EVIOCGKEYCODE, codes))
> >>printf("scancode 0x%08x = keycode 0x%08x\n", codes[0],
> >> codes[1]);
> >> }
> >>
> >> So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE
> >> ioctl to
> >> read the complete scancode space, to get those 50-500 useful codes.
> >>
> >
> > Right, currently there is no need to query all scancodes defined by
> > device. Quite often drivers don't even know what scancodes device
> > actually generates (ex AT keyboard).
> >
> > Could you describe in more detail how you are using this data?
>
> It is useful if you want to dump the keycode maps into file with the current
> scancode attribution, in order to modify some keystrokes.
>
> Right now, programs like dumpkeys (from kbd package) allow you to dump for
> example
> the attribution keys from your keyboard.
>
> In the case of IR's this functionality is very important.
>
> For example, you may need to replace the scancode/KEY_CHANNELUP tuple by
> scancode/KEY_UP,
> in order to make your IR to work with some applications that don't recognize
> the IR
> specific keycodes.
>
> In practice, with such applications, you'll need to replace several different
> scancodes.
>
> So, you may end by having different scancodes producing the same keycode, as
> such applications
> aren't capable of differentiating an UP key from a CHANNELUP key. This is the
> case, for example
> of the popular tvtime application.
>
> The better way is to just generate a dump file, modify the needed entries and
> reload the
> table by calling EVIOSKEYCODE, in order to use the new table.
>
> I wrote a small application that just do the above, and I use to load some
> special tables
> to work with some applications like tvtime and mplayer. (with mplayer, you
> need to map
> as KEY_H and as KEY_K).
>
> I hope that, after we finish addressing IR's, we'll finally have media
> applications handling
> directly the proper keycodes, but people may still need to write different
> keycodes to do
> other things. I used to have a keymap file in order to use an IR to control
> the slide show
> with openoffice.
>
> >> Due to the current API limit, we don't have any way to use the full 64bits
> >> space for scancodes.
> >>
> >
> > Can we probably reduce the "scancode" space? ARe all 64 bits in
> > protocols used to represent keypresses or some are used for some kind of
> > addressing?
>
> All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
> extended protocol).
> However, currently, the drivers were getting only 7 bits, due to the old way
> to implement
> EVIO[S|G]KEYCODE.
>
> I know, however, one i2c chip that returns a 5 byte scancode when you press a
> key.
> We're currently just discarding the remaining bits, so I'm not really sure
> what's there.
>
>
> The usage of 7 bits, in practice, were meaning that it weren't possible to use
> a different remote than the one provided by the device manufacturer, as the
> scancodes produced
> by other remotes differ on more than 7 bits. Also, this means that, if your
> TV and your PC
> are using the same protocol, like RC5, if you press a button on your TV
> remote, the PC will
> also get it.
>
> I know, however, one IR driver that produces 6 bytes when you press a key.
> We're currently just discarding the remaining bits, so I'm not really sure
> what else is there. Some badly optimized protocol? a bigger scancode? a
> protocol indication?
>
> In general, the scancode contains 8 or 16 bits for address, and 8 bits for
> command.
>
> However, the scancode table needs to handle the address as well, since we
> don't want that a
> scancode meant to go to your TV to be handled by the PC, but we may want to
> get codes from
> different addresses there, as
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa wrote: > Jon Smirl writes: > >>> Once again: how about agreement about the LIRC interface >>> (kernel-userspace) and merging the actual LIRC code first? In-kernel >>> decoding can wait a bit, it doesn't change any kernel-user interface. >> >> I'd like to see a semi-complete design for an in-kernel IR system >> before anything is merged from any source. > > This is a way to nowhere, there is no logical dependency between LIRC > and input layer IR. > > There is only one thing which needs attention before/when merging LIRC: > the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, > actually, making a correct IR core design without the LIRC merged can be > only harder. Here's a few design review questions on the LIRC drivers that were posted How is the pulse data going to be communicated to user space? Can the pulse data be reported via an existing interface without creating a new one? Where is the documentation for the protocol? Is it a device interface or something else? Does it work with poll, epoll, etc? What is the time standard for the data, where does it come from? How do you define the start and stop of sequences? What about capabilities of the receiver, what frequencies? If a receiver has multiple frequencies, how do you report what frequency the data came in on? What about multiple apps simultaneously using the pulse data? Is receiving synchronous or queued? How big is the receive queue? How does access work, root only or any user? What about transmit, how do you get pulse data into the device? Transmitter frequencies? Multiple transmitters? Is transmitting synchronous or queued? How big is the transmit queue? How are capabilities exposed, sysfs, etc? What is the interface for attaching an in-kernel decoder? If there is an in-kernel decoder should the pulse data stop being reported, partially stopped, something else? What is the mechanism to make sure both system don't process the same pulses? > -- > Krzysztof Halasa > -- Jon Smirl jonsm...@gmail.com -- 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 writes: >> Once again: how about agreement about the LIRC interface >> (kernel-userspace) and merging the actual LIRC code first? In-kernel >> decoding can wait a bit, it doesn't change any kernel-user interface. > > I'd like to see a semi-complete design for an in-kernel IR system > before anything is merged from any source. This is a way to nowhere, there is no logical dependency between LIRC and input layer IR. There is only one thing which needs attention before/when merging LIRC: the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, actually, making a correct IR core design without the LIRC merged can be only harder. -- Krzysztof Halasa -- 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 writes: > The in-kernel support can start small and add protocols and maps over > time. Protocols, yes. Maps - we certainly don't want megatons of maps in the kernel. The existing ones have to be removed, some time. -- Krzysztof Halasa -- 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?
Mauro Carvalho Chehab writes:
> All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC
> extended protocol).
> However, currently, the drivers were getting only 7 bits, due to the old way
> to implement
> EVIO[S|G]KEYCODE.
>
> I know, however, one i2c chip that returns a 5 byte scancode when you press a
> key.
> We're currently just discarding the remaining bits, so I'm not really sure
> what's there.
Right. This will have to be investigated by owners of the exact hardware
in question. What we can do is to try to make it easy for them.
There is no hurry, though - it can and will continue to work the current
way.
> In general, the scancode contains 8 or 16 bits for address, and 8 bits for
> command.
Right. I think the kernel shouldn't differentiate between address and
command too much.
> at include/linux/input.h, we'll add a code like:
>
> struct input_keytable_entry {
> u16 index;
> u64 scancode;
> u32 keycode;
> } __attribute__ ((packed));
>
> (the attribute packed avoids needing a compat for 64 bits)
Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
bit better, no alignment problems and we could eventually change
"reserved" into something useful.
But I think, if we are going to redesign it, we better use scancodes of
arbitrary length (e.g. protocol-dependent length). It should be opaque
except for the protocol handler.
--
Krzysztof Halasa
--
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?
On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa wrote: > Once again: how about agreement about the LIRC interface > (kernel-userspace) and merging the actual LIRC code first? In-kernel > decoding can wait a bit, it doesn't change any kernel-user interface. I'd like to see a semi-complete design for an in-kernel IR system before anything is merged from any source. -- Jon Smirl jonsm...@gmail.com -- 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?
Mauro Carvalho Chehab writes:
>> I do not believe you are being realistic. Sometimes we just need to say
>> that the device is a POS and is just not worth it. Remember, there is
>> still "lirc hole" for the hard core people still using solder to produce
>> something out of the spare electronic components that may be made to
>> work
Which device? It was about a remote controller, not the receiver. The IR
receivers are frequently coupled with a DVB etc. receiver. There is
absolutely no problem supporting almost any remote if the hardware is
compatible with the receiver (i.e. IR to IR, the carrier frequency is
not 36 vs 56 kHz, the receiver supports the protocol etc).
I don't say we need to support in-kernel decoding for arbitrary
protocols.
>> (never mind that it causes the CPU constantly poll the device, not
>> letting it sleep and wasting electricity as a result - just hypotetical
>> example here).
Very hypotetical, indeed :-)
Most (all?) home-made receivers don't need polling, they use IRQs
instead ("the" home-made receiver is based on serial port and uses IRQ).
They are hardly the "obscure hardware" that nobody has.
The "more advanced" receivers using shift registers may use polling.
> Fully agreed. The costs (our time) to add and keep supporting an in-kernel
> driver for an IR that just one person is still using is higher than
> asking the user to get a new IR. This time would be better spent adding a new
> driver for other devices.
Agreed, I think nobody argues we should support such things in the
kernel.
Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
--
Krzysztof Halasa
--
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
