Skip to contentSkip to conversation

Updated Mantis VP-2033 remote control patch for Manu's jusst.de Mantis branch

linux-dvb Pauli Borodulin 4 participants 11 messages May 16, 2008 – May 24, 2008 2 messages not in the archive Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

Heya!

Since there has been some direct requests for this via email, I'm posting a updated version of Kristian Slavov's original remote control patch[1] for Manu's jusst.de Mantis branch. The new version is functionally the same as the one I posted in March[2].

I have adapted the patch for the current driver tree and moved ir_codes back to ir-keymaps.c & ir-common.h to follow the standard kernel procedure for the IR stuff. The patch is against the current driver tree (cd1fc4c7f1d8).

[1] http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017279.html
[2] http://www.linuxtv.org/pipermail/linux-dvb/2008-March/024301.html

Regards,
Pauli Borodulin

linux/drivers/media/common/ir-keymaps.c +65 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/common/ir-keymaps.c mantis-cd1fc4c7f1d8/linux/drivers/media/common/ir-keymaps.c
@@ -2037,3 +2037,68 @@
 };
 
 EXPORT_SYMBOL_GPL(ir_codes_behold);
+
+/* Twinhan CAB-CI 2033 */
+IR_KEYTAB_TYPE ir_codes_mantis_vp2033[IR_KEYTAB_SIZE] = {
+	[ 0x29 ] = KEY_POWER,
+	[ 0x28 ] = KEY_FAVORITES,
+	[ 0x30 ] = KEY_TEXT,
+	[ 0x17 ] = KEY_INFO,		// Preview
+	[ 0x23 ] = KEY_EPG,
+	[ 0x3b ] = KEY_F22,		// Record List
+
+	[ 0x3c ] = KEY_1,
+	[ 0x3e ] = KEY_2,
+	[ 0x39 ] = KEY_3,
+	[ 0x36 ] = KEY_4,
+	[ 0x22 ] = KEY_5,
+	[ 0x20 ] = KEY_6,
+	[ 0x32 ] = KEY_7,
+	[ 0x26 ] = KEY_8,
+	[ 0x24 ] = KEY_9,
+	[ 0x2a ] = KEY_0,
+
+	[ 0x33 ] = KEY_CANCEL,
+	[ 0x2c ] = KEY_BACK,
+	[ 0x15 ] = KEY_CLEAR,
+	[ 0x3f ] = KEY_TAB,
+	[ 0x10 ] = KEY_ENTER,
+	[ 0x14 ] = KEY_UP,
+	[ 0x0d ] = KEY_RIGHT,
+	[ 0x0e ] = KEY_DOWN,
+	[ 0x11 ] = KEY_LEFT,
+
+	[ 0x21 ] = KEY_VOLUMEUP,
+	[ 0x35 ] = KEY_VOLUMEDOWN,
+	[ 0x3d ] = KEY_CHANNELDOWN,
+	[ 0x3a ] = KEY_CHANNELUP,
+	[ 0x2e ] = KEY_RECORD,
+	[ 0x2b ] = KEY_PLAY,
+	[ 0x13 ] = KEY_PAUSE,
+	[ 0x25 ] = KEY_STOP,
+
+	[ 0x1f ] = KEY_REWIND,
+	[ 0x2d ] = KEY_FASTFORWARD,
+	[ 0x1e ] = KEY_PREVIOUS,	// Replay |<
+	[ 0x1d ] = KEY_NEXT,		// Skip   >|
+
+	[ 0x0b ] = KEY_CAMERA,		// Capture
+	[ 0x0f ] = KEY_LANGUAGE,	// SAP
+	[ 0x18 ] = KEY_MODE,		// PIP
+	[ 0x12 ] = KEY_ZOOM,		// Full screen,
+	[ 0x1c ] = KEY_SUBTITLE,
+	[ 0x2f ] = KEY_MUTE,
+	[ 0x16 ] = KEY_F20,		// L/R,
+	[ 0x38 ] = KEY_F21,		// Hibernate,
+
+	[ 0x37 ] = KEY_SWITCHVIDEOMODE,	// A/V
+	[ 0x31 ] = KEY_AGAIN,		// Recall,
+	[ 0x1a ] = KEY_KPPLUS,		// Zoom+,
+	[ 0x19 ] = KEY_KPMINUS,		// Zoom-,
+	[ 0x27 ] = KEY_RED,
+	[ 0x0C ] = KEY_GREEN,
+	[ 0x01 ] = KEY_YELLOW,
+	[ 0x00 ] = KEY_BLUE,
+};
+
+EXPORT_SYMBOL_GPL(ir_codes_mantis_vp2033);
linux/drivers/media/dvb/mantis/Makefile +2 -1
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/dvb/mantis/Makefile mantis-cd1fc4c7f1d8/linux/drivers/media/dvb/mantis/Makefile
@@ -12,7 +12,8 @@
 		mantis_vp1041.o	\
 		mantis_vp2033.o	\
 		mantis_vp2040.o	\
