Ticlkess Mantis remote control implementation

Hi,

I have still my own version of Manu's jusst.de/mantis driver that is based on v4l-dvb-linuxtv main branch,
mainly because I use so new Linux kernels.
I have done the following improvement lately:

I implemented a remote control patch, that doesn't poll the remote control all the time.
It polls the remote control only if you press the button (a tickless version, you know).
It surprised me, that the actual implementation was really small, it took very few lines of code.

Hi,

I have still my own version of Manu's jusst.de/mantis driver that is based on v4l-dvb-linuxtv main branch,
mainly because I use so new Linux kernels.
I have done the following improvement lately:

I implemented a remote control patch, that doesn't poll the remote control all the time.
It polls the remote control only if you press the button (a tickless version, you know).
It surprised me, that the actual implementation was really small, it took very few lines of code.

The idea is, that the remote control informs (thrue irq) mantis_query_rc() to be active.
mantis_query_rc takes care that it will reactivate itself after 250ms, until remote control
hasn't sent any "user is still pressing a button" messages.

POLL_FREQ (HZ/4) time (250ms) must be more than the remote control message interval (230ms).
This way we can ensure that the remote control sends at least one message per POLL_FREQ tick.
If on the last POLL_FREQ tick no button is pressed (-1), mantis_query_rc() doesn't activate the POLL_FREQ tick anymore, just informs via ir_input_nokey() that the remote control user doesn't press any buttons.

So in this way the remote control works with Twinhan 2033 better than ever (the hand experience is good also).
+ Initial key press is delivered instantly.
+ No CPU consumption while the remote control isn't used. Could possibly be improved with a tasklet, if the instant response experience would be that important.
Can be used from 1 to 4 key repeats per second (230ms remote control limit is the lower bound, we must be safely above).

Interrupt handler on mantis_pci.c:

       if (stat & MANTIS_INT_IRQ1) {
               mantis->ir.ir_last_code = mmread(0xe8);
               dprintk(verbose, MANTIS_DEBUG, 0, "* INT IRQ-1 *");
               schedule_delayed_work(&mantis->ir.rc_query_work, 0);
       }

mantis_rc.c:
#define POLL_FREQ (HZ/4)

void mantis_query_rc(struct work_struct *work) {
struct mantis_pci *mantis =
container_of(work, struct mantis_pci,

ir.rc_query_work.work);
       struct ir_input_state *ir = &mantis->ir.ir;

       u32 lastkey = mantis->ir.ir_last_code;

       ir_input_nokey(mantis->ir.rc_dev, ir);

       if (lastkey != -1) {
               ir_input_keydown(mantis->ir.rc_dev, ir, lastkey, 0);
               mantis->ir.ir_last_code = -1;
               schedule_delayed_work(&mantis->ir.rc_query_work, POLL_FREQ);
       }
}

int mantis_rc_init(struct mantis_pci *mantis):

       mantis->ir.ir_last_code = -1; /* key presses disabled here. */
       INIT_DELAYED_WORK(&mir->rc_query_work, mantis_query_rc);

int mantis_rc_exit(struct mantis_pci *mantis):

mmwrite(mmread(MANTIS_INT_MASK) & (~MANTIS_INT_IRQ1),

MANTIS_INT_MASK);
       mantis->ir.ir_last_code = -1; /* key presses disabled here. */
       cancel_delayed_work_sync(&mantis->ir.rc_query_work); /* not my

idea */

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

Hi Marko,

Quoted 17 lines · Marko Ristola

Hi,

I have still my own version of Manu's jusst.de/mantis driver that is based on v4l-dvb-linuxtv main branch,
mainly because I use so new Linux kernels.
I have done the following improvement lately:

I implemented a remote control patch, that doesn't poll the remote control all the time.
It polls the remote control only if you press the button (a tickless version, you know).
It surprised me, that the actual implementation was really small, it took very few lines of code.

Quoted 4 lines

mantis_rc.c:
#define POLL_FREQ (HZ/4)

maybe msecs_to_jiffies(250) would be easier to understand here?

Markus

Quoted 37 lines

