Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Tue, May 25, 2010 at 5:05 PM, Jarod Wilson wrote: > On Wed, Apr 28, 2010 at 12:32 AM, Jarod Wilson wrote: >> On Sat, Apr 24, 2010 at 1:12 AM, David Härdeman wrote: >>> On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote: So now that I'm more or less done with porting the imon driver, I think I'm ready to start tackling the mceusb driver. But I'm debating on what approach to take with respect to lirc support. It sort of feels like we should have lirc_dev ported as an ir "decoder" driver/plugin before starting to port mceusb to ir-core, so that we can maintain lirc compat and transmit support. Alternatively, I could port mceusb without lirc support for now, leaving it to only use in-kernel decoding and have no transmit support for the moment, then re-add lirc support. I'm thinking that porting lirc_dev as, say, ir-lirc-decoder first is probably the way to go though. Anyone else want to share their thoughts on this? >>> >>> I think it would make sense to start with a mce driver without the TX >>> and lirc bits first. Adding lirc rx support can be done as a separate >>> "raw" decoder later (so its scope is outside the mce driver anyway) and >>> TX support is not implemented in ir-core yet and we haven't had any >>> discussion yet on which form it should take. >> >> So after looking at folks feedback, I did settle on starting the >> mceusb port first, my logic going more or less like this... Having a >> well-supported general-purpose IR receiver functional is a Good Thing >> for people wanting to work on protocol support (i.e., so they have a >> way to actually test protocol support). Having an >> already-ir-core-ified driver to test out an ir-lirc-decoder (lirc_dev >> port) would also be rather helpful. So rather than trying to port >> lirc_dev before there's anything that can actually make use of it, >> give myself something to work with. I'm kind of thinking that >> ir-lirc-decoder might actually be ir-lirc-codec, able to do xmit as >> well, maintaining full compat with lirc userspace, and then we'd have >> a separate input subsystem based xmit method at some point, which >> might be the "preferred/blessed" route. This means ripping a bunch of >> code out of lirc_mceusb.c only to put it back in later, but that's not >> terribly painful. I've already got as far as having an mceusb.c that >> has no lirc dependency, which builds, but doesn't actually do anything >> useful yet (not wired up to ir-core). Should be able to get something >> functional RSN, I hope... > > Got sidetracked for a few weeks, but I'm probably 95% of the way there > as of this afternoon. Something isn't quite right with how I'm > processing and handing off the raw IR data right now though, best as I > can tell. Its also possible my first-gen mce device is throwing things > for a loop, so I need to see if maybe things Just Work with a newer > gen device so I know if its device-specific, or if something is still > generally wrong. I did crib the simplified mce data processing routine > from Jon's code, but the original lirc_mceusb.c has some changes > specific to the first-gen mce device that were made to properly > support it quite some time after Jon's port, so I may also try w/the > uglier/more complex routine I know has been working on this device... > > David, you mentioned having something based on Jon's earlier port that > was more or less working. I'd be curious to get a look at that if > you're willing to drop me a copy, see if I've missed something > blindingly stupid. :) I was missing something blindingly stupid. Was accumulating duration values in ms instead of us. Now alternating presses of the OK button on the stock MCE remote get this: ir_rc6_decode: RC6(6A) scancode 0x800f0422 (toggle: 1) ir_rc6_decode: RC6(6A) scancode 0x800f0422 (toggle: 0) This is with Jon's IR handling routine and a recent MCE device, still need to go back and see how the older one behaves, but within the next few days, I should have a patch worthy of submission. -- Jarod Wilson ja...@wilsonet.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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Wed, Apr 28, 2010 at 12:32 AM, Jarod Wilson wrote: > On Sat, Apr 24, 2010 at 1:12 AM, David Härdeman wrote: >> On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote: >>> So now that I'm more or less done with porting the imon driver, I >>> think I'm ready to start tackling the mceusb driver. But I'm debating >>> on what approach to take with respect to lirc support. It sort of >>> feels like we should have lirc_dev ported as an ir "decoder" >>> driver/plugin before starting to port mceusb to ir-core, so that we >>> can maintain lirc compat and transmit support. Alternatively, I could >>> port mceusb without lirc support for now, leaving it to only use >>> in-kernel decoding and have no transmit support for the moment, then >>> re-add lirc support. I'm thinking that porting lirc_dev as, say, >>> ir-lirc-decoder first is probably the way to go though. Anyone else >>> want to share their thoughts on this? >> >> I think it would make sense to start with a mce driver without the TX >> and lirc bits first. Adding lirc rx support can be done as a separate >> "raw" decoder later (so its scope is outside the mce driver anyway) and >> TX support is not implemented in ir-core yet and we haven't had any >> discussion yet on which form it should take. > > So after looking at folks feedback, I did settle on starting the > mceusb port first, my logic going more or less like this... Having a > well-supported general-purpose IR receiver functional is a Good Thing > for people wanting to work on protocol support (i.e., so they have a > way to actually test protocol support). Having an > already-ir-core-ified driver to test out an ir-lirc-decoder (lirc_dev > port) would also be rather helpful. So rather than trying to port > lirc_dev before there's anything that can actually make use of it, > give myself something to work with. I'm kind of thinking that > ir-lirc-decoder might actually be ir-lirc-codec, able to do xmit as > well, maintaining full compat with lirc userspace, and then we'd have > a separate input subsystem based xmit method at some point, which > might be the "preferred/blessed" route. This means ripping a bunch of > code out of lirc_mceusb.c only to put it back in later, but that's not > terribly painful. I've already got as far as having an mceusb.c that > has no lirc dependency, which builds, but doesn't actually do anything > useful yet (not wired up to ir-core). Should be able to get something > functional RSN, I hope... Got sidetracked for a few weeks, but I'm probably 95% of the way there as of this afternoon. Something isn't quite right with how I'm processing and handing off the raw IR data right now though, best as I can tell. Its also possible my first-gen mce device is throwing things for a loop, so I need to see if maybe things Just Work with a newer gen device so I know if its device-specific, or if something is still generally wrong. I did crib the simplified mce data processing routine from Jon's code, but the original lirc_mceusb.c has some changes specific to the first-gen mce device that were made to properly support it quite some time after Jon's port, so I may also try w/the uglier/more complex routine I know has been working on this device... David, you mentioned having something based on Jon's earlier port that was more or less working. I'd be curious to get a look at that if you're willing to drop me a copy, see if I've missed something blindingly stupid. :) What I get right now when I press a key: ... ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (1us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us pulse) ir_rc6_decode: RC6 decode failed at state 0 (0us space) ir_rc6_decode: RC6 decode failed at state 0 (1us pulse) Always fails at state 0, varying us values from 0 to 100, but mostly 0 and 1. -- Jarod Wilson ja...@wilsonet.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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 1:12 AM, David Härdeman wrote: > On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote: >> So now that I'm more or less done with porting the imon driver, I >> think I'm ready to start tackling the mceusb driver. But I'm debating >> on what approach to take with respect to lirc support. It sort of >> feels like we should have lirc_dev ported as an ir "decoder" >> driver/plugin before starting to port mceusb to ir-core, so that we >> can maintain lirc compat and transmit support. Alternatively, I could >> port mceusb without lirc support for now, leaving it to only use >> in-kernel decoding and have no transmit support for the moment, then >> re-add lirc support. I'm thinking that porting lirc_dev as, say, >> ir-lirc-decoder first is probably the way to go though. Anyone else >> want to share their thoughts on this? > > I think it would make sense to start with a mce driver without the TX > and lirc bits first. Adding lirc rx support can be done as a separate > "raw" decoder later (so its scope is outside the mce driver anyway) and > TX support is not implemented in ir-core yet and we haven't had any > discussion yet on which form it should take. So after looking at folks feedback, I did settle on starting the mceusb port first, my logic going more or less like this... Having a well-supported general-purpose IR receiver functional is a Good Thing for people wanting to work on protocol support (i.e., so they have a way to actually test protocol support). Having an already-ir-core-ified driver to test out an ir-lirc-decoder (lirc_dev port) would also be rather helpful. So rather than trying to port lirc_dev before there's anything that can actually make use of it, give myself something to work with. I'm kind of thinking that ir-lirc-decoder might actually be ir-lirc-codec, able to do xmit as well, maintaining full compat with lirc userspace, and then we'd have a separate input subsystem based xmit method at some point, which might be the "preferred/blessed" route. This means ripping a bunch of code out of lirc_mceusb.c only to put it back in later, but that's not terribly painful. I've already got as far as having an mceusb.c that has no lirc dependency, which builds, but doesn't actually do anything useful yet (not wired up to ir-core). Should be able to get something functional RSN, I hope... -- Jarod Wilson ja...@wilsonet.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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 5:23 PM, David Härdeman wrote: > I don't care either way. Get the input maintainers to agree and I'll > happily write patches that follow that approach (writing TX data to the > input dev will also have to be supported). > > The only real problem I see is if we implement > 1 input device per > rc/ir device (which I think we should do - each logical remote should > have a separate keytable and input device). I forgot about the many to 1 aspect of the receiver. You should have started off with this point and I would have shut up, DRM does not have many to 1 mappings. My radio receivers show up as network devices. So I have multiple devices too. I don't think we want a 'rc' device. The IR transceiver should be an 'ir' device. My radios are already 'net' devices. So my complaint really is, I don't want an three devices - input, rc and net. -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 11:07:07AM -0400, Jon Smirl wrote: > On Sat, Apr 24, 2010 at 10:15 AM, David Härdeman wrote: > > On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: > >> On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman wrote: > >> > I think we're eventually going to want to let rc-core create a > >> > chardev > >> > per rc device to allow for things like reading out scancodes (when > >> > creating keymaps for new and unknown remotes), raw timings (for > >> > debugging in-kernel decoders and writing new ones), possibly also > >> > ioctl's (for e.g. setting all RX parameters in one go or to > >> > create/destroy additional keymaps, though I'm sure some will want all of > >> > that to go through sysfs). > >> > >> That problem is handled differently in the graphics code. You only > >> have one /dev device for graphics. IOCTLs on it are divided into > >> ranges - core and driver. The IOCTL call initially lands in the core > >> code, but if it is in the driver range it simply gets forwarded to the > >> specific driver and handled there. > >> > >> Doing it that was avoids needing two /dev devices nodes for the same > >> device. Two device nodes has problems. How do you keep them from > >> being open by two different users and different privilege levels, or > >> one is open and one closed, etc... > > > > I'm not sure which two devices you're talking about. ir-core currently > > creates no device at all (unless you count the input device). And > > further down the road I think each rc (ir) device should support > > multiple keytables, each keytable having an associated input device. > > > > Input device(s) would be used by the majority of applications that only > > want to react on keypresses, the rc device is used by rc-aware > > applications that want to create new keytables, send ir commands, tweak > > RX/TX parameters, etc. I do not see how any of your two-device concerns > > would apply to that division... > > > >> Splitting the IOCTL range is easy to add to input core and it won't > >> effect any existing user space code. > > > > The input maintainers have already NAK'ed adding any ir-specific ioctls > > to the input layer, and I tend to agree with them. > > Based on my experience with DRM adding a split to the IOCTL range is a > good solution. The split does not add IR specific IOCTLs to the input > core. The input core just looks at the IOCTL number and if it is out > of range it forwards it down the chain - to IR core, which can process > it or forward to the specific driver. This model is already in use > and it works without problem. I don't care either way. Get the input maintainers to agree and I'll happily write patches that follow that approach (writing TX data to the input dev will also have to be supported). The only real problem I see is if we implement > 1 input device per rc/ir device (which I think we should do - each logical remote should have a separate keytable and input device). -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 10:15 AM, David Härdeman wrote: > On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: >> On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman wrote: >> > On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: >> >> Not that my commit rate has been > 0 LOC lately, but I'd like to see >> >> lirc_dev, just to get transmit worked out for the CX23888 chip and >> >> cx23885 driver. >> >> >> >> I think this device will bring to light some assumptions LIRC currently >> >> makes about transmit that don't apply to the CX23888 (i.e. LIRC having >> >> to perform the pulse timing). The cx23888-ir implementation has a kfifo >> >> for holding outgoing pulse data and the hardware itself has an 8 pulse >> >> measurement deep fifo. >> > >> > I think we're eventually going to want to let rc-core create a chardev >> > per rc device to allow for things like reading out scancodes (when >> > creating keymaps for new and unknown remotes), raw timings (for >> > debugging in-kernel decoders and writing new ones), possibly also >> > ioctl's (for e.g. setting all RX parameters in one go or to >> > create/destroy additional keymaps, though I'm sure some will want all of >> > that to go through sysfs). >> >> That problem is handled differently in the graphics code. You only >> have one /dev device for graphics. IOCTLs on it are divided into >> ranges - core and driver. The IOCTL call initially lands in the core >> code, but if it is in the driver range it simply gets forwarded to the >> specific driver and handled there. >> >> Doing it that was avoids needing two /dev devices nodes for the same >> device. Two device nodes has problems. How do you keep them from >> being open by two different users and different privilege levels, or >> one is open and one closed, etc... > > I'm not sure which two devices you're talking about. ir-core currently > creates no device at all (unless you count the input device). And > further down the road I think each rc (ir) device should support > multiple keytables, each keytable having an associated input device. > > Input device(s) would be used by the majority of applications that only > want to react on keypresses, the rc device is used by rc-aware > applications that want to create new keytables, send ir commands, tweak > RX/TX parameters, etc. I do not see how any of your two-device concerns > would apply to that division... > >> Splitting the IOCTL range is easy to add to input core and it won't >> effect any existing user space code. > > The input maintainers have already NAK'ed adding any ir-specific ioctls > to the input layer, and I tend to agree with them. Based on my experience with DRM adding a split to the IOCTL range is a good solution. The split does not add IR specific IOCTLs to the input core. The input core just looks at the IOCTL number and if it is out of range it forwards it down the chain - to IR core, which can process it or forward to the specific driver. This model is already in use and it works without problem. > want to react on keypresses, the rc device is used by rc-aware > applications that want to create new keytables, send ir commands, tweak > RX/TX parameters, etc. I do not see how any of your two-device concerns These would be implemented by IOCTL forwarding. >> Don't forget about binary sysfs attributes. I have scars from >> implementing sysfs attributes as text that other people thought should >> have been binary. >> >> There has long been talk of implementing sysfs transactions. I think >> the closest thing that got implemented was to not make the attributes >> take effect until an action occurs. For example, you would set all of >> the RX parameters using sysfs. They would be written into shadow >> variables. Then you write to a 'commit' attribute. The write triggers >> the copy from the shadow variables to the real ones. > > I still fail to understand why sysfs is preferrable over ioctls. I don't care one way or the other. IOCTLs have portability issues with word size and endianness. sysfs gets rid of those problems. But sysfs doesn't have an explicit transaction mechanism. So both strategies have issues. > >> Why are the TX variables being set via sysfs? > > There's not a single line of TX code yet. > >> I think the attributes >> were read only in the code I wrote. Instead I set them via commands in >> the input stream. Setting via the stream make it easy to change them >> on each transmit. The input layer already supports transactions >> wrapping in output. The same transactions could be used to wrap input >> parameter setting. Start an input transaction, set the TX variables, >> send the pulse data, end the input transaction. I don't remember if I >> got around to implementing that. > > Again, the input maintainers have NAK'ed the kind of changes that would > be necessary to support TX through the input layer. We're going to have > to go with something ir-core specific. We already have two way devices in the input l
Re: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 08:35:48AM -0400, Jon Smirl wrote: > On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman wrote: > > On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: > >> Not that my commit rate has been > 0 LOC lately, but I'd like to see > >> lirc_dev, just to get transmit worked out for the CX23888 chip and > >> cx23885 driver. > >> > >> I think this device will bring to light some assumptions LIRC currently > >> makes about transmit that don't apply to the CX23888 (i.e. LIRC having > >> to perform the pulse timing). The cx23888-ir implementation has a kfifo > >> for holding outgoing pulse data and the hardware itself has an 8 pulse > >> measurement deep fifo. > > > > I think we're eventually going to want to let rc-core create a chardev > > per rc device to allow for things like reading out scancodes (when > > creating keymaps for new and unknown remotes), raw timings (for > > debugging in-kernel decoders and writing new ones), possibly also > > ioctl's (for e.g. setting all RX parameters in one go or to > > create/destroy additional keymaps, though I'm sure some will want all of > > that to go through sysfs). > > That problem is handled differently in the graphics code. You only > have one /dev device for graphics. IOCTLs on it are divided into > ranges - core and driver. The IOCTL call initially lands in the core > code, but if it is in the driver range it simply gets forwarded to the > specific driver and handled there. > > Doing it that was avoids needing two /dev devices nodes for the same > device. Two device nodes has problems. How do you keep them from > being open by two different users and different privilege levels, or > one is open and one closed, etc... I'm not sure which two devices you're talking about. ir-core currently creates no device at all (unless you count the input device). And further down the road I think each rc (ir) device should support multiple keytables, each keytable having an associated input device. Input device(s) would be used by the majority of applications that only want to react on keypresses, the rc device is used by rc-aware applications that want to create new keytables, send ir commands, tweak RX/TX parameters, etc. I do not see how any of your two-device concerns would apply to that division... > Splitting the IOCTL range is easy to add to input core and it won't > effect any existing user space code. The input maintainers have already NAK'ed adding any ir-specific ioctls to the input layer, and I tend to agree with them. > Don't forget about binary sysfs attributes. I have scars from > implementing sysfs attributes as text that other people thought should > have been binary. > > There has long been talk of implementing sysfs transactions. I think > the closest thing that got implemented was to not make the attributes > take effect until an action occurs. For example, you would set all of > the RX parameters using sysfs. They would be written into shadow > variables. Then you write to a 'commit' attribute. The write triggers > the copy from the shadow variables to the real ones. I still fail to understand why sysfs is preferrable over ioctls. > Why are the TX variables being set via sysfs? There's not a single line of TX code yet. > I think the attributes > were read only in the code I wrote. Instead I set them via commands in > the input stream. Setting via the stream make it easy to change them > on each transmit. The input layer already supports transactions > wrapping in output. The same transactions could be used to wrap input > parameter setting. Start an input transaction, set the TX variables, > send the pulse data, end the input transaction. I don't remember if I > got around to implementing that. Again, the input maintainers have NAK'ed the kind of changes that would be necessary to support TX through the input layer. We're going to have to go with something ir-core specific. -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Sat, Apr 24, 2010 at 1:22 AM, David Härdeman wrote: > On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: >> Not that my commit rate has been > 0 LOC lately, but I'd like to see >> lirc_dev, just to get transmit worked out for the CX23888 chip and >> cx23885 driver. >> >> I think this device will bring to light some assumptions LIRC currently >> makes about transmit that don't apply to the CX23888 (i.e. LIRC having >> to perform the pulse timing). The cx23888-ir implementation has a kfifo >> for holding outgoing pulse data and the hardware itself has an 8 pulse >> measurement deep fifo. > > I think we're eventually going to want to let rc-core create a chardev > per rc device to allow for things like reading out scancodes (when > creating keymaps for new and unknown remotes), raw timings (for > debugging in-kernel decoders and writing new ones), possibly also > ioctl's (for e.g. setting all RX parameters in one go or to > create/destroy additional keymaps, though I'm sure some will want all of > that to go through sysfs). That problem is handled differently in the graphics code. You only have one /dev device for graphics. IOCTLs on it are divided into ranges - core and driver. The IOCTL call initially lands in the core code, but if it is in the driver range it simply gets forwarded to the specific driver and handled there. Doing it that was avoids needing two /dev devices nodes for the same device. Two device nodes has problems. How do you keep them from being open by two different users and different privilege levels, or one is open and one closed, etc... Splitting the IOCTL range is easy to add to input core and it won't effect any existing user space code. Don't forget about binary sysfs attributes. I have scars from implementing sysfs attributes as text that other people thought should have been binary. There has long been talk of implementing sysfs transactions. I think the closest thing that got implemented was to not make the attributes take effect until an action occurs. For example, you would set all of the RX parameters using sysfs. They would be written into shadow variables. Then you write to a 'commit' attribute. The write triggers the copy from the shadow variables to the real ones. Why are the TX variables being set via sysfs? I think the attributes were read only in the code I wrote. Instead I set them via commands in the input stream. Setting via the stream make it easy to change them on each transmit. The input layer already supports transactions wrapping in output. The same transactions could be used to wrap input parameter setting. Start an input transaction, set the TX variables, send the pulse data, end the input transaction. I don't remember if I got around to implementing that. > > That same chardev could also be used to implement TX, once a suitable > interface has been fleshed out. The end result might not look exactly > like lirc... > > -- > David Härdeman > -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 23, 2010 at 06:20:28PM -0400, Andy Walls wrote: > Not that my commit rate has been > 0 LOC lately, but I'd like to see > lirc_dev, just to get transmit worked out for the CX23888 chip and > cx23885 driver. > > I think this device will bring to light some assumptions LIRC currently > makes about transmit that don't apply to the CX23888 (i.e. LIRC having > to perform the pulse timing). The cx23888-ir implementation has a kfifo > for holding outgoing pulse data and the hardware itself has an 8 pulse > measurement deep fifo. I think we're eventually going to want to let rc-core create a chardev per rc device to allow for things like reading out scancodes (when creating keymaps for new and unknown remotes), raw timings (for debugging in-kernel decoders and writing new ones), possibly also ioctl's (for e.g. setting all RX parameters in one go or to create/destroy additional keymaps, though I'm sure some will want all of that to go through sysfs). That same chardev could also be used to implement TX, once a suitable interface has been fleshed out. The end result might not look exactly like lirc... -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 23, 2010 at 01:40:34PM -0400, Jarod Wilson wrote: > So now that I'm more or less done with porting the imon driver, I > think I'm ready to start tackling the mceusb driver. But I'm debating > on what approach to take with respect to lirc support. It sort of > feels like we should have lirc_dev ported as an ir "decoder" > driver/plugin before starting to port mceusb to ir-core, so that we > can maintain lirc compat and transmit support. Alternatively, I could > port mceusb without lirc support for now, leaving it to only use > in-kernel decoding and have no transmit support for the moment, then > re-add lirc support. I'm thinking that porting lirc_dev as, say, > ir-lirc-decoder first is probably the way to go though. Anyone else > want to share their thoughts on this? I think it would make sense to start with a mce driver without the TX and lirc bits first. Adding lirc rx support can be done as a separate "raw" decoder later (so its scope is outside the mce driver anyway) and TX support is not implemented in ir-core yet and we haven't had any discussion yet on which form it should take. > (Actually, while sharing thoughts... Should drivers/media/IR become > drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become > rc-keytable.c and so on?) It will happen...and on a related note, I still think rc-core should in the end expose an API where drivers create "rc" devices and the input device(s) are kept as an internal detail in rc-core rather than the way it works now (where drivers create input devices and use ir-core to create a kind of addon device). But that change is about as disruptive as the ir-core -> rc-core change, so it can also wait to a more convenient time. -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, 2010-04-23 at 14:06 -0400, Jon Smirl wrote: > On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson wrote: > > > > So now that I'm more or less done with porting the imon driver, I > > think I'm ready to start tackling the mceusb driver. But I'm debating > > on what approach to take with respect to lirc support. It sort of > > feels like we should have lirc_dev ported as an ir "decoder" > > driver/plugin before starting to port mceusb to ir-core, so that we > > can maintain lirc compat and transmit support. Alternatively, I could > > port mceusb without lirc support for now, leaving it to only use > > in-kernel decoding and have no transmit support for the moment, then > > re-add lirc support. I'm thinking that porting lirc_dev as, say, > > ir-lirc-decoder first is probably the way to go though. Anyone else > > want to share their thoughts on this? > > I'd take whatever you think is the simplest path. It is more likely > that initial testers will want to work with the new in-kernel system > than the compatibility layer to LIRC. Existing users that are happy > with the current LIRC should just keep on using it. Jarod, Not that my commit rate has been > 0 LOC lately, but I'd like to see lirc_dev, just to get transmit worked out for the CX23888 chip and cx23885 driver. I think this device will bring to light some assumptions LIRC currently makes about transmit that don't apply to the CX23888 (i.e. LIRC having to perform the pulse timing). The cx23888-ir implementation has a kfifo for holding outgoing pulse data and the hardware itself has an 8 pulse measurement deep fifo. But I'd recommend whatever helps you get more productive work done first. I've had no time for linux lately. 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
Jon Smirl wrote: >> So now that I'm more or less done with porting the imon driver, I >> think I'm ready to start tackling the mceusb driver. But I'm debating >> on what approach to take with respect to lirc support. It sort of >> feels like we should have lirc_dev ported as an ir "decoder" >> driver/plugin before starting to port mceusb to ir-core, so that we >> can maintain lirc compat and transmit support. Alternatively, I could >> port mceusb without lirc support for now, leaving it to only use >> in-kernel decoding and have no transmit support for the moment, then >> re-add lirc support. I'm thinking that porting lirc_dev as, say, >> ir-lirc-decoder first is probably the way to go though. Anyone else >> want to share their thoughts on this? > > I'd take whatever you think is the simplest path. It is more likely > that initial testers will want to work with the new in-kernel system > than the compatibility layer to LIRC. Existing users that are happy > with the current LIRC should just keep on using it. Agreed. You may start by adding either lirc "decoder" or mce. Both ways will end on having the same result ;) >> (Actually, while sharing thoughts... Should drivers/media/IR become >> drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become >> rc-keytable.c and so on?) > > Why aren't these files going into drivers/input/rc? My embedded system > has a remote control and it has nothing to do with media. Historical reasons. It were simpler to start from drivers/media, as we've started with some already existing code there. My intention is to write one or two big patches at the end, moving everything to drivers/rc or drivers/input/rc and renaming the structures. The point is that a patch like that will force people that are working on the code to rebase to the newer names, so I prefer to postpone it to happen after we finish with the big changes. A change like that won't affect just the new RC code, but also several V4L/DVB drivers. Maybe the right moment would be during the next merge window, as all pending work for 2.6.35 will be already finished, and people likely didn't start working for 2.6.36. So, my intention is to write such patch during the merge week, just after sending the pending stuff. -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 23, 2010 at 1:40 PM, Jarod Wilson wrote: > On Wed, Apr 7, 2010 at 5:32 AM, David Härdeman wrote: >> On Mon, Apr 05, 2010 at 04:49:10PM -0400, Jarod Wilson wrote: >>> On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote: >>> > Porting the msmce driver to rc-core will be high on my list of >>> > priorities once I've done some more changes to the API. >>> >>> Very cool. Though note that the latest lirc_mceusb is quite heavily >>> modified from what Jon had initially ported, and I still have a few >>> outstanding enhancements to make, such as auto-detecting xmit mask to >>> eliminate the crude inverted mask list and support for the mce IR >>> keyboard/mouse, though that'll probably be trivial once RC5 and RC6 >>> in-kernel decoders are in place. I'd intended to start with porting >>> the imon driver I'm working on over to this new infra (onboard >>> hardware decoder, should be rather easy to port), and then hop over to >>> the mceusb driver, but if you beat me to it, I've got no problem with >>> you doing it instead. :) >> >> I'd be happy with you doing it, you seem to know the hardware better >> than me. The mceusb driver I'm using right now with ir-core is based on >> Jon's driver which is in turn based on a version of lirc_mceusb which is >> quite old by now. My version of the driver is basically just random bits >> and pieces thrown together, enough to get pulse/space durations flowing >> through ir-core so that I can test the decoders, but not much more - so >> it's not something I'd even consider useful as a starting point :) > > So now that I'm more or less done with porting the imon driver, I > think I'm ready to start tackling the mceusb driver. But I'm debating > on what approach to take with respect to lirc support. It sort of > feels like we should have lirc_dev ported as an ir "decoder" > driver/plugin before starting to port mceusb to ir-core, so that we > can maintain lirc compat and transmit support. Alternatively, I could > port mceusb without lirc support for now, leaving it to only use > in-kernel decoding and have no transmit support for the moment, then > re-add lirc support. I'm thinking that porting lirc_dev as, say, > ir-lirc-decoder first is probably the way to go though. Anyone else > want to share their thoughts on this? I'd take whatever you think is the simplest path. It is more likely that initial testers will want to work with the new in-kernel system than the compatibility layer to LIRC. Existing users that are happy with the current LIRC should just keep on using it. MSMCE is a good device for debugging protocol engines. It's easy to use and pretty much always captures the pulses correctly. > > (Actually, while sharing thoughts... Should drivers/media/IR become > drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become > rc-keytable.c and so on?) Why aren't these files going into drivers/input/rc? My embedded system has a remote control and it has nothing to do with media. -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Wed, Apr 7, 2010 at 5:32 AM, David Härdeman wrote: > On Mon, Apr 05, 2010 at 04:49:10PM -0400, Jarod Wilson wrote: >> On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote: >> > Porting the msmce driver to rc-core will be high on my list of >> > priorities once I've done some more changes to the API. >> >> Very cool. Though note that the latest lirc_mceusb is quite heavily >> modified from what Jon had initially ported, and I still have a few >> outstanding enhancements to make, such as auto-detecting xmit mask to >> eliminate the crude inverted mask list and support for the mce IR >> keyboard/mouse, though that'll probably be trivial once RC5 and RC6 >> in-kernel decoders are in place. I'd intended to start with porting >> the imon driver I'm working on over to this new infra (onboard >> hardware decoder, should be rather easy to port), and then hop over to >> the mceusb driver, but if you beat me to it, I've got no problem with >> you doing it instead. :) > > I'd be happy with you doing it, you seem to know the hardware better > than me. The mceusb driver I'm using right now with ir-core is based on > Jon's driver which is in turn based on a version of lirc_mceusb which is > quite old by now. My version of the driver is basically just random bits > and pieces thrown together, enough to get pulse/space durations flowing > through ir-core so that I can test the decoders, but not much more - so > it's not something I'd even consider useful as a starting point :) So now that I'm more or less done with porting the imon driver, I think I'm ready to start tackling the mceusb driver. But I'm debating on what approach to take with respect to lirc support. It sort of feels like we should have lirc_dev ported as an ir "decoder" driver/plugin before starting to port mceusb to ir-core, so that we can maintain lirc compat and transmit support. Alternatively, I could port mceusb without lirc support for now, leaving it to only use in-kernel decoding and have no transmit support for the moment, then re-add lirc support. I'm thinking that porting lirc_dev as, say, ir-lirc-decoder first is probably the way to go though. Anyone else want to share their thoughts on this? (Actually, while sharing thoughts... Should drivers/media/IR become drivers/media/RC, ir-core.h become rc-core.h, ir-keytable.c become rc-keytable.c and so on?) -- Jarod Wilson ja...@wilsonet.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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Mon, Apr 05, 2010 at 04:49:10PM -0400, Jarod Wilson wrote: > On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote: > > Porting the msmce driver to rc-core will be high on my list of > > priorities once I've done some more changes to the API. > > Very cool. Though note that the latest lirc_mceusb is quite heavily > modified from what Jon had initially ported, and I still have a few > outstanding enhancements to make, such as auto-detecting xmit mask to > eliminate the crude inverted mask list and support for the mce IR > keyboard/mouse, though that'll probably be trivial once RC5 and RC6 > in-kernel decoders are in place. I'd intended to start with porting > the imon driver I'm working on over to this new infra (onboard > hardware decoder, should be rather easy to port), and then hop over to > the mceusb driver, but if you beat me to it, I've got no problem with > you doing it instead. :) I'd be happy with you doing it, you seem to know the hardware better than me. The mceusb driver I'm using right now with ir-core is based on Jon's driver which is in turn based on a version of lirc_mceusb which is quite old by now. My version of the driver is basically just random bits and pieces thrown together, enough to get pulse/space durations flowing through ir-core so that I can test the decoders, but not much more - so it's not something I'd even consider useful as a starting point :) Note however that you won't be able to actually port the mceusb driver over until ir-core is taught to use durations (first version of the patch is at [1], second version still brewing but I still need to convince Mauro though). [1] http://www.spinics.net/lists/linux-input/msg07859.html -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Fri, Apr 2, 2010 at 6:20 AM, David Härdeman wrote: > On Thu, Apr 01, 2010 at 09:44:12PM -0400, Jon Smirl wrote: >> On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab >> wrote: >> > This series of 15 patches improves support for IR, as discussed at the >> > "What are the goals for the architecture of an in-kernel IR system?" >> > thread. >> > >> > It basically adds a raw decoder layer at ir-core, allowing decoders to plug >> > into IR core, and preparing for the addition of a lirc_dev driver that will >> > allow raw IR codes to be sent to userspace. >> > >> > There's no lirc patch in this series. I have also a few other patches from >> > David Härdeman that I'm about to test/review probably later today, but >> > as I prefer to first merge what I have at V4L/DVB tree, before applying >> > them. >> >> Has anyone ported the MSMCE driver onto these patches yet? That would >> be a good check to make sure that rc-core has the necessary API. > > I still plan to make lots of changes to the rc-core API (I just have to > convince Mauro first, but I'll get there). What I have done is to port > your port of the msmce driver to the suggested rc-core subsystem I sent > you in private a week or so ago, and it works fine (I've bought the > hardware and tested it with 20 or so different protocols). > > The subsystem I suggested is basically what I'm using as inspiration > while working with Mauro in improving rc-core so msmce should work well > with the end product...but there's still some ground to cover. > > Porting the msmce driver to rc-core will be high on my list of > priorities once I've done some more changes to the API. Very cool. Though note that the latest lirc_mceusb is quite heavily modified from what Jon had initially ported, and I still have a few outstanding enhancements to make, such as auto-detecting xmit mask to eliminate the crude inverted mask list and support for the mce IR keyboard/mouse, though that'll probably be trivial once RC5 and RC6 in-kernel decoders are in place. I'd intended to start with porting the imon driver I'm working on over to this new infra (onboard hardware decoder, should be rather easy to port), and then hop over to the mceusb driver, but if you beat me to it, I've got no problem with you doing it instead. :) >> Cooler if it works both through LIRC and with an internal protocol >> decoder. The MSMCE driver in my old patches was very simplified, it >> removed about half of the code from the LIRC version. > > Yes, and it was a great help to me at least...thanks :) Yeah, copy that. Good to see we've got some major momentum going now, just need to get off my butt and do some more work on it myself... -- Jarod Wilson ja...@wilsonet.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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Thu, Apr 01, 2010 at 09:44:12PM -0400, Jon Smirl wrote: > On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab > wrote: > > This series of 15 patches improves support for IR, as discussed at the > > "What are the goals for the architecture of an in-kernel IR system?" > > thread. > > > > It basically adds a raw decoder layer at ir-core, allowing decoders to plug > > into IR core, and preparing for the addition of a lirc_dev driver that will > > allow raw IR codes to be sent to userspace. > > > > There's no lirc patch in this series. I have also a few other patches from > > David Härdeman that I'm about to test/review probably later today, but > > as I prefer to first merge what I have at V4L/DVB tree, before applying > > them. > > Has anyone ported the MSMCE driver onto these patches yet? That would > be a good check to make sure that rc-core has the necessary API. I still plan to make lots of changes to the rc-core API (I just have to convince Mauro first, but I'll get there). What I have done is to port your port of the msmce driver to the suggested rc-core subsystem I sent you in private a week or so ago, and it works fine (I've bought the hardware and tested it with 20 or so different protocols). The subsystem I suggested is basically what I'm using as inspiration while working with Mauro in improving rc-core so msmce should work well with the end product...but there's still some ground to cover. Porting the msmce driver to rc-core will be high on my list of priorities once I've done some more changes to the API. > Cooler if it works both through LIRC and with an internal protocol > decoder. The MSMCE driver in my old patches was very simplified, it > removed about half of the code from the LIRC version. Yes, and it was a great help to me at least...thanks :) -- 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: [PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
On Thu, Apr 1, 2010 at 1:56 PM, Mauro Carvalho Chehab wrote: > This series of 15 patches improves support for IR, as discussed at the > "What are the goals for the architecture of an in-kernel IR system?" > thread. > > It basically adds a raw decoder layer at ir-core, allowing decoders to plug > into IR core, and preparing for the addition of a lirc_dev driver that will > allow raw IR codes to be sent to userspace. > > There's no lirc patch in this series. I have also a few other patches from > David Härdeman that I'm about to test/review probably later today, but > as I prefer to first merge what I have at V4L/DVB tree, before applying > them. Has anyone ported the MSMCE driver onto these patches yet? That would be a good check to make sure that rc-core has the necessary API. Cooler if it works both through LIRC and with an internal protocol decoder. The MSMCE driver in my old patches was very simplified, it removed about half of the code from the LIRC version. > > There are two patches on this series that deserve a better analysis, IMO: > > - V4L/DVB: ir-core: rename sysfs remote controller class from ir to rc > > As discussed, "IR" is not a good name, as this infrastructure could later > be used by other types of Remote Controllers, as it has nothing that > is specific to IR inside the code, except for the name. So, I'm proposing > to replace the sysfs notes do "rc", instead of "ir". The sooner we do > such changes, the better, as userspace apps using it are still under > development. So, an API change is still possible, without causing > much hurt. > > Also, as some RC devices allow RC code transmission, we probably need to add > a TX node somewhere, associated with the same RX part (as some devices > don't allow simultaneous usage of TX and RX). > > So, we have a few alternatives for the RC device sysfs node: > a) /sys/class/rc/rc0 > |--> rx > ---> tx > b) /sys/class/rc/rcrcv0 > /sys/class/rc/rctx0 > > c) /sys/class/rc/rc0 > and have there the RX and TX nodes/attributes mixed. IMO, (b) is a bad idea, > so, I am between (a) and (c). > > - V4L/DVB: input: Add support for EVIO[CS]GKEYCODEBIG > > Adds two new ioctls in order to handle with big keycode tables. As already > said, we'll need another ioctl, in order to get the maximum keycode supported > by a given device. I didn't wrote the patch for the new ioctl yet. > This patch will probably have a small conflict with upstream input, but I > prefer to keep it on my tree and fix the upstream conflicts when submiting > it, as the rest of the new IR code is also on my tree, and this patch is > needed to procced with the IR code development. > > Mauro Carvalho Chehab (15): > V4L/DVB: ir-core: be less pedantic with RC protocol name > V4L/DVB: saa7134: use a full scancode table for M135A > V4L/DVB: saa7134: add code to allow changing IR protocol > V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core > V4L/DVB: ir-core: add two functions to report keyup/keydown events > V4L/DVB: ir-core/saa7134: Move ir keyup/keydown code to the ir-core > V4L/DVB: saa7134: don't wait too much to generate an IR event on raw_decode > V4L/DVB: ir-core: dynamically load the compiled IR protocols > V4L/DVB: ir-core: prepare to add more operations for ir decoders > V4L/DVB: ir-nec-decoder: Add sysfs node to enable/disable per irrcv > V4L/DVB: saa7134: clear warning noise > V4L/DVB: ir-core: rename sysfs remote controller class from ir to rc > V4L/DVB: ir-core: Add callbacks for input/evdev open/close on IR core > V4L/DVB: cx88: Only start IR if the input device is opened > V4L/DVB: input: Add support for EVIO[CS]GKEYCODEBIG > > drivers/input/evdev.c | 39 +++ > drivers/input/input.c | 260 ++-- > drivers/media/IR/Kconfig | 9 + > drivers/media/IR/Makefile | 3 +- > drivers/media/IR/ir-keymaps.c | 98 > drivers/media/IR/ir-keytable.c | 75 ++- > drivers/media/IR/ir-nec-decoder.c | 351 > +++ > drivers/media/IR/ir-raw-event.c | 231 ++ > drivers/media/IR/ir-sysfs.c | 29 ++- > drivers/media/video/cx88/cx88-input.c | 69 +- > drivers/media/video/cx88/cx88-video.c | 6 +- > drivers/media/video/cx88/cx88.h | 6 +- > drivers/media/video/saa7134/saa7134-core.c | 2 +- > drivers/media/video/saa7134/saa7134-input.c | 207 +++-- > drivers/media/video/saa7134/saa7134.h | 4 +- > include/linux/input.h | 40 +++- > include/media/ir-common.h | 9 +- > include/media/ir-core.h | 59 +- > 18 files changed, 1368 insertions(+), 129 deletions(-) > create mode 100644 drivers/media/IR/ir-nec-decoder.c > create mode 100644 drivers/media/IR/ir-raw-event.c > > -- > To unsubscribe
[PATCH 00/15] ir-core: Several improvements to allow adding LIRC and decoder plugins
This series of 15 patches improves support for IR, as discussed at the "What are the goals for the architecture of an in-kernel IR system?" thread. It basically adds a raw decoder layer at ir-core, allowing decoders to plug into IR core, and preparing for the addition of a lirc_dev driver that will allow raw IR codes to be sent to userspace. There's no lirc patch in this series. I have also a few other patches from David Härdeman that I'm about to test/review probably later today, but as I prefer to first merge what I have at V4L/DVB tree, before applying them. There are two patches on this series that deserve a better analysis, IMO: - V4L/DVB: ir-core: rename sysfs remote controller class from ir to rc As discussed, "IR" is not a good name, as this infrastructure could later be used by other types of Remote Controllers, as it has nothing that is specific to IR inside the code, except for the name. So, I'm proposing to replace the sysfs notes do "rc", instead of "ir". The sooner we do such changes, the better, as userspace apps using it are still under development. So, an API change is still possible, without causing much hurt. Also, as some RC devices allow RC code transmission, we probably need to add a TX node somewhere, associated with the same RX part (as some devices don't allow simultaneous usage of TX and RX). So, we have a few alternatives for the RC device sysfs node: a) /sys/class/rc/rc0 |--> rx ---> tx b) /sys/class/rc/rcrcv0 /sys/class/rc/rctx0 c) /sys/class/rc/rc0 and have there the RX and TX nodes/attributes mixed. IMO, (b) is a bad idea, so, I am between (a) and (c). - V4L/DVB: input: Add support for EVIO[CS]GKEYCODEBIG Adds two new ioctls in order to handle with big keycode tables. As already said, we'll need another ioctl, in order to get the maximum keycode supported by a given device. I didn't wrote the patch for the new ioctl yet. This patch will probably have a small conflict with upstream input, but I prefer to keep it on my tree and fix the upstream conflicts when submiting it, as the rest of the new IR code is also on my tree, and this patch is needed to procced with the IR code development. Mauro Carvalho Chehab (15): V4L/DVB: ir-core: be less pedantic with RC protocol name V4L/DVB: saa7134: use a full scancode table for M135A V4L/DVB: saa7134: add code to allow changing IR protocol V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core V4L/DVB: ir-core: add two functions to report keyup/keydown events V4L/DVB: ir-core/saa7134: Move ir keyup/keydown code to the ir-core V4L/DVB: saa7134: don't wait too much to generate an IR event on raw_decode V4L/DVB: ir-core: dynamically load the compiled IR protocols V4L/DVB: ir-core: prepare to add more operations for ir decoders V4L/DVB: ir-nec-decoder: Add sysfs node to enable/disable per irrcv V4L/DVB: saa7134: clear warning noise V4L/DVB: ir-core: rename sysfs remote controller class from ir to rc V4L/DVB: ir-core: Add callbacks for input/evdev open/close on IR core V4L/DVB: cx88: Only start IR if the input device is opened V4L/DVB: input: Add support for EVIO[CS]GKEYCODEBIG drivers/input/evdev.c | 39 +++ drivers/input/input.c | 260 ++-- drivers/media/IR/Kconfig|9 + drivers/media/IR/Makefile |3 +- drivers/media/IR/ir-keymaps.c | 98 drivers/media/IR/ir-keytable.c | 75 ++- drivers/media/IR/ir-nec-decoder.c | 351 +++ drivers/media/IR/ir-raw-event.c | 231 ++ drivers/media/IR/ir-sysfs.c | 29 ++- drivers/media/video/cx88/cx88-input.c | 69 +- drivers/media/video/cx88/cx88-video.c |6 +- drivers/media/video/cx88/cx88.h |6 +- drivers/media/video/saa7134/saa7134-core.c |2 +- drivers/media/video/saa7134/saa7134-input.c | 207 +++-- drivers/media/video/saa7134/saa7134.h |4 +- include/linux/input.h | 40 +++- include/media/ir-common.h |9 +- include/media/ir-core.h | 59 +- 18 files changed, 1368 insertions(+), 129 deletions(-) create mode 100644 drivers/media/IR/ir-nec-decoder.c create mode 100644 drivers/media/IR/ir-raw-event.c -- 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
