[PATCH 0/2] Improve imon LCD/VFD driver to better support 15c2:0036

[PATCH 0/2] Improve imon LCD/VFD driver to better support 15c2:0036

[Kevin Baradon]

Hi,

Please find those two short patches to improve support of (at least) 15c2:0036 imon device.
These apply on latest git and were tested on 3.7.8 and 3.7.9 kernels.

Thanks.

Kevin Baradon (2):
  media/rc/imon.c: make send_packet() delay configurable
  media/rc/imon.c: avoid flooding syslog with "unknown keypress" when keypad is pressed

 drivers/media/rc/imon.c |   29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

-- 
1.7.10.4

[PATCH 1/2] media/rc/imon.c: make send_packet() delay configurable

[Kevin Baradon]

Some imon devices (like 15c2:0036) need a higher delay between send_packet calls.
Default value is still 5ms to avoid regressions on already working hardware.

Also use interruptible wait to avoid load average going too high (and let caller handle signals).

Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
---
 drivers/media/rc/imon.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 78d109b..a3e66a0 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -347,6 +347,11 @@ module_param(pad_stabilize, int, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(pad_stabilize, "Apply stabilization algorithm to iMON PAD "
 		 "presses in arrow key mode. 0=disable, 1=enable (default).");
 
+static unsigned int send_packet_delay = 5;
+module_param(send_packet_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(send_packet_delay, "Minimum delay between send_packet() calls "
+		 "(default 5ms)");
+
 /*
  * In certain use cases, mouse mode isn't really helpful, and could actually
  * cause confusion, so allow disabling it when the IR device is open.
@@ -535,12 +540,15 @@ static int send_packet(struct imon_context *ictx)
 	kfree(control_req);
 
 	/*
-	 * Induce a mandatory 5ms delay before returning, as otherwise,
+	 * Induce a mandatory delay before returning, as otherwise,
 	 * send_packet can get called so rapidly as to overwhelm the device,
 	 * particularly on faster systems and/or those with quirky usb.
+	 * Do not use TASK_UNINTERRUPTIBLE as this routine is called quite often
+	 * and doing so will increase load average slightly. Caller will handle
+	 * signals itself.
 	 */
-	timeout = msecs_to_jiffies(5);
-	set_current_state(TASK_UNINTERRUPTIBLE);
+	timeout = msecs_to_jiffies(send_packet_delay);
+	set_current_state(TASK_INTERRUPTIBLE);
 	schedule_timeout(timeout);
 
 	return retval;
-- 
1.7.10.4

Re: [PATCH 1/2] media/rc/imon.c: make send_packet() delay configurable

[Mauro Carvalho Chehab]

Em Sun, 24 Feb 2013 21:19:29 +0100
Kevin Baradon <kevin.baradon@gmail.com> escreveu:

> Some imon devices (like 15c2:0036) need a higher delay between send_packet calls.
> Default value is still 5ms to avoid regressions on already working hardware.
> 
> Also use interruptible wait to avoid load average going too high (and let caller handle signals).
> 
> Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
> ---
>  drivers/media/rc/imon.c |   14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> index 78d109b..a3e66a0 100644
> --- a/drivers/media/rc/imon.c
> +++ b/drivers/media/rc/imon.c
> @@ -347,6 +347,11 @@ module_param(pad_stabilize, int, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(pad_stabilize, "Apply stabilization algorithm to iMON PAD "
>  		 "presses in arrow key mode. 0=disable, 1=enable (default).");
>  
> +static unsigned int send_packet_delay = 5;
> +module_param(send_packet_delay, uint, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(send_packet_delay, "Minimum delay between send_packet() calls "
> +		 "(default 5ms)");
> +

Users will find a hard time discovering what delay is needed for each device.

If this is a per-device type property, then it should, instead, be associated
with the device's USB ID.

The better would be to encapsulate it at the USB device table, like adding a
NEED_(extra)_DELAY flag, like:

	{ USB_DEVICE(0x15c2, 0x0036),  .driver_info = NEED_10MS_DELAY },

If such flag is zero (like on all devices where .driver_info is not filled, as
Kernel zeroes the memory on all static vars), then it will keep using 5ms.

Another alternative would be to use .driver_info for the device type, and
add a logic to handle different types with different logic. This is what
mceusb.c does, for example.

>  /*
>   * In certain use cases, mouse mode isn't really helpful, and could actually
>   * cause confusion, so allow disabling it when the IR device is open.
> @@ -535,12 +540,15 @@ static int send_packet(struct imon_context *ictx)
>  	kfree(control_req);
>  
>  	/*
> -	 * Induce a mandatory 5ms delay before returning, as otherwise,
> +	 * Induce a mandatory delay before returning, as otherwise,
>  	 * send_packet can get called so rapidly as to overwhelm the device,
>  	 * particularly on faster systems and/or those with quirky usb.
> +	 * Do not use TASK_UNINTERRUPTIBLE as this routine is called quite often
> +	 * and doing so will increase load average slightly. Caller will handle
> +	 * signals itself.
>  	 */
> -	timeout = msecs_to_jiffies(5);
> -	set_current_state(TASK_UNINTERRUPTIBLE);
> +	timeout = msecs_to_jiffies(send_packet_delay);
> +	set_current_state(TASK_INTERRUPTIBLE);
>  	schedule_timeout(timeout);
>  
>  	return retval;

Regards,
Mauro

Re: [PATCH 1/2] media/rc/imon.c: make send_packet() delay configurable

[Kevin Baradon]

Le Thu, 14 Mar 2013 12:01:53 -0300,
Mauro Carvalho Chehab <mchehab@redhat.com> a écrit :

> Em Sun, 24 Feb 2013 21:19:29 +0100
> Kevin Baradon <kevin.baradon@gmail.com> escreveu:
> 
> > Some imon devices (like 15c2:0036) need a higher delay between send_packet calls.
> > Default value is still 5ms to avoid regressions on already working hardware.
> > 
> > Also use interruptible wait to avoid load average going too high (and let caller handle signals).
> > 
> > Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
> > ---
> >  drivers/media/rc/imon.c |   14 +++++++++++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> > index 78d109b..a3e66a0 100644
> > --- a/drivers/media/rc/imon.c
> > +++ b/drivers/media/rc/imon.c
> > @@ -347,6 +347,11 @@ module_param(pad_stabilize, int, S_IRUGO | S_IWUSR);
> >  MODULE_PARM_DESC(pad_stabilize, "Apply stabilization algorithm to iMON PAD "
> >  		 "presses in arrow key mode. 0=disable, 1=enable (default).");
> >  
> > +static unsigned int send_packet_delay = 5;
> > +module_param(send_packet_delay, uint, S_IRUGO | S_IWUSR);
> > +MODULE_PARM_DESC(send_packet_delay, "Minimum delay between send_packet() calls "
> > +		 "(default 5ms)");
> > +
> 
> Users will find a hard time discovering what delay is needed for each device.
> 
> If this is a per-device type property, then it should, instead, be associated
> with the device's USB ID.
> 
> The better would be to encapsulate it at the USB device table, like adding a
> NEED_(extra)_DELAY flag, like:
> 
> 	{ USB_DEVICE(0x15c2, 0x0036),  .driver_info = NEED_10MS_DELAY },
> 
> If such flag is zero (like on all devices where .driver_info is not filled, as
> Kernel zeroes the memory on all static vars), then it will keep using 5ms.
> 
> Another alternative would be to use .driver_info for the device type, and
> add a logic to handle different types with different logic. This is what
> mceusb.c does, for example.
> 

Hi,

Please find below an updated patch:


>From 8d4ba61cb21617b8169127b085332ed7813470c9 Mon Sep 17 00:00:00 2001
From: Kevin Baradon <kevin.baradon@gmail.com>
Date: Mon, 18 Feb 2013 18:42:47 +0100
Subject: [PATCH 1/2] media/rc/imon.c: make send_packet() delay larger for 15c2:0036

Imon device 15c2:0036 need a higher delay between send_packet() calls.
Also use interruptible wait to avoid load average going too high (and let caller handle signals).

Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
---
 drivers/media/rc/imon.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index dec203b..178b946 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -112,6 +112,7 @@ struct imon_context {
 	bool tx_control;
 	unsigned char usb_rx_buf[8];
 	unsigned char usb_tx_buf[8];
+	unsigned int send_packet_delay;
 
 	struct tx_t {
 		unsigned char data_buf[35];	/* user data buffer */
@@ -185,6 +186,10 @@ enum {
 	IMON_KEY_PANEL	= 2,
 };
 
+enum {
+	IMON_NEED_20MS_PKT_DELAY = 1
+};
+
 /*
  * USB Device ID for iMON USB Control Boards
  *
@@ -215,7 +220,7 @@ static struct usb_device_id imon_usb_id_table[] = {
 	/* SoundGraph iMON OEM Touch LCD (IR & 4.3" VGA LCD) */
 	{ USB_DEVICE(0x15c2, 0x0035) },
 	/* SoundGraph iMON OEM VFD (IR & VFD) */
-	{ USB_DEVICE(0x15c2, 0x0036) },
+	{ USB_DEVICE(0x15c2, 0x0036), .driver_info = IMON_NEED_20MS_PKT_DELAY },
 	/* device specifics unknown */
 	{ USB_DEVICE(0x15c2, 0x0037) },
 	/* SoundGraph iMON OEM LCD (IR & LCD) */
@@ -535,12 +540,12 @@ static int send_packet(struct imon_context *ictx)
 	kfree(control_req);
 
 	/*
-	 * Induce a mandatory 5ms delay before returning, as otherwise,
+	 * Induce a mandatory delay before returning, as otherwise,
 	 * send_packet can get called so rapidly as to overwhelm the device,
 	 * particularly on faster systems and/or those with quirky usb.
 	 */
-	timeout = msecs_to_jiffies(5);
-	set_current_state(TASK_UNINTERRUPTIBLE);
+	timeout = msecs_to_jiffies(ictx->send_packet_delay);
+	set_current_state(TASK_INTERRUPTIBLE);
 	schedule_timeout(timeout);
 
 	return retval;
@@ -2335,6 +2340,10 @@ static int imon_probe(struct usb_interface *interface,
 
 	}
 
+	/* default send_packet delay is 5ms but some devices need more */
+	ictx->send_packet_delay = id->driver_info & IMON_NEED_20MS_PKT_DELAY ?
+				  20 : 5;
+
 	usb_set_intfdata(interface, ictx);
 
 	if (ifnum == 0) {
-- 
1.7.10.4


> >  /*
> >   * In certain use cases, mouse mode isn't really helpful, and could actually
> >   * cause confusion, so allow disabling it when the IR device is open.
> > @@ -535,12 +540,15 @@ static int send_packet(struct imon_context *ictx)
> >  	kfree(control_req);
> >  
> >  	/*
> > -	 * Induce a mandatory 5ms delay before returning, as otherwise,
> > +	 * Induce a mandatory delay before returning, as otherwise,
> >  	 * send_packet can get called so rapidly as to overwhelm the device,
> >  	 * particularly on faster systems and/or those with quirky usb.
> > +	 * Do not use TASK_UNINTERRUPTIBLE as this routine is called quite often
> > +	 * and doing so will increase load average slightly. Caller will handle
> > +	 * signals itself.
> >  	 */
> > -	timeout = msecs_to_jiffies(5);
> > -	set_current_state(TASK_UNINTERRUPTIBLE);
> > +	timeout = msecs_to_jiffies(send_packet_delay);
> > +	set_current_state(TASK_INTERRUPTIBLE);
> >  	schedule_timeout(timeout);
> >  
> >  	return retval;
> 
> Regards,
> Mauro

Regards,
Kevin

[PATCH 2/2] media/rc/imon.c: avoid flooding syslog with "unknown keypress" when keypad is pressed

[Kevin Baradon]

My 15c2:0036 device floods syslog when a keypad key is pressed:

Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fef2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2

This patch lowers severity of this message when key appears to be coming from keypad.

Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
---
 drivers/media/rc/imon.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index a3e66a0..bca03d4 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1499,7 +1499,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
 	int i;
 	u64 scancode;
 	int press_type = 0;
-	int msec;
+	int msec, is_pad_key = 0;
 	struct timeval t;
 	static struct timeval prev_time = { 0, 0 };
 	u8 ktype;
@@ -1562,6 +1562,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
 	    ((len == 8) && (buf[0] & 0x40) &&
 	     !(buf[1] & 0x1 || buf[1] >> 2 & 0x1))) {
 		len = 8;
+		is_pad_key = 1;
 		imon_pad_to_keys(ictx, buf);
 	}
 
@@ -1625,8 +1626,16 @@ static void imon_incoming_packet(struct imon_context *ictx,
 
 unknown_key:
 	spin_unlock_irqrestore(&ictx->kc_lock, flags);
-	dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
-		 (long long)scancode);
+	/*
+	 * On some devices syslog is flooded with unknown keypresses when keypad
+	 * is pressed. Lower message severity in that case.
+	 */
+	if (!is_pad_key)
+		dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
+			 (long long)scancode);
+	else
+		dev_dbg(dev, "%s: unknown keypad keypress, code 0x%llx\n",
+			__func__, (long long)scancode);
 	return;
 
 not_input_data:
-- 
1.7.10.4

Re: [PATCH 2/2] media/rc/imon.c: avoid flooding syslog with "unknown keypress" when keypad is pressed

[Mauro Carvalho Chehab]

Em Sun, 24 Feb 2013 21:19:30 +0100
Kevin Baradon <kevin.baradon@gmail.com> escreveu:

> My 15c2:0036 device floods syslog when a keypad key is pressed:
> 
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fef2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> 
> This patch lowers severity of this message when key appears to be coming from keypad.
> 
> Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
> ---
>  drivers/media/rc/imon.c |   15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> index a3e66a0..bca03d4 100644
> --- a/drivers/media/rc/imon.c
> +++ b/drivers/media/rc/imon.c
> @@ -1499,7 +1499,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
>  	int i;
>  	u64 scancode;
>  	int press_type = 0;
> -	int msec;
> +	int msec, is_pad_key = 0;
>  	struct timeval t;
>  	static struct timeval prev_time = { 0, 0 };
>  	u8 ktype;
> @@ -1562,6 +1562,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
>  	    ((len == 8) && (buf[0] & 0x40) &&
>  	     !(buf[1] & 0x1 || buf[1] >> 2 & 0x1))) {
>  		len = 8;
> +		is_pad_key = 1;
>  		imon_pad_to_keys(ictx, buf);
>  	}
>  
> @@ -1625,8 +1626,16 @@ static void struct imon_context *ictx,
>  
>  unknown_key:
>  	spin_unlock_irqrestore(&ictx->kc_lock, flags);
> -	dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
> -		 (long long)scancode);
> +	/*
> +	 * On some devices syslog is flooded with unknown keypresses when keypad
> +	 * is pressed. Lower message severity in that case.
> +	 */
> +	if (!is_pad_key)
> +		dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
> +			 (long long)scancode);
> +	else
> +		dev_dbg(dev, "%s: unknown keypad keypress, code 0x%llx\n",
> +			__func__, (long long)scancode);

Hmmm... this entire logic looks weird to me. IMO, the proper fix is to
remove this code snippet from imon_incoming_packet():

	spin_lock_irqsave(&ictx->kc_lock, flags);
	if (ictx->kc == KEY_UNKNOWN)
		goto unknown_key;
	spin_unlock_irqrestore(&ictx->kc_lock, flags);

and similar logic from other parts of the code, and just let rc_keydown()
to be handled for KEY_UNKNOWN.

rc_keydown() actually produces two input events:
	input_event(dev->input_dev, EV_MSC, MSC_SCAN, scancode);
	input_event(dev, EV_KEY, code, !!value);

(the last one, indirectly, by calling input_report_key)

In this particular case, the fist event will allow userspace programs
like "rc-keycode -t" to detect that an unknown scancode was produced,
helping the user to properly fill the scancode table for a particular device.

In the case of your remote, you'll likely will want to add support for those
currently unknown scancodes.

Those "unkonwn keypad keypress" type of messages are now obsolete, as users
can get it anytime in userspace, using the appropriate tool (ir-keytable,
with is part of v4l-utils).

Regards,
Mauro

Re: [PATCH 2/2] media/rc/imon.c: avoid flooding syslog with "unknown keypress" when keypad is pressed

[Mauro Carvalho Chehab]

Em Sun, 24 Feb 2013 21:19:30 +0100
Kevin Baradon <kevin.baradon@gmail.com> escreveu:

> My 15c2:0036 device floods syslog when a keypad key is pressed:
> 
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fef2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> 
> This patch lowers severity of this message when key appears to be coming from keypad.
> 
> Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
> ---
>  drivers/media/rc/imon.c |   15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> index a3e66a0..bca03d4 100644
> --- a/drivers/media/rc/imon.c
> +++ b/drivers/media/rc/imon.c
> @@ -1499,7 +1499,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
>  	int i;
>  	u64 scancode;
>  	int press_type = 0;
> -	int msec;
> +	int msec, is_pad_key = 0;
>  	struct timeval t;
>  	static struct timeval prev_time = { 0, 0 };
>  	u8 ktype;
> @@ -1562,6 +1562,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
>  	    ((len == 8) && (buf[0] & 0x40) &&
>  	     !(buf[1] & 0x1 || buf[1] >> 2 & 0x1))) {
>  		len = 8;
> +		is_pad_key = 1;
>  		imon_pad_to_keys(ictx, buf);
>  	}
>  
> @@ -1625,8 +1626,16 @@ static void struct imon_context *ictx,
>  
>  unknown_key:
>  	spin_unlock_irqrestore(&ictx->kc_lock, flags);
> -	dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
> -		 (long long)scancode);
> +	/*
> +	 * On some devices syslog is flooded with unknown keypresses when keypad
> +	 * is pressed. Lower message severity in that case.
> +	 */
> +	if (!is_pad_key)
> +		dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
> +			 (long long)scancode);
> +	else
> +		dev_dbg(dev, "%s: unknown keypad keypress, code 0x%llx\n",
> +			__func__, (long long)scancode);