void mantis_query_rc(struct work_struct *work) {
struct mantis_pci *mantis =
container_of(work, struct mantis_pci,

ir.rc_query_work.work);
       struct ir_input_state *ir = &mantis->ir.ir;

       u32 lastkey = mantis->ir.ir_last_code;

       ir_input_nokey(mantis->ir.rc_dev, ir);

       if (lastkey != -1) {
               ir_input_keydown(mantis->ir.rc_dev, ir, lastkey, 0);
               mantis->ir.ir_last_code = -1;
               schedule_delayed_work(&mantis->ir.rc_query_work, POLL_FREQ);
       }
}

int mantis_rc_init(struct mantis_pci *mantis):

       mantis->ir.ir_last_code = -1; /* key presses disabled here. */
       INIT_DELAYED_WORK(&mir->rc_query_work, mantis_query_rc);

int mantis_rc_exit(struct mantis_pci *mantis):

mmwrite(mmread(MANTIS_INT_MASK) & (~MANTIS_INT_IRQ1),

MANTIS_INT_MASK);
       mantis->ir.ir_last_code = -1; /* key presses disabled here. */
       cancel_delayed_work_sync(&mantis->ir.rc_query_work); /* not my

idea */

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

Quoted 7 lines · Marko Ristola

Hi,

I have still my own version of Manu's jusst.de/mantis driver that is based on v4l-dvb-linuxtv main branch,
mainly because I use so new Linux kernels.
I have done the following improvement lately:

Quoted 8 lines

I implemented a remote control patch, that doesn't poll the remote control all the time.
It polls the remote control only if you press the button (a tickless version, you know).
It surprised me, that the actual implementation was really small, it took very few lines of code.

You're not the first to think that the constant polling is not necessary, too bad these things always get lost because they aren't integrated in the official driver...

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

Roland

Quoted 21 lines · Roland Scheidegger

Quoted 7 lines · Marko Ristola

Hi,

I have still my own version of Manu's jusst.de/mantis driver that is based on v4l-dvb-linuxtv main branch,
mainly because I use so new Linux kernels.
I have done the following improvement lately:

Quoted 8 lines

I implemented a remote control patch, that doesn't poll the remote control all the time.
It polls the remote control only if you press the button (a tickless version, you know).
It surprised me, that the actual implementation was really small, it took very few lines of code.

You're not the first to think that the constant polling is not necessary, too bad these things always get lost because they aren't integrated in the official driver...

Quoted 2 lines

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

Okay, I understood from your patch that you just deliver all key repeats as initial key presses.
You have disabled the polling altogether, but just deliver the key presses as initial key presses
and deliver the "key unpressed" instantly after the key press.

What is the feeling? I think that it might work for my remote control equally.
Also I noticed that you mentioned that you remote control's initial key repeat comes after 270ms.
So polling on my code should be done with 300ms intervals for example. Maybe it would make my own remote control also more robust.

My version is better only in the sense that some application would be able to
catch the fact that the user is pressing a button and holding it down a long time. Maybe some programs need that for robustness.

Your version is better in the sense that you repeat 270ms and 220ms rerepeats correctly, as the remote control sends them.

Can we implement a version that has both advantages and is still acceptable to the kernel?

+ no work cancellation needs to be done during normal operation.
+ no current time calculation is done.

With both features working, it could be done in the following way:
Set a work with a timeout of 300ms.
Deliver all key presses and repeats instantly.
On key press delivery, cancel the assumed ealier delayed check and setup a new checking work with 300ms delay.
If a 300ms checking delay will be ever active, it will just inform "no key pressed" and continue.

On my opinion this "final" implementation might be a generic implementation which could be used in more places than on Mantis driver.

One question is, that are these Mantis remote controls at all like RC5 remote controls mentioned in ir-common.c/h.
If yes, the correct way might be to use it's implementation.

Personally I haven't seen a "key unpressed" IRQ with my remote. That event seems to be needed, if RC5 code is going to be used.

It might though be, that the interrupt line for "key unpressed" isn't the same as with "key pressed".
That might be rather easy to investigate and the implementation for "key unpressed" would be then trivial.