-		mantis_vp3030.o
+		mantis_vp3030.o \
+		mantis_rc.o
 
 obj-$(CONFIG_DVB_MANTIS) += mantis.o
 
linux/drivers/media/dvb/mantis/mantis_common.h +19 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/dvb/mantis/mantis_common.h mantis-cd1fc4c7f1d8/linux/drivers/media/dvb/mantis/mantis_common.h
@@ -26,6 +26,8 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/mutex.h>
+#include <linux/input.h>
+#include <media/ir-common.h>
 
 #include "dvbdev.h"
 #include "dvb_demux.h"
@@ -74,6 +76,20 @@
 	char			*model_name;
 	char			*dev_type;
 	u32			ts_size;
+	IR_KEYTAB_TYPE		*ir_codes;
+};
+
+struct mantis_ir {
+	struct input_dev	*rc_dev;
+	char			rc_name[80];
+	char			rc_phys[80];
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
+	struct work_struct	rc_query_work;
+#else
+	struct delayed_work	rc_query_work;
+#endif
+	u32			ir_last_code;
+	struct ir_input_state	ir;
 };
 
 struct mantis_pci {
@@ -140,6 +156,9 @@
 	int			gpio_status;
 
 	struct mantis_ca	*mantis_ca;
+
+	/* 	IR			*/
+	struct mantis_ir	ir;
 };
 
 extern unsigned int verbose;
linux/drivers/media/dvb/mantis/mantis_core.c +4 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/dvb/mantis/mantis_core.c mantis-cd1fc4c7f1d8/linux/drivers/media/dvb/mantis/mantis_core.c
@@ -164,6 +164,10 @@
 		dprintk(verbose, MANTIS_DEBUG, 1, "Mantis DVB init failed");
 		return err;
 	}
+	if ((err = mantis_rc_init(mantis)) < 0) {
+		dprintk(verbose, MANTIS_DEBUG, 1, "mantis RC init failed");
+		return err;
+	}
 
 	return 0;
 }
linux/drivers/media/dvb/mantis/mantis_core.h +2 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/dvb/mantis/mantis_core.h mantis-cd1fc4c7f1d8/linux/drivers/media/dvb/mantis/mantis_core.h
@@ -53,6 +53,8 @@
 extern int mantis_i2c_exit(struct mantis_pci *mantis);
 extern int mantis_core_init(struct mantis_pci *mantis);
 extern int mantis_core_exit(struct mantis_pci *mantis);
+extern int mantis_rc_init(struct mantis_pci *mantis);
+extern int mantis_rc_exit(struct mantis_pci *mantis);
 //extern void mantis_fe_powerup(struct mantis_pci *mantis);
 //extern void mantis_fe_powerdown(struct mantis_pci *mantis);
 //extern void mantis_fe_reset(struct dvb_frontend *fe);
linux/drivers/media/dvb/mantis/mantis_pci.c +2 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/dvb/mantis/mantis_pci.c mantis-cd1fc4c7f1d8/linux/drivers/media/dvb/mantis/mantis_pci.c
@@ -80,6 +80,7 @@
 		schedule_work(&ca->hif_evm_work);
 	}
 	if (stat & MANTIS_INT_IRQ1) {
+		mantis->ir.ir_last_code = mmread(0xe8);
 		dprintk(verbose, MANTIS_DEBUG, 0, "* INT IRQ-1 *");
 	}
 	if (stat & MANTIS_INT_OCERR) {
@@ -243,6 +244,7 @@
 		dprintk(verbose, MANTIS_ERROR, 1, "Aeio, Mantis NULL ptr");
 		return;
 	}