Hmmm... this entire logic looks weird to me. IMO, the proper fix is to
remove this code snippet from imon_incoming_packet():

	spin_lock_irqsave(&ictx->kc_lock, flags);
	if (ictx->kc == KEY_UNKNOWN)
		goto unknown_key;
	spin_unlock_irqrestore(&ictx->kc_lock, flags);

and similar logic from other parts of the code, and just let rc_keydown()
to be handled for KEY_UNKNOWN.

rc_keydown() actually produces two input events:
	input_event(dev->input_dev, EV_MSC, MSC_SCAN, scancode);
	input_event(dev, EV_KEY, code, !!value);

(the last one, indirectly, by calling input_report_key)

In this particular case, the fist event will allow userspace programs
like "rc-keycode -t" to detect that an unknown scancode was produced,
helping the user to properly fill the scancode table for a particular device.

In the case of your remote, you'll likely will want to add support for those
currently unknown scancodes.

Those "unkonwn keypad keypress" type of messages are now obsolete, as users
can get it anytime in userspace, using the appropriate tool (ir-keytable,
with is part of v4l-utils).

Regards,
Mauro

Re: [PATCH 2/2] media/rc/imon.c: avoid flooding syslog with "unknown keypress" when keypad is pressed

[Kevin Baradon]

Le Thu, 14 Mar 2013 12:18:41 -0300,
Mauro Carvalho Chehab <mchehab@redhat.com> a écrit :

