Re: DVICO FusionRemote MCE: every button sent twice (but not as a repeat)

[raf <li...@ra...>]

raf wrote:

> hi,
> 
> remote: DVICO FusionRemote MCE
> lirc: 0.8.0 then 0.8.1
> driver: dev/input
> client: mythtv (release-0-19-fixes)
> kernel: 2.6.17.1 (smp preempt)
> distro: ubuntu-6.06
> 
> my remote sends two identical copies of every button press
> whenever any of the buttons are pressed.
> 
> i created a lircd.conf with irrecord (lirc-0.8.0/devinput).
> it's attached. i creat
> 
> irw's output looks like:
> 
>  $ irw # and then press the "2" button on the remote
>  0000000000010003 00 2 DVICO_MCE
>  0000000000010003 00 2 DVICO_MCE
> 
> the second column is always "00" which i think
> means that the remote is telling us that it's not
> a repeat of a previous key even though that's exactly
> what it is.
> 
> i can't find the reference anymore but i think that "00"
> means key down, "01" means key repeat, and either "08" or
> "09" mean key up. or every number above "00" is a repeat.
> but i couldn't find any documentation specifying the format
> of irw's output so it's hard to tell for sure.
> 
> even when i hold a button down for a long time, irw's
> output is pairs of identical lines, all with "00" in
> the second column. it seems that the remote never admits
> to repeating buttons.
> 
> anyway, i've tried using the repeat and/or delay options in
> my ~/.lircrc but that had no effect (probably because they
> only operate on buttons that are identified as repeats).
> 
> then i tried the "min_repeat 1" option in lircd.conf as
> suggested by FAQ #4 (http://www.lirc.org/faq.html) but that
> had no effect.
> 
> then i searched for the problem in the mailing list archives
> and found:
> 
>  http://comments.gmane.org/gmane.comp.hardware.lirc/4464
> 
> the suggestion (for a different remote) was to get the
> latest version of lirc and use the "min_code_repeat 1"
> option in the lircd.conf. trying that just resulted in
> "invalid min_code_repeat value" log messages. looking for
> documentation on the min_code_repeat option (and what
> consititues a valid value) uncovered nothing. reading the
> source code told me that i also needed min_repeat and/or?
> repeat options in order to use min_code_repeat. but the
> min_code_repeat option was added to support a different
> remote anyway and so is probably not relevant to this
> problem.
> 
> i tried various combinations of these three options (and the
> NO_HEAD_REP and REPEAT_HEADER flags) but nothing had any
> effect. of course, i didn't know what i was doing and
> min_code_repeat wasn't documented and much of what was
> documented meant little to me (e.g. what values make sense
> in the repeat option in lircd.conf?).
> 
> the person that suggested the min_code_repeat option also
> said that lircd was doing the right thing in passing on
> multiple button presses. that's a true but unhelpful
> statement since the remote remains mostly unusable (and the
> suggestion to use the delay option in ~/.lircrc doesn't help
> in my case presumably because the second button code does
> not identify itself as a repeat).
> 
> any ideas on what i can try next?
> what am i missing?
> 
> can i avoid having to write an proxy/adapter to sit between
> lircd and lirc clients to remove these extraneous non-repeat
> repeats?
> 
> is my remote really stupid?
> should i get a different one?
> or is it just me :-?
> 
> cheers,
> raf

what i have discovered since (thanks to my brother's superior web searching skills):

there's an old patch for a dvico_mce driver that never made it into lirc:

  http://www.mythtv.org/pipermail/mythtv-users/2005-August/100371.html

but it was so old i didn't try it.

and christopher pascoe wrote linux-dvb patches that seem
like they might be relevant:

  http://www.itee.uq.edu.au/~chrisp/Linux-DVB/DVICO/hid-core.c.diff
  http://www.itee.uq.edu.au/~chrisp/Linux-DVB/DVICO/hid.h.diff

but again, these are patches for an old kernel so i didn't
to try that.

and greg lehey wrote a patch for lirc-0.8.0 for this problem
when porting lirc to freebsd:

  http://www.mail-archive.com/lin...@li.../msg22214.html

but all of the above affect the hiddev driver, not the
devinput driver that i am using.

so, i added a line of code to hw_devinput.c to discard the extraneous
messages. it's probably dangerous for others but it fixed my problem.
hopefully, someone will come up with a real solution to this one day.

here it is (lirc-0.8.1.dvico_fusion_remote_mce_devinput_hack.diff):

diff -durp lirc-0.8.1/daemons/hw_devinput.c lirc-0.8.1.hacked/daemons/hw_devinput.c
--- lirc-0.8.1/daemons/hw_devinput.c	2006-12-11 13:28:08.000000000 +1100
+++ lirc-0.8.1.hacked/daemons/hw_devinput.c	2007-03-16 12:50:51.000000000 +1100
@@ -280,5 +280,18 @@ char *devinput_rec(struct ir_remote *rem
 	/* ignore EV_SYN */
 	if(event.type == EV_SYN) return NULL;
 
+	/*
+	** My "DVICO Fusion Remove MCE" sends two messages for every button press.
+	** The second (and subsequent) messages are not identified as repeats.
+	** This is indicated by the second column of irw's output always being "00".
+	** In this function, the first message has event.value == 1 and the second
+	** message has event.value == 0. This shameful hack below discards the
+	** second message based on the value of event.value. This is extremely lame
+	** but it fixed my problem.
+	**
+	** 20070316 raf <ra...@ra...>
+	*/
+	if(event.value == 0) return NULL;
+
 	return decode_all(remotes);
 }