+	mantis_rc_exit(mantis);
 	mantis_core_exit(mantis);
 	dprintk(verbose, MANTIS_ERROR, 1, "Removing -->Mantis irq: %d, latency: %d\n memory: 0x%lx, mmio: 0x%p",
 		pdev->irq, mantis->latency, mantis->mantis_addr,
linux/drivers/media/dvb/mantis/mantis_rc.c +91 -0

91 lines not on this page · raw message

linux/drivers/media/dvb/mantis/mantis_vp2033.c +1 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/drivers/media/dvb/mantis/mantis_vp2033.c mantis-cd1fc4c7f1d8/linux/drivers/media/dvb/mantis/mantis_vp2033.c
@@ -28,6 +28,7 @@
 	.model_name	= MANTIS_MODEL_NAME,
 	.dev_type	= MANTIS_DEV_TYPE,
 	.ts_size	= MANTIS_TS_204,
+	.ir_codes	= ir_codes_mantis_vp2033,
 };
 
 struct tda1002x_config philips_cu1216_config = {
linux/include/media/ir-common.h +1 -0
diff -urN mantis-cd1fc4c7f1d8.ORIG/linux/include/media/ir-common.h mantis-cd1fc4c7f1d8/linux/include/media/ir-common.h
@@ -142,6 +142,7 @@
 extern IR_KEYTAB_TYPE ir_codes_fusionhdtv_mce[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_behold[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_pinnacle_pctv_hd[IR_KEYTAB_SIZE];
+extern IR_KEYTAB_TYPE ir_codes_mantis_vp2033[IR_KEYTAB_SIZE];
 
 #endif
 

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#1 lore raw

Hi Pauli,

Quoted 12 lines · Pauli Borodulin

Heya!

Since there has been some direct requests for this via email, I'm posting a updated version of Kristian Slavov's original remote control patch[1] for Manu's jusst.de Mantis branch. The new version is functionally the same as the one I posted in March[2].

I have adapted the patch for the current driver tree and moved ir_codes back to ir-keymaps.c & ir-common.h to follow the standard kernel procedure for the IR stuff. The patch is against the current driver tree (cd1fc4c7f1d8).

Quoted 6 lines

[1] http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017279.html
[2] http://www.linuxtv.org/pipermail/linux-dvb/2008-March/024301.html

Regards,
Pauli Borodulin

+int mantis_rc_exit(struct mantis_pci *mantis)
+{
+ mmwrite(mmread(MANTIS_INT_MASK) & (~MANTIS_INT_IRQ1),
MANTIS_INT_MASK);
+

 +        cancel_delayed_work(&mantis->ir.rc_query_work);
 +        input_unregister_device(mantis->ir.rc_dev);
 +        dprintk(verbose, MANTIS_DEBUG, 1, "RC unregistered");
 +        return 0;

+}

this might be dangerous when unloading the driver because the callback function might still be running after cancel_delayed_work.
I ran into that problem a while ago and it could lock up the whole input system.

There's also a note in the kernelheaders:
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
* function may still be running on return from cancel_delayed_work(). Run
* flush_scheduled_work() to wait on it.
*/
include/linux/workqueue.h

Markus

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#2 lore raw

Heya!

Quoted 6 lines · Pauli Borodulin
Quoted 5 lines

Since there has been some direct requests for this via email, I'm posting a updated version of Kristian Slavov's original remote control patch[1] for Manu's jusst.de Mantis branch. The new version is functionally the same as the one I posted in March[2]. [...]

Quoted 9 lines · Markus Rechberger

+int mantis_rc_exit(struct mantis_pci *mantis)
+{
+ mmwrite(mmread(MANTIS_INT_MASK) & (~MANTIS_INT_IRQ1),
MANTIS_INT_MASK);
+

 +        cancel_delayed_work(&mantis->ir.rc_query_work);
 +        input_unregister_device(mantis->ir.rc_dev);
 +        dprintk(verbose, MANTIS_DEBUG, 1, "RC unregistered");
 +        return 0;
Quoted 6 lines

+}

this might be dangerous when unloading the driver because the callback function might still be running after cancel_delayed_work.
I ran into that problem a while ago and it could lock up the whole input system. [...]

Thanks Markus! I created a revised version of the patch with call to flush_scheduled_work() after calling cancel_delayed_work. I also changed RC polling a bit so that it would work alike on different kernel configurations (thanks go to Kristian Slavov for pointing this out).

The patch is against http://www.jusst.de/hg/mantis/archive/b14e79e460fc.tar.bz2.

Regards,
Pauli Borodulin

linux/drivers/media/common/ir-keymaps.c +65 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/common/ir-keymaps.c mantis-b14e79e460fc/linux/drivers/media/common/ir-keymaps.c
@@ -2037,3 +2037,68 @@
 };
 
 EXPORT_SYMBOL_GPL(ir_codes_behold);
+
+/* Twinhan CAB-CI 2033 */
+IR_KEYTAB_TYPE ir_codes_mantis_vp2033[IR_KEYTAB_SIZE] = {
+	[ 0x29 ] = KEY_POWER,
+	[ 0x28 ] = KEY_FAVORITES,
+	[ 0x30 ] = KEY_TEXT,
+	[ 0x17 ] = KEY_INFO,		// Preview
+	[ 0x23 ] = KEY_EPG,
+	[ 0x3b ] = KEY_F22,		// Record List
+
+	[ 0x3c ] = KEY_1,
+	[ 0x3e ] = KEY_2,
+	[ 0x39 ] = KEY_3,
+	[ 0x36 ] = KEY_4,
+	[ 0x22 ] = KEY_5,
+	[ 0x20 ] = KEY_6,
+	[ 0x32 ] = KEY_7,
+	[ 0x26 ] = KEY_8,
+	[ 0x24 ] = KEY_9,
+	[ 0x2a ] = KEY_0,
+
+	[ 0x33 ] = KEY_CANCEL,
+	[ 0x2c ] = KEY_BACK,
+	[ 0x15 ] = KEY_CLEAR,
+	[ 0x3f ] = KEY_TAB,
+	[ 0x10 ] = KEY_ENTER,
+	[ 0x14 ] = KEY_UP,
+	[ 0x0d ] = KEY_RIGHT,
+	[ 0x0e ] = KEY_DOWN,
+	[ 0x11 ] = KEY_LEFT,
+
+	[ 0x21 ] = KEY_VOLUMEUP,
+	[ 0x35 ] = KEY_VOLUMEDOWN,
+	[ 0x3d ] = KEY_CHANNELDOWN,
+	[ 0x3a ] = KEY_CHANNELUP,
+	[ 0x2e ] = KEY_RECORD,
+	[ 0x2b ] = KEY_PLAY,
+	[ 0x13 ] = KEY_PAUSE,
+	[ 0x25 ] = KEY_STOP,
+
+	[ 0x1f ] = KEY_REWIND,
+	[ 0x2d ] = KEY_FASTFORWARD,
+	[ 0x1e ] = KEY_PREVIOUS,	// Replay |<
+	[ 0x1d ] = KEY_NEXT,		// Skip   >|
+
+	[ 0x0b ] = KEY_CAMERA,		// Capture
+	[ 0x0f ] = KEY_LANGUAGE,	// SAP
+	[ 0x18 ] = KEY_MODE,		// PIP
+	[ 0x12 ] = KEY_ZOOM,		// Full screen,
+	[ 0x1c ] = KEY_SUBTITLE,
+	[ 0x2f ] = KEY_MUTE,
+	[ 0x16 ] = KEY_F20,		// L/R,
+	[ 0x38 ] = KEY_F21,		// Hibernate,
+
+	[ 0x37 ] = KEY_SWITCHVIDEOMODE,	// A/V
+	[ 0x31 ] = KEY_AGAIN,		// Recall,
+	[ 0x1a ] = KEY_KPPLUS,		// Zoom+,
+	[ 0x19 ] = KEY_KPMINUS,		// Zoom-,
+	[ 0x27 ] = KEY_RED,
+	[ 0x0C ] = KEY_GREEN,
+	[ 0x01 ] = KEY_YELLOW,
+	[ 0x00 ] = KEY_BLUE,
+};
+
+EXPORT_SYMBOL_GPL(ir_codes_mantis_vp2033);
linux/drivers/media/dvb/mantis/Makefile +2 -1
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/dvb/mantis/Makefile mantis-b14e79e460fc/linux/drivers/media/dvb/mantis/Makefile
@@ -12,7 +12,8 @@
 		mantis_vp1041.o	\
 		mantis_vp2033.o	\
 		mantis_vp2040.o	\
-		mantis_vp3030.o
+		mantis_vp3030.o \
+		mantis_rc.o
 
 obj-$(CONFIG_DVB_MANTIS) += mantis.o
 
linux/drivers/media/dvb/mantis/mantis_common.h +19 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/dvb/mantis/mantis_common.h mantis-b14e79e460fc/linux/drivers/media/dvb/mantis/mantis_common.h
@@ -26,6 +26,8 @@
 #include <linux/kernel.h>
 #include <linux/pci.h>
 #include <linux/mutex.h>
+#include <linux/input.h>
+#include <media/ir-common.h>
 
 #include "dvbdev.h"
 #include "dvb_demux.h"
@@ -74,6 +76,20 @@
 	char			*model_name;
 	char			*dev_type;
 	u32			ts_size;
+	IR_KEYTAB_TYPE		*ir_codes;
+};
+
+struct mantis_ir {
+	struct input_dev	*rc_dev;
+	char			rc_name[80];
+	char			rc_phys[80];
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
+	struct work_struct	rc_query_work;
+#else
+	struct delayed_work	rc_query_work;
+#endif
+	u32			ir_last_code;
+	struct ir_input_state	ir;
 };
 
 struct mantis_pci {
@@ -140,6 +156,9 @@
 	u32			gpio_status;
 
 	struct mantis_ca	*mantis_ca;
+
+	/*	IR			*/
+	struct mantis_ir	ir;
 };
 
 #define MANTIS_HIF_STATUS	(mantis->gpio_status << 12)
linux/drivers/media/dvb/mantis/mantis_core.c +4 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/dvb/mantis/mantis_core.c mantis-b14e79e460fc/linux/drivers/media/dvb/mantis/mantis_core.c
@@ -164,6 +164,10 @@
 		dprintk(verbose, MANTIS_DEBUG, 1, "Mantis DVB init failed");
 		return err;
 	}
