Updated Mantis VP-2033 remote control patch for Manu's jusst.de Mantis branch
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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_codesback toir-keymaps.c&ir-common.hto 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.htmlRegards,
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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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 callingcancel_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]
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_workinstead ofcancel_delayed_work(as I did in my patch) would make it unnecessary to callflush_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
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_workinstead ofcancel_delayed_work(as I did in my patch) would make it unnecessary to callflush_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_workis 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]
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
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
Quoted 11 lines · Pauli Borodulin
Quoted 10 lines
[...]
Btw I found these indvb-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_devicealso 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_DELAYa bit over the initial delay (like 300ms) should work, and aREP_PERIODof 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
Quoted 11 lines · Pauli Borodulin
Quoted 10 lines
[...]
Btw I found these indvb-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_devicealso 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_DELAYa bit over the initial delay (like 300ms) should work, and aREP_PERIODof 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
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