> Em Sun, 24 Feb 2013 21:19:30 +0100
> Kevin Baradon <kevin.baradon@gmail.com> escreveu:
> 
> > My 15c2:0036 device floods syslog when a keypad key is pressed:
> > 
> > Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> > Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fef2
> > Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> > Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> > Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
> > 
> > This patch lowers severity of this message when key appears to be coming from keypad.
> > 
> > Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
> > ---
> >  drivers/media/rc/imon.c |   15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
> > index a3e66a0..bca03d4 100644
> > --- a/drivers/media/rc/imon.c
> > +++ b/drivers/media/rc/imon.c
> > @@ -1499,7 +1499,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
> >  	int i;
> >  	u64 scancode;
> >  	int press_type = 0;
> > -	int msec;
> > +	int msec, is_pad_key = 0;
> >  	struct timeval t;
> >  	static struct timeval prev_time = { 0, 0 };
> >  	u8 ktype;
> > @@ -1562,6 +1562,7 @@ static void imon_incoming_packet(struct imon_context *ictx,
> >  	    ((len == 8) && (buf[0] & 0x40) &&
> >  	     !(buf[1] & 0x1 || buf[1] >> 2 & 0x1))) {
> >  		len = 8;
> > +		is_pad_key = 1;
> >  		imon_pad_to_keys(ictx, buf);
> >  	}
> >  
> > @@ -1625,8 +1626,16 @@ static void struct imon_context *ictx,
> >  
> >  unknown_key:
> >  	spin_unlock_irqrestore(&ictx->kc_lock, flags);
> > -	dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
> > -		 (long long)scancode);
> > +	/*
> > +	 * On some devices syslog is flooded with unknown keypresses when keypad
> > +	 * is pressed. Lower message severity in that case.
> > +	 */
> > +	if (!is_pad_key)
> > +		dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
> > +			 (long long)scancode);
> > +	else
> > +		dev_dbg(dev, "%s: unknown keypad keypress, code 0x%llx\n",
> > +			__func__, (long long)scancode);
> 
> Hmmm... this entire logic looks weird to me. IMO, the proper fix is to
> remove this code snippet from imon_incoming_packet():
> 
> 	spin_lock_irqsave(&ictx->kc_lock, flags);
> 	if (ictx->kc == KEY_UNKNOWN)
> 		goto unknown_key;
> 	spin_unlock_irqrestore(&ictx->kc_lock, flags);
> 
> and similar logic from other parts of the code, and just let rc_keydown()
> to be handled for KEY_UNKNOWN.
> 
> rc_keydown() actually produces two input events:
> 	input_event(dev->input_dev, EV_MSC, MSC_SCAN, scancode);
> 	input_event(dev, EV_KEY, code, !!value);
> 
> (the last one, indirectly, by calling input_report_key)
> 
> In this particular case, the fist event will allow userspace programs
> like "rc-keycode -t" to detect that an unknown scancode was produced,
> helping the user to properly fill the scancode table for a particular device.
> 
> In the case of your remote, you'll likely will want to add support for those
> currently unknown scancodes.
> 
> Those "unkonwn keypad keypress" type of messages are now obsolete, as users
> can get it anytime in userspace, using the appropriate tool (ir-keytable,
> with is part of v4l-utils).