+	if ((err = mantis_rc_init(mantis)) < 0) {
+		dprintk(verbose, MANTIS_DEBUG, 1, "Mantis RC init failed");
+		return err;
+	}
 
 	return 0;
 }
linux/drivers/media/dvb/mantis/mantis_core.h +2 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/dvb/mantis/mantis_core.h mantis-b14e79e460fc/linux/drivers/media/dvb/mantis/mantis_core.h
@@ -53,5 +53,7 @@
 extern int mantis_i2c_exit(struct mantis_pci *mantis);
 extern int mantis_core_init(struct mantis_pci *mantis);
 extern int mantis_core_exit(struct mantis_pci *mantis);
+extern int mantis_rc_init(struct mantis_pci *mantis);
+extern int mantis_rc_exit(struct mantis_pci *mantis);
 
 #endif //__MANTIS_CORE_H
linux/drivers/media/dvb/mantis/mantis_pci.c +2 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/dvb/mantis/mantis_pci.c mantis-b14e79e460fc/linux/drivers/media/dvb/mantis/mantis_pci.c
@@ -80,6 +80,7 @@
 		schedule_work(&ca->hif_evm_work);
 	}
 	if (stat & MANTIS_INT_IRQ1) {
+		mantis->ir.ir_last_code = mmread(0xe8);
 		dprintk(verbose, MANTIS_DEBUG, 0, "* INT IRQ-1 *");
 	}
 	if (stat & MANTIS_INT_OCERR) {
@@ -228,6 +229,7 @@
 		dprintk(verbose, MANTIS_ERROR, 1, "Aeio, Mantis NULL ptr");
 		return;
 	}
