nuvoton-cir: Add support for user configurable wake-up codes

This patch introduces module parameters for setting wake-up codes to be programmed into the hardware FIFO. This allows users to provide custom IR sample sequences to trigger system wake-up from sleep states.

Usage:

   modprobe nuvoton-cir wake_samples=0x90,0x11,0xa1... (up to 67 bytes)

Here is a summary of module parameters introduced by this patch:
* wake_samples: FIFO values to compare against received IR codes when in sleep state.

* cmp_deep: Number of bytes the hardware will compare against. This is currently autodetected by the driver.

* cmp_tolerance: The maximum allowed value difference between a single wake-up byte and a sample read from IR to be still considered a match. Default is 5.

Signed-off-by Antti Seppälä <[email protected]>

---
 drivers/media/rc/nuvoton-cir.c | 65 +++++++++++++++++++++++++++++++-----------
 drivers/media/rc/nuvoton-cir.h |  6 ++--
 2 files changed, 51 insertions(+), 20 deletions(-)

drivers/media/rc/nuvoton-cir.c +49 -16

index 21ee0dc..b11ee43 100644
@@ -39,6 +39,15 @@
 
 #include "nuvoton-cir.h"
 
+/* debugging module parameter */
+static int debug;
+
+/* Wake up configuration parameters */
+static unsigned char wake_samples[WAKE_FIFO_LEN];
+static unsigned int num_wake_samples;
+static unsigned char cmp_deep;
+static unsigned char cmp_tolerance = CIR_WAKE_CMP_TOLERANCE;
+
 /* write val to config reg */
 static inline void nvt_cr_write(struct nvt_dev *nvt, u8 val, u8 reg)
 {

@@ -418,13 +427,38 @@ static void nvt_cir_regs_init(struct nvt_dev *nvt)
 
 static void nvt_cir_wake_regs_init(struct nvt_dev *nvt)
 {
+	int i;
+	u8 cmp_reg = CIR_WAKE_FIFO_CMP_BYTES;
+	u8 ircon_reg = CIR_WAKE_IRCON_RXEN | CIR_WAKE_IRCON_R |
+		       CIR_WAKE_IRCON_RXINV | CIR_WAKE_IRCON_SAMPLE_PERIOD_SEL;
+	/*
+	 * Enable TX and RX, specific carrier on = low, off = high, and set
+	 * sample period (currently 50us)
+	 */
+	nvt_cir_wake_reg_write(nvt, ircon_reg | CIR_WAKE_IRCON_MODE1,
+			       CIR_WAKE_IRCON);
+
+	/* clear cir wake rx fifo */
+	nvt_clear_cir_wake_fifo(nvt);
+
+	/* Write samples from module parameter to fifo */
+	for (i = 0; i < num_wake_samples; i++)
+		nvt_cir_wake_reg_write(nvt, wake_samples[i],
+				       CIR_WAKE_WR_FIFO_DATA);
+
+	/* Switch cir to wakeup mode and disable fifo writing */
+	nvt_cir_wake_reg_write(nvt, ircon_reg | CIR_WAKE_IRCON_MODE0,
+			       CIR_WAKE_IRCON);
+
 	/* set number of bytes needed for wake from s3 (default 65) */
-	nvt_cir_wake_reg_write(nvt, CIR_WAKE_FIFO_CMP_BYTES,
-			       CIR_WAKE_FIFO_CMP_DEEP);
+	if (cmp_deep)
+		cmp_reg = cmp_deep;
+	else if (num_wake_samples)
+		cmp_reg = num_wake_samples;
+	nvt_cir_wake_reg_write(nvt, cmp_reg, CIR_WAKE_FIFO_CMP_DEEP);
 
 	/* set tolerance/variance allowed per byte during wake compare */
-	nvt_cir_wake_reg_write(nvt, CIR_WAKE_CMP_TOLERANCE,
-			       CIR_WAKE_FIFO_CMP_TOL);
+	nvt_cir_wake_reg_write(nvt, cmp_tolerance, CIR_WAKE_FIFO_CMP_TOL);
 
 	/* set sample limit count (PE interrupt raised when reached) */
 	nvt_cir_wake_reg_write(nvt, CIR_RX_LIMIT_COUNT >> 8, CIR_WAKE_SLCH);

@@ -434,18 +468,6 @@ static void nvt_cir_wake_regs_init(struct nvt_dev *nvt)
 	nvt_cir_wake_reg_write(nvt, CIR_WAKE_FIFOCON_RX_TRIGGER_LEV,
 			       CIR_WAKE_FIFOCON);
 
-	/*
-	 * Enable TX and RX, specific carrier on = low, off = high, and set
-	 * sample period (currently 50us)
-	 */
-	nvt_cir_wake_reg_write(nvt, CIR_WAKE_IRCON_MODE0 | CIR_WAKE_IRCON_RXEN |
-			       CIR_WAKE_IRCON_R | CIR_WAKE_IRCON_RXINV |
-			       CIR_WAKE_IRCON_SAMPLE_PERIOD_SEL,
-			       CIR_WAKE_IRCON);
-
-	/* clear cir wake rx fifo */
-	nvt_clear_cir_wake_fifo(nvt);
-
 	/* clear any and all stray interrupts */
 	nvt_cir_wake_reg_write(nvt, 0xff, CIR_WAKE_IRSTS);
 }

@@ -1232,6 +1254,17 @@ static void nvt_exit(void)
 module_param(debug, int, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(debug, "Enable debugging output");
 
+module_param_array(wake_samples, byte, &num_wake_samples, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(wake_samples, "FIFO sample bytes triggering wake");
+
+module_param(cmp_deep, byte, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(cmp_deep, "How many bytes need to compare\n"
+			   "\t\t(0 = auto (default))");
+
+module_param(cmp_tolerance, byte, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(cmp_tolerance, "Data tolerance to each wake sample byte\n"
+				"\t\t(default = 5)");
+
 MODULE_DEVICE_TABLE(pnp, nvt_ids);
 MODULE_DESCRIPTION("Nuvoton W83667HG-A & W83677HG-I CIR driver");
 

drivers/media/rc/nuvoton-cir.h +2 -4

index 07e8310..8209f84 100644
@@ -31,10 +31,6 @@
 /* platform driver name to register */
 #define NVT_DRIVER_NAME "nuvoton-cir"
 
-/* debugging module parameter */
-static int debug;
-
-
 #define nvt_pr(level, text, ...) \
 	printk(level KBUILD_MODNAME ": " text, ## __VA_ARGS__)
 

@@ -64,6 +60,8 @@ static int debug;
 #define TX_BUF_LEN 256
 #define RX_BUF_LEN 32
 
+#define WAKE_FIFO_LEN 67
+
 struct nvt_dev {
 	struct pnp_dev *pdev;
 	struct rc_dev *rdev;

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Quoted 11 lines · Antti Seppälä

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?

This is needed for winbond-cir; I guess this should be another sysfs file, something like "wakeup_protocol". Even if the nuvoton can only handle one IR protocol, maybe it should be exported (readonly) via sysfs?

I'm happy to help with a winbond-cir implementation; I have the hardware.

Sean

Quoted 23 lines · Sean Young

Quoted 11 lines · Antti Seppälä

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?

This is needed for winbond-cir; I guess this should be another sysfs file, something like "wakeup_protocol". Even if the nuvoton can only handle one IR protocol, maybe it should be exported (readonly) via sysfs?

I'm happy to help with a winbond-cir implementation; I have the hardware.

Quoted 1 line

Sean

Nuvoton-cir doesn't care about the IR protocol because the hardware compares raw IR pulse lengths and wakes the system if received pulse is within certain tolerance of the one pre-programmed to the HW. This approach is agnostic to the used IR protocol.

I glanced over the winbond-cir driver and porting the driver to use sysfs for wakeup scancodes looks doable. Also a new sysfs entry for setting the wakeup protocol would indeed be needed... I will take a closer look at this when I have some more time.

-Antti
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 26 lines · Antti Seppälä

Quoted 24 lines · Sean Young

Quoted 11 lines · Antti Seppälä

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?

This is needed for winbond-cir; I guess this should be another sysfs file, something like "wakeup_protocol". Even if the nuvoton can only handle one IR protocol, maybe it should be exported (readonly) via sysfs?

I'm happy to help with a winbond-cir implementation; I have the hardware.

Sean

Quoted 4 lines

Nuvoton-cir doesn't care about the IR protocol because the hardware compares raw IR pulse lengths and wakes the system if received pulse is within certain tolerance of the one pre-programmed to the HW. This approach is agnostic to the used IR protocol.

Your patch talks about scancodes which is something entirely different. This should be renamed to something better.

So with the nuvoton you program a set of pulses and spaces; with the winbond you set the protocol and the scancode. I don't think there is any shared code here. Maybe it's better to implement the wakeup sysfs files in the drivers themselves rather than in rcdev, I guess that depends on whether there are other devices that implement similar functionality.

Quoted 27 lines · Sean Young

Quoted 26 lines · Antti Seppälä

Quoted 24 lines · Sean Young

Quoted 11 lines · Antti Seppälä

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?

This is needed for winbond-cir; I guess this should be another sysfs file, something like "wakeup_protocol". Even if the nuvoton can only handle one IR protocol, maybe it should be exported (readonly) via sysfs?

I'm happy to help with a winbond-cir implementation; I have the hardware.

Sean

Quoted 8 lines

Quoted 4 lines

Nuvoton-cir doesn't care about the IR protocol because the hardware compares raw IR pulse lengths and wakes the system if received pulse is within certain tolerance of the one pre-programmed to the HW. This approach is agnostic to the used IR protocol.

Your patch talks about scancodes which is something entirely different. This should be renamed to something better.

I agree that for the nuvoton my choice of wording (scancode) was a poor one. Perhaps wakeup_code would suit both drivers?

Quoted 7 lines

So with the nuvoton you program a set of pulses and spaces; with the winbond you set the protocol and the scancode. I don't think there is any shared code here. Maybe it's better to implement the wakeup sysfs files in the drivers themselves rather than in rcdev, I guess that depends on whether there are other devices that implement similar functionality.

The code to be shared is the logic of creating, parsing and formatting the sysfs file. In the end the drivers are only interested in getting a bunch of values to write to the hardware.

I was thinking about adding another file (wakeup_protocol sounds good) which would tell what semantics are used to interpret the contents of wakeup_code file (rc6, rc5, nec or raw). Would this be a decent solution?

The other alternative is to push the sysfs handling to individual drivers. I'm ok with either way. Which one should I pursue?

Quoted 27 lines · Sean Young

Quoted 26 lines · Antti Seppälä

Quoted 24 lines · Sean Young

Quoted 11 lines · Antti Seppälä

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?

This is needed for winbond-cir; I guess this should be another sysfs file, something like "wakeup_protocol". Even if the nuvoton can only handle one IR protocol, maybe it should be exported (readonly) via sysfs?

I'm happy to help with a winbond-cir implementation; I have the hardware.

Sean

Quoted 8 lines

Quoted 4 lines

Nuvoton-cir doesn't care about the IR protocol because the hardware compares raw IR pulse lengths and wakes the system if received pulse is within certain tolerance of the one pre-programmed to the HW. This approach is agnostic to the used IR protocol.

Your patch talks about scancodes which is something entirely different. This should be renamed to something better.

I agree that for the nuvoton my choice of wording (scancode) was a poor one. Perhaps wakeup_code would suit both drivers?

Quoted 7 lines

So with the nuvoton you program a set of pulses and spaces; with the winbond you set the protocol and the scancode. I don't think there is any shared code here. Maybe it's better to implement the wakeup sysfs files in the drivers themselves rather than in rcdev, I guess that depends on whether there are other devices that implement similar functionality.

The code to be shared is the logic of creating, parsing and formatting the sysfs file. In the end the drivers are only interested in getting a bunch of values to write to the hardware.

I was thinking about adding another file (wakeup_protocol sounds good) which would tell what semantics are used to interpret the contents of wakeup_code file (rc6, rc5, nec or raw). Would this be a decent solution?

Quoted 52 lines · Sean Young

Quoted 27 lines · Antti Seppälä

Quoted 26 lines · Sean Young

Quoted 24 lines · Antti Seppälä

Quoted 11 lines

This patch series introduces a simple sysfs file interface for reading and writing wakeup scancodes to rc drivers.

This is an improved version of my previous patch for nuvoton-cir which did the same thing via module parameters. This is a more generic approach allowing other drivers to utilize the interface as well.

I did not port winbond-cir to this method of wakeup scancode setting yet because I don't have the hardware to test it and I wanted first to get some comments about how the patch series looks. I did however write a simple support to read and write scancodes to rc-loopback module.

Doesn't the nuvoton-cir driver need to know the IR protocol for wakeup?

This is needed for winbond-cir; I guess this should be another sysfs file, something like "wakeup_protocol". Even if the nuvoton can only handle one IR protocol, maybe it should be exported (readonly) via sysfs?

I'm happy to help with a winbond-cir implementation; I have the hardware.

Sean

Quoted 8 lines

Quoted 4 lines

Nuvoton-cir doesn't care about the IR protocol because the hardware compares raw IR pulse lengths and wakes the system if received pulse is within certain tolerance of the one pre-programmed to the HW. This approach is agnostic to the used IR protocol.

Your patch talks about scancodes which is something entirely different. This should be renamed to something better.

I agree that for the nuvoton my choice of wording (scancode) was a poor one. Perhaps wakeup_code would suit both drivers?

Quoted 7 lines

So with the nuvoton you program a set of pulses and spaces; with the winbond you set the protocol and the scancode. I don't think there is any shared code here. Maybe it's better to implement the wakeup sysfs files in the drivers themselves rather than in rcdev, I guess that depends on whether there are other devices that implement similar functionality.

The code to be shared is the logic of creating, parsing and formatting the sysfs file. In the end the drivers are only interested in getting a bunch of values to write to the hardware.

Quoted 4 lines

I was thinking about adding another file (wakeup_protocol sounds good) which would tell what semantics are used to interpret the contents of wakeup_code file (rc6, rc5, nec or raw). Would this be a decent solution?

Good idea. I like it.

Sean

Not sure if you saw it, but there's already another patchset proposing that, that got submitted before this changeset:

        https://patchwork.linuxtv.org/patch/21625/

Quoted 3 lines

Not sure if you saw it, but there's already another patchset proposing that, that got submitted before this changeset:

        https://patchwork.linuxtv.org/patch/21625/

I actually didn't notice that until now. Seems quite a similar kind of approach with even more advanced features than what I had in mind (namely the scancode filtering and masking).

However it looks like that patchset has the same drawback about not knowing which protocol to use for the wakeup scancode as was pointed from my patch.

I think I'll try to come up with a new patch addressing the comments I've seen so far.

Em Thu, 23 Jan 2014 21:11:09 +0200
Antti Seppälä <[email protected]> escreveu:

Quoted 5 lines · Mauro Carvalho Chehab

Quoted 3 lines

Not sure if you saw it, but there's already another patchset proposing that, that got submitted before this changeset:

        https://patchwork.linuxtv.org/patch/21625/

Quoted 7 lines

I actually didn't notice that until now. Seems quite a similar kind of approach with even more advanced features than what I had in mind (namely the scancode filtering and masking).

However it looks like that patchset has the same drawback about not knowing which protocol to use for the wakeup scancode as was pointed from my patch.

Well, the protocol is important only if there are two or more active RCs that produce the same IR code on different protocols.

Also, from the sysfs description made by James, it seems clear to me that the protocol to be used is the current protocol.

I think is an unlikely border case to have some hardware that supports more than one IR protocols enabled for the wakeup to work, so James patch looks ok on my eyes.

Also, nothing prevents to add latter a wakeup_filter_protocol sysfs node to allow to filter the wakeup scancode to a protocol set different than the one(s) currently enabled.

Quoted 2 lines

I think I'll try to come up with a new patch addressing the comments I've seen so far.

I guess I'll merge James approach, as there are a pile of other patches depending on it. If we need latter to distinguish between current_protocol and the wakeup one, as I said, a latter patch can add a "wakeup_filter_protocol" sysfs node to specify it.

Regards,
Mauro

Quoted 33 lines

Em Thu, 23 Jan 2014 21:11:09 +0200
Antti Seppälä <[email protected]> escreveu:

Quoted 5 lines · Mauro Carvalho Chehab

Quoted 3 lines

Not sure if you saw it, but there's already another patchset proposing that, that got submitted before this changeset:

        https://patchwork.linuxtv.org/patch/21625/

Quoted 7 lines

I actually didn't notice that until now. Seems quite a similar kind of approach with even more advanced features than what I had in mind (namely the scancode filtering and masking).

However it looks like that patchset has the same drawback about not knowing which protocol to use for the wakeup scancode as was pointed from my patch.

Well, the protocol is important only if there are two or more active RCs that produce the same IR code on different protocols.

Also, from the sysfs description made by James, it seems clear to me that the protocol to be used is the current protocol.

I think is an unlikely border case to have some hardware that supports more than one IR protocols enabled for the wakeup to work, so James patch looks ok on my eyes.

Also, nothing prevents to add latter a wakeup_filter_protocol sysfs node to allow to filter the wakeup scancode to a protocol set different than the one(s) currently enabled.

Quoted 2 lines

I think I'll try to come up with a new patch addressing the comments I've seen so far.

Quoted 7 lines

I guess I'll merge James approach, as there are a pile of other patches depending on it. If we need latter to distinguish between current_protocol and the wakeup one, as I said, a latter patch can add a "wakeup_filter_protocol" sysfs node to specify it.

Regards,
Mauro

Hi Mauro.

How do you want to proceed with the nuvoton wakeup I initially set out to do?

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

To keep things simple maybe module parameters in my first patch
(http://www.mail-archive.com/[email protected]/msg69782.html)
are then the best thing to do for nuvoton? Other drivers can probably adapt to the suggested filter api.

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

Hi Antti,

Quoted 3 lines · Antti Seppälä

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

Do the raw pulse/space lengths your hardware requires correspond to a single IR packet (mapping to a single scancode)?

If so then my API is simply at a higher level of abstraction. I think this has the following advantages:
* userspace sees a consistent interface at the same level of abstraction as it already has access to from input subsystem (i.e. scancodes). I.e. it doesn't need to care which IR device is in use, whether it does raw/hardware decode, or the details of the timings of the current protocol.
* it supports hardware decoders which filter on the demodulated data rather than the raw pulse/space lengths.

Of course to support this we'd need some per-protocol code to convert a scancode back to pulse/space lengths. I'd like to think that code could be generic, maybe as helper functions which multiple drivers could use, which could also handle corner cases of the API in a consistent way (e.g. user providing filter mask covering multiple scancodes, which presumably pulse/space).

I see I've just crossed emails with Mauro who has just suggested something similar. I agree that his (2) is the more elegant option.

Cheers
James

Quoted 19 lines · James Hogan

Hi Antti,

Quoted 3 lines · Antti Seppälä

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

Do the raw pulse/space lengths your hardware requires correspond to a single IR packet (mapping to a single scancode)?

If so then my API is simply at a higher level of abstraction. I think this has the following advantages:
* userspace sees a consistent interface at the same level of abstraction as it already has access to from input subsystem (i.e. scancodes). I.e. it doesn't need to care which IR device is in use, whether it does raw/hardware decode, or the details of the timings of the current protocol.
* it supports hardware decoders which filter on the demodulated data rather than the raw pulse/space lengths.

Quoted 6 lines

Of course to support this we'd need some per-protocol code to convert a scancode back to pulse/space lengths. I'd like to think that code could be generic, maybe as helper functions which multiple drivers could use, which could also handle corner cases of the API in a consistent way (e.g. user providing filter mask covering multiple scancodes, which presumably pulse/space).

hmm, I didn't complete that sentence :(.
I meant:
..., which presumably pulse/space can't really represent very easily).

Cheers
James

Quoted 4 lines

I see I've just crossed emails with Mauro who has just suggested something similar. I agree that his (2) is the more elegant option.

Quoted 27 lines · James Hogan

Quoted 19 lines

Hi Antti,

Quoted 3 lines · Antti Seppälä

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

Do the raw pulse/space lengths your hardware requires correspond to a single IR packet (mapping to a single scancode)?

If so then my API is simply at a higher level of abstraction. I think this has the following advantages:
* userspace sees a consistent interface at the same level of abstraction as it already has access to from input subsystem (i.e. scancodes). I.e. it doesn't need to care which IR device is in use, whether it does raw/hardware decode, or the details of the timings of the current protocol.
* it supports hardware decoders which filter on the demodulated data rather than the raw pulse/space lengths.

Quoted 6 lines

Of course to support this we'd need some per-protocol code to convert a scancode back to pulse/space lengths. I'd like to think that code could be generic, maybe as helper functions which multiple drivers could use, which could also handle corner cases of the API in a consistent way (e.g. user providing filter mask covering multiple scancodes, which presumably pulse/space).

Quoted 11 lines

hmm, I didn't complete that sentence :(.
I meant:
..., which presumably pulse/space can't really represent very easily).

Cheers
James

Quoted 4 lines

I see I've just crossed emails with Mauro who has just suggested something similar. I agree that his (2) is the more elegant option.

Yes, in nuvoton the ir pulses correspond to a scancode (or part of a scancode)

After giving it some thought I agree that using scancodes is the most elegant way for specifying wakeup commands. Too bad that nuvoton does not work with scancodes.
I pretty much agree with Mauro that the right solution would be to write an IR encoder and use it to convert the given scancode back to a format understood by nuvoton.

Writing IR encoders for all the protocols and an encoder selector functionality is quite labourous and sadly I don't have time for that anytime soon. If anyone wants to step up I'd be more than happy to help though :)

Em Wed, 05 Feb 2014 20:16:04 +0200
Antti Seppälä <[email protected]> escreveu:

Quoted 42 lines · James Hogan

Quoted 27 lines · James Hogan

Quoted 19 lines

Hi Antti,

Quoted 3 lines · Antti Seppälä

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

Do the raw pulse/space lengths your hardware requires correspond to a single IR packet (mapping to a single scancode)?

If so then my API is simply at a higher level of abstraction. I think this has the following advantages:
* userspace sees a consistent interface at the same level of abstraction as it already has access to from input subsystem (i.e. scancodes). I.e. it doesn't need to care which IR device is in use, whether it does raw/hardware decode, or the details of the timings of the current protocol.
* it supports hardware decoders which filter on the demodulated data rather than the raw pulse/space lengths.

Quoted 6 lines

Of course to support this we'd need some per-protocol code to convert a scancode back to pulse/space lengths. I'd like to think that code could be generic, maybe as helper functions which multiple drivers could use, which could also handle corner cases of the API in a consistent way (e.g. user providing filter mask covering multiple scancodes, which presumably pulse/space).

Quoted 11 lines

hmm, I didn't complete that sentence :(.
I meant:
..., which presumably pulse/space can't really represent very easily).

Cheers
James

Quoted 4 lines

I see I've just crossed emails with Mauro who has just suggested something similar. I agree that his (2) is the more elegant option.

Yes, in nuvoton the ir pulses correspond to a scancode (or part of a scancode)

Quoted 6 lines

After giving it some thought I agree that using scancodes is the most elegant way for specifying wakeup commands. Too bad that nuvoton does not work with scancodes.
I pretty much agree with Mauro that the right solution would be to write an IR encoder and use it to convert the given scancode back to a format understood by nuvoton.

Ok, as we all agreed, I'll merge the remaining patches from James.

Quoted 5 lines

Writing IR encoders for all the protocols and an encoder selector functionality is quite labourous and sadly I don't have time for that anytime soon. If anyone wants to step up I'd be more than happy to help though :)

I suspect that writing one IR encoder should not be hard, as there are already some on LIRC userspace.

I would love to have some time to write at least a few IR encoders, but, unfortunately, I would not have any time soon.

Quoted 52 lines

Em Wed, 05 Feb 2014 20:16:04 +0200
Antti Seppälä <[email protected]> escreveu:

Quoted 48 lines · James Hogan

Quoted 27 lines · James Hogan

Quoted 19 lines

Hi Antti,

Quoted 3 lines · Antti Seppälä

To wake up with nuvoton-cir we need to program several raw ir pulse/space lengths to the hardware and not a scancode. James's approach doesn't support this.

Do the raw pulse/space lengths your hardware requires correspond to a single IR packet (mapping to a single scancode)?

If so then my API is simply at a higher level of abstraction. I think this has the following advantages:
* userspace sees a consistent interface at the same level of abstraction as it already has access to from input subsystem (i.e. scancodes). I.e. it doesn't need to care which IR device is in use, whether it does raw/hardware decode, or the details of the timings of the current protocol.
* it supports hardware decoders which filter on the demodulated data rather than the raw pulse/space lengths.

Quoted 6 lines

Of course to support this we'd need some per-protocol code to convert a scancode back to pulse/space lengths. I'd like to think that code could be generic, maybe as helper functions which multiple drivers could use, which could also handle corner cases of the API in a consistent way (e.g. user providing filter mask covering multiple scancodes, which presumably pulse/space).

Quoted 11 lines

hmm, I didn't complete that sentence :(.
I meant:
..., which presumably pulse/space can't really represent very easily).

Cheers
James

Quoted 4 lines

I see I've just crossed emails with Mauro who has just suggested something similar. I agree that his (2) is the more elegant option.

Yes, in nuvoton the ir pulses correspond to a scancode (or part of a scancode)

After giving it some thought I agree that using scancodes is the most elegant way for specifying wakeup commands. Too bad that nuvoton does not work with scancodes.
I pretty much agree with Mauro that the right solution would be to write an IR encoder and use it to convert the given scancode back to a format understood by nuvoton.

Quoted 1 line

Ok, as we all agreed, I'll merge the remaining patches from James.

Thanks :)

Quoted 9 lines

Quoted 5 lines

Writing IR encoders for all the protocols and an encoder selector functionality is quite labourous and sadly I don't have time for that anytime soon. If anyone wants to step up I'd be more than happy to help though :)

I suspect that writing one IR encoder should not be hard, as there are already some on LIRC userspace.

Quoted 2 lines

I would love to have some time to write at least a few IR encoders, but, unfortunately, I would not have any time soon.

For fun, I did some experimentation yesterday evening with adding basic generic IR encoding (just NEC implemented so far). Encoders can certainly be a lot simpler than decoders.

I'll submit a few RFC patches later so Antti can see whether it would be suitable for nuvoton.