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 http://danconti.net/mceusb-v2.tgz
> > (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 : )