+	mantis_rc_exit(mantis);
 	mantis_core_exit(mantis);
 	dprintk(verbose, MANTIS_ERROR, 1, "Removing -->Mantis irq: %d, latency: %d\n memory: 0x%lx, mmio: 0x%p",
 		pdev->irq, mantis->latency, mantis->mantis_addr,
linux/drivers/media/dvb/mantis/mantis_rc.c +94 -0

94 lines not on this page · raw message

linux/drivers/media/dvb/mantis/mantis_vp2033.c +1 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/drivers/media/dvb/mantis/mantis_vp2033.c mantis-b14e79e460fc/linux/drivers/media/dvb/mantis/mantis_vp2033.c
@@ -28,6 +28,7 @@
 	.model_name	= MANTIS_MODEL_NAME,
 	.dev_type	= MANTIS_DEV_TYPE,
 	.ts_size	= MANTIS_TS_204,
+	.ir_codes	= ir_codes_mantis_vp2033,
 };
 
 struct tda1002x_config philips_cu1216_config = {
linux/include/media/ir-common.h +1 -0
diff -urN mantis-b14e79e460fc.ORIG/linux/include/media/ir-common.h mantis-b14e79e460fc/linux/include/media/ir-common.h
@@ -142,6 +142,7 @@
 extern IR_KEYTAB_TYPE ir_codes_fusionhdtv_mce[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_behold[IR_KEYTAB_SIZE];
 extern IR_KEYTAB_TYPE ir_codes_pinnacle_pctv_hd[IR_KEYTAB_SIZE];
+extern IR_KEYTAB_TYPE ir_codes_mantis_vp2033[IR_KEYTAB_SIZE];
 
 #endif
 

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#3 lore raw
Quoted 27 lines · Pauli Borodulin

Heya!

Quoted 6 lines · Pauli Borodulin
Quoted 5 lines

Since there has been some direct requests for this via email, I'm posting a updated version of Kristian Slavov's original remote control patch[1] for Manu's jusst.de Mantis branch. The new version is functionally the same as the one I posted in March[2]. [...]

Quoted 9 lines · Markus Rechberger

+int mantis_rc_exit(struct mantis_pci *mantis)
+{
+ mmwrite(mmread(MANTIS_INT_MASK) & (~MANTIS_INT_IRQ1),
MANTIS_INT_MASK);
+

 +        cancel_delayed_work(&mantis->ir.rc_query_work);
 +        input_unregister_device(mantis->ir.rc_dev);
 +        dprintk(verbose, MANTIS_DEBUG, 1, "RC unregistered");
 +        return 0;
Quoted 7 lines

+}

this might be dangerous when unloading the driver because the callback function might still be running after cancel_delayed_work. I ran into that problem a while ago and it could lock up the whole input system.
[...]

Quoted 7 lines

Thanks Markus! I created a revised version of the patch with call to flush_scheduled_work() after calling cancel_delayed_work. I also changed RC polling a bit so that it would work alike on different kernel configurations (thanks go to Kristian Slavov for pointing this out).

The patch is against
http://www.jusst.de/hg/mantis/archive/b14e79e460fc.tar.bz2.

No offense, but I like my patch much better :-) [1]. I fail to see why polling has to be done - just for half-working (at best on some cards, not at all if the native repeat rate is too low) "improved" auto-repeat.

I was under the impression that using cancel_rearming_delayed_work instead of cancel_delayed_work (as I did in my patch) would make it unnecessary to call flush_scheduled_work (but I just followed some other drivers and could be easily wrong).

As for the IR codes being in common ir code, I didn't care but the dvb-usb driver also uses its own tables - though I see this driver probably has reasons to do so.

[1]http://www.linuxtv.org/pipermail/linux-dvb/2008-May/026102.html

Roland

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw

Heya!

Quoted 4 lines · Roland Scheidegger

[...]
No offense, but I like my patch much better :-) [1]. I fail to see why polling has to be done - just for half-working (at best on some cards, not at all if the native repeat rate is too low) "improved" auto-repeat.

