At 02:48 PM 2/29/2004 , Dan Conti wrote:
Hi Ben, some comments inlined below.

On Sun, 29 Feb 2004, Benjamin Watkins wrote:

> I applied the patches Dan just posted to
> (now incorporated into CVS) in hopes that I would be able to capture my MCE
> remote (it came bundled with my PC, but you can find an identical looking
> one at
> .  It basically has all of the same buttons as the one defined in the
> lircd.conf for the MCE remote, but for some reason that lircd.conf file
> doesn't work for me. For this reason, I have been trying to capture my own
> remote.

How exactly does it not work for you? Is it that you use that lircd.conf,
start lircd, run irw and see no events? Or do you see some events but not

The former.  I use the lircd.conf, start lircd, run irw, and see no events.  Or, I should say saw no events until a little bit ago.  I just realized that I had been doing something very stupid.  In the course of playing with this last week, I had modified my initscript to specify the lirc device.  I realize there is not a good reason to do this, and apparently this was my problem (with this part) the whole time.

> Before applying this patch, I was having trouble using irrecord to capture
> the codes. The output from mode2 seemed to that lirc was seeing the codes
> correctly, but irrecord was having trouble when capturing actual codes. The
> remote captures in raw mode, and every time I push a button I got the
> following message:
> Sorry, something went wrong.
> Try again.

This is my bad, i promised christoph i would debug irrecord for this
remote and i haven't done so yet.

At least I'm not crazy... irrecord really didn't like this remote.

Originally it was failing and throwing you in to raw mode because the
driver itself was giving back bad data. While trying irrecord just now,
however, it figured out the gap, the header, and the protocol (RC-6), so
it's doing a bit better. I still had an error, and i will look at fixing

You should not need to use irrecord with this though; when you updated to
the latest drivers, did you try using the updated lircd.conf in
remotes/mceusb ? The gap length from the driver changed, and i had put in
an improper eps before that caused a few problems.

> In any case I was hoping that the new patches would help, but it seems I
> was better off with the previous CVS version. After applying the patch, the
> module seems to hang after using it for a while. I can get it working again
> by typing
> rmmod lirc_mceusb && insmod lirc_mceusb

What do you mean by "hang"? mode2 no longer outputs data when you press
buttons? Can you still open the device? Do you get anything less than
pleasant in /var/log/messages ?

I mean that mode2 no longer showed any activity on the IR port.  I could connect with mode2 a few times, but ultimately it failed to show any data.  I have seen this happen a few times since it started recognizing buttons in irw, and I will post more information if it continues to happen.

> I'm assuming this new problem is a result of the changes that have been
> made, and not something stupid on my part. I can't rule the latter out,
> since I still can't get my remote to work (or any other remote for that
> matter, though at least I can capture other remotes successfully). I'll
> address that problem once I can capture my MCE remote. In case it helps,
> this is a file I generated one of the only times I successfully grabbed a
> button. Unfortunately, irw seems to ignore it.

Yeah, the remote has two toggle bits which gives lirc fits if you dont
describe them properly. that is the toggle_bit and rc6_mask fields in the
lircd.conf for it. I dont think it would be possible to get a raw mode
capture to work properly.

This also answers your question in the other email: the data in seemingly
identical presses will vary each time. There are two reasons, one is the
toggle bits flipping, and the other is the fact that the a/d conversion on
the receiver isn't going to produce identical data. One time you might see
a length of 450, and the next 500; they are in effect the same value, and
the eps/aeps (error tolerance) settings in the lircd.conf compensate for

Makes sense to me... I figured there had to be a way of dealing with this.

With the first version of the driver, there was a problem where the total
number of mode2 bytes returned for a repeat event was not constant; this
was a bug that i have fixed though.

I did notice that as well... it would report a problem with the number of bytes not being odd and make me retry.

> Perhaps the codes for my remote are the same as for the Philips remote, and
> there is something else going on here.  I will also try using the patched
> CVS version, through it should be the same as the version I patched myself.

One last thing to try here,
echo -n "" > /var/log/lircd
kill lircd and restart it with --debug=10
start up irw and hit a button

Look through /var/log/lircd and see where the failure happens. Basically
there are two types of failures:

1) Failure to process the mode2 data, indicated by "failed on bit XX"
2) Failure to match the code to a code in /etc/lircd.conf; i dont remember
the exact message, but this would happen after a line saying "code xxxx"
or something similar, when it has processed the entire signal

If neither of those failures happen, and it is showing the mode2 it
processed, you should be seeing events in irw.

Let me know if you are still not getting anywhere and we can try some
other stuff. :)


Well I'm going to keep configuring this now that it seems to be (mostly) behaving.  I will assume everything is resolved until I learn otherwise.  Now I just need to get MythTV working to my taste.  Thank you for your help, and thanks for making this remote work for me!  I really do appreciate all of your efforts, as well as those of the people on this list.

-Ben : )