Hi

Here is an updated version:


>From a9b4ea2a0211fc319887590efb9e772d1d16f817 Mon Sep 17 00:00:00 2001
From: Kevin Baradon <kevin.baradon@gmail.com>
Date: Mon, 18 Feb 2013 19:10:22 +0100
Subject: [PATCH 2/2] media/rc/imon.c: avoid flooding syslog with "unknown keypress" when keypad is pressed

My 15c2:0036 device floods syslog when a keypad key is pressed:

Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fef2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2
Feb 18 19:00:57 homeserver kernel: imon 5-1:1.0: imon_incoming_packet: unknown keypress, code 0x100fff2

This patch removes those messages from imon, following suggestion from Mauro. Unknown keys shall be correctly handled by rc/input layer.

Signed-off-by: Kevin Baradon <kevin.baradon@gmail.com>
---
 drivers/media/rc/imon.c |   11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 178b946..b8f9f85 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1573,11 +1573,6 @@ static void imon_incoming_packet(struct imon_context *ictx,
 	if (press_type < 0)
 		goto not_input_data;
 
-	spin_lock_irqsave(&ictx->kc_lock, flags);
-	if (ictx->kc == KEY_UNKNOWN)
-		goto unknown_key;
-	spin_unlock_irqrestore(&ictx->kc_lock, flags);
-
 	if (ktype != IMON_KEY_PANEL) {
 		if (press_type == 0)
 			rc_keyup(ictx->rdev);
@@ -1620,12 +1615,6 @@ static void imon_incoming_packet(struct imon_context *ictx,
 
 	return;
 
-unknown_key:
-	spin_unlock_irqrestore(&ictx->kc_lock, flags);
-	dev_info(dev, "%s: unknown keypress, code 0x%llx\n", __func__,
-		 (long long)scancode);
-	return;
-
 not_input_data:
 	if (len != 8) {
 		dev_warn(dev, "imon %s: invalid incoming packet "
-- 
1.7.10.4



> 
> Regards,
> Mauro

Regards,
Kevin