Ah, sorry. My bad, I missed your patch. It surely looks better.

What comes to auto-repeat... With your version of the patch it works equally well/badly on 2033 as it did with the earlier version.

Quoted 4 lines

I was under the impression that using cancel_rearming_delayed_work instead of cancel_delayed_work (as I did in my patch) would make it unnecessary to call flush_scheduled_work (but I just followed some other drivers and could be easily wrong).

After reading some kernel source code, I agree that cancel_rearming_delayed_work is better suited.

Quoted 1 line

[...]

Regards,
Pauli Borodulin <[email protected]>

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#6 lore raw
Quoted 8 lines · Pauli Borodulin

Heya!

Quoted 4 lines · Roland Scheidegger

[...]
No offense, but I like my patch much better :-) [1]. I fail to see why polling has to be done - just for half-working (at best on some cards, not at all if the native repeat rate is too low) "improved" auto-repeat.

Quoted 4 lines

Ah, sorry. My bad, I missed your patch. It surely looks better.

What comes to auto-repeat... With your version of the patch it works equally well/badly on 2033 as it did with the earlier version.

Just curious, what's the native repeat rate (what it prints out with verbose set time between irqs) with this card?

Quoted 8 lines
Quoted 5 lines

I was under the impression that using cancel_rearming_delayed_work instead of cancel_delayed_work (as I did in my patch) would make it unnecessary to call flush_scheduled_work (but I just followed some other drivers and could be easily wrong).

After reading some kernel source code, I agree that cancel_rearming_delayed_work is better suited.

Roland

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 4 lines · Pauli Borodulin
Quoted 3 lines

[...]
What comes to auto-repeat... With your version of the patch it works equally well/badly on 2033 as it did with the earlier version.

Quoted 2 lines · Roland Scheidegger

Just curious, what's the native repeat rate (what it prints out with verbose set time between irqs) with this card?

Initial delay ~270ms and repeats ~220ms.

Btw I found these in dvb-usb-remote.c:

     input_dev->rep[REP_PERIOD] = d->props.rc_interval;
     input_dev->rep[REP_DELAY]  = d->props.rc_interval + 150;

So there seems to be some configurable auto-repeat functionality in input layer. I guess I'll experiment with those even tho' RCs delays are a bit crappy, since it's a pretty painful to go through a long list of recordings without any auto-repeat...

Quoted 1 line
Quoted 1 line

[...]

Regards,
Pauli Borodulin

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#9 lore raw
Quoted 10 lines · Pauli Borodulin
Quoted 4 lines · Pauli Borodulin
Quoted 3 lines

[...]
What comes to auto-repeat... With your version of the patch it works equally well/badly on 2033 as it did with the earlier version.

Quoted 2 lines · Roland Scheidegger

Just curious, what's the native repeat rate (what it prints out with verbose set time between irqs) with this card?

Initial delay ~270ms and repeats ~220ms.

Ah so exactly the same as for my remote. Interesting...

Quoted 10 lines

Btw I found these in dvb-usb-remote.c:

     input_dev->rep[REP_PERIOD] = d->props.rc_interval;
     input_dev->rep[REP_DELAY]  = d->props.rc_interval + 150;

So there seems to be some configurable auto-repeat functionality in input layer. I guess I'll experiment with those even tho' RCs delays are a bit crappy, since it's a pretty painful to go through a long list of recordings without any auto-repeat...

If you change these values (to anything but zero) before input_register_device, the input driver will just disable auto-repeat (or rather, you'd need to handle it yourself in the driver with the appropriate timer func, and I didn't feel like duplicating half the code of the input driver). input_register_device also says all capabilities must be set up before calling it, when I tried to change those values afterwards it didn't seem to work (though maybe I made some testing error, I can't see why it shouldn't work). I guess a REP_DELAY a bit over the initial delay (like 300ms) should work, and a REP_PERIOD of about 100 (which would give you about 50% chance of stopping pressing keys exactly) might be reasonable - though it really is annoying if you can't stop exactly (but it's not solvable - either live with slow repeat or live with that).

Roland

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#10 lore raw
Quoted 11 lines · Pauli Borodulin
Quoted 10 lines

[...]
Btw I found these in dvb-usb-remote.c:

     input_dev->rep[REP_PERIOD] = d->props.rc_interval;
     input_dev->rep[REP_DELAY]  = d->props.rc_interval + 150;

So there seems to be some configurable auto-repeat functionality in input layer. I guess I'll experiment with those even tho' RCs delays are a bit crappy, since it's a pretty painful to go through a long list of recordings without any auto-repeat...

Quoted 5 lines · Roland Scheidegger

If you change these values (to anything but zero) before input_register_device, the input driver will just disable auto-repeat (or rather, you'd need to handle it yourself in the driver with the appropriate timer func, and I didn't feel like duplicating half the code of the input driver). input_register_device also says all capabilities

Quoted 8 lines

must be set up before calling it, when I tried to change those values afterwards it didn't seem to work (though maybe I made some testing error, I can't see why it shouldn't work). I guess a REP_DELAY a bit over the initial delay (like 300ms) should work, and a REP_PERIOD of about 100 (which would give you about 50% chance of stopping pressing keys exactly) might be reasonable - though it really is annoying if you can't stop exactly (but it's not solvable - either live with slow repeat or live with that).

In dvb/ttpci/budget-ci.c there's a note:

         /* note: these must be after input_register_device */
         input_dev->rep[REP_DELAY] = 400;
         input_dev->rep[REP_PERIOD] = 250;

I wondered why and proceeded to kernel's drivers/input/input.c. There's a note in input_register_device:

/*
* If delay and period are pre-set by the driver, then autorepeating
* is handled by the driver itself and we don't do it in input.c. */

init_timer(&dev->timer);

if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
	dev->timer.data = (long) dev;
	dev->timer.function = input_repeat_key;
	dev->rep[REP_DELAY] = 250;
	dev->rep[REP_PERIOD] = 33;
}

So it is different whether you set REP_DELAY & REP_PERIOD before or after calling input_register_device. If you set them before, it seems you are also expected to provide your own input_repeat_key function. If after, then... I guess input layer uses it's own logic, but just using customized REP_DELAY and REP_PERIOD.

I don't know why for example ttpci/av7110_ir.c uses it's own input_repeat_key function instead of using the logic provided by input layer. I will probably find this out later today when trying to experiment auto-repeat functionality.

Regards,
Pauli Borodulin

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#11 lore raw
In reply to Roland Scheidegger
Quoted 11 lines · Pauli Borodulin
Quoted 10 lines

[...]
Btw I found these in dvb-usb-remote.c:

     input_dev->rep[REP_PERIOD] = d->props.rc_interval;
     input_dev->rep[REP_DELAY]  = d->props.rc_interval + 150;

So there seems to be some configurable auto-repeat functionality in input layer. I guess I'll experiment with those even tho' RCs delays are a bit crappy, since it's a pretty painful to go through a long list of recordings without any auto-repeat...

Quoted 5 lines · Roland Scheidegger

If you change these values (to anything but zero) before input_register_device, the input driver will just disable auto-repeat (or rather, you'd need to handle it yourself in the driver with the appropriate timer func, and I didn't feel like duplicating half the code of the input driver). input_register_device also says all capabilities

Quoted 8 lines

must be set up before calling it, when I tried to change those values afterwards it didn't seem to work (though maybe I made some testing error, I can't see why it shouldn't work). I guess a REP_DELAY a bit over the initial delay (like 300ms) should work, and a REP_PERIOD of about 100 (which would give you about 50% chance of stopping pressing keys exactly) might be reasonable - though it really is annoying if you can't stop exactly (but it's not solvable - either live with slow repeat or live with that).

In dvb/ttpci/budget-ci.c there's a note:

          /* note: these must be after input_register_device */
          input_dev->rep[REP_DELAY] = 400;
          input_dev->rep[REP_PERIOD] = 250;

I wondered why and proceeded to kernel's drivers/input/input.c. There's a note in input_register_device:

/*
* If delay and period are pre-set by the driver, then autorepeating
* is handled by the driver itself and we don't do it in input.c. */

init_timer(&dev->timer);

if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
	dev->timer.data = (long) dev;
	dev->timer.function = input_repeat_key;
	dev->rep[REP_DELAY] = 250;
	dev->rep[REP_PERIOD] = 33;
}

So it is different whether you set REP_DELAY & REP_PERIOD before or after calling input_register_device. If you set them before, it seems you are also expected to provide your own input_repeat_key function. If after, then... I guess input layer uses it's own logic, but just using customized REP_DELAY and REP_PERIOD.

I don't know why for example ttpci/av7110_ir.c uses it's own input_repeat_key function instead of using the logic provided by input layer. I will probably find this out later today when trying to experiment auto-repeat functionality.

Regards,
Pauli Borodulin

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#12 lore raw
In reply to Pauli Borodulin
Quoted 10 lines · Pauli Borodulin
Quoted 4 lines · Pauli Borodulin
Quoted 3 lines

[...]
What comes to auto-repeat... With your version of the patch it works equally well/badly on 2033 as it did with the earlier version.

Quoted 2 lines · Roland Scheidegger

Just curious, what's the native repeat rate (what it prints out with verbose set time between irqs) with this card?

Initial delay ~270ms and repeats ~220ms.

Ah so exactly the same as for my remote. Interesting...

Quoted 10 lines

Btw I found these in dvb-usb-remote.c:

     input_dev->rep[REP_PERIOD] = d->props.rc_interval;
     input_dev->rep[REP_DELAY]  = d->props.rc_interval + 150;

So there seems to be some configurable auto-repeat functionality in input layer. I guess I'll experiment with those even tho' RCs delays are a bit crappy, since it's a pretty painful to go through a long list of recordings without any auto-repeat...

If you change these values (to anything but zero) before input_register_device, the input driver will just disable auto-repeat (or rather, you'd need to handle it yourself in the driver with the appropriate timer func, and I didn't feel like duplicating half the code of the input driver). input_register_device also says all capabilities must be set up before calling it, when I tried to change those values afterwards it didn't seem to work (though maybe I made some testing error, I can't see why it shouldn't work). I guess a REP_DELAY a bit over the initial delay (like 300ms) should work, and a REP_PERIOD of about 100 (which would give you about 50% chance of stopping pressing keys exactly) might be reasonable - though it really is annoying if you can't stop exactly (but it's not solvable - either live with slow repeat or live with that).

Roland

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb