I have Linux box (gentoo) on my LAPTOP and HTPC. Kernel is almost the same. Using irtoy (firmware x22) as ttyACM0. Lirc is from git-repo. lirc.conf for the remote is attached. LAPTOP has no problems (irw shows every button press).
On HTPC if i press buttons frequent - everything goes fine - every press is shown on irw. But if I wait for a while (about 3 seconds), lirc in debug level shows raw_code 0xFFFF coming during this wait and LIRC suddenly stops recognise the pressing.
I attached two lirc logs - one from LAPTOP with successful and HTPC, not recognized second KEY_OK press.
In line 10292 - successfull press KEY_OK both recognized. After that HTPC receives 0xFFFF raw_code.
Please file a bug ticket at https://sourceforge.net/p/lirc/tickets/ (https://sourceforge.net/p/lirc/tickets/) (You may need a sourceforge account.) Possibly you should give some more details on your "HTTP", for example configuration parameters.
The IrToy behaves a little bit "funny" when ending timeout occurs (that is the 0xffff), so I would not be surprised if it is a real bug in Lirc or the driver.
From the logs, it appears as if both Lircs fail to decode after the 0xffff.
[quote author="Barf"]Please file a bug ticket at https://sourceforge.net/p/lirc/tickets/ (https://sourceforge.net/p/lirc/tickets/) (You may need a sourceforge account.) Possibly you should give some more details on your "HTTP", for example configuration parameters.
The IrToy behaves a little bit "funny" when ending timeout occurs (that is the 0xffff), so I would not be surprised if it is a real bug in Lirc or the driver.[/quote]
I think this is not a lirc problem (irtoy driver - maybe, but not the lirc).
[quote author="Barf"]From the logs, it appears as if both Lircs fail to decode after the 0xffff.[/quote]
Why? LAPTOP successfully recognized second KEY_OK.
I can't undestand who is responsible for the problem. Linux' kernel stuff (cdc_acm, usb settings), lirc's irtoy driver, my lirc config or the device. So I can't corretly address my question.
I tried a lot of Kernel config parameters combinations, various lirc versions (from manual patching 0.9.0 till "official version"
in 0.9.1 and 0.9.3-devel from lastest git), various Linux kernels 3.9.0, 3.11.4, 3.19.0, and even "nice" lirc to 20. But nothing helps. I am in despair. =(
Barf wrote:From the logs, it appears as if both Lircs fail to decode after the 0xffff.
Why? LAPTOP successfully recognized second KEY_OK.
Because of this:
lircd-0.9.3-devel[20309]: Debug: read_raw ffff
lircd-0.9.3-devel[20309]: Debug: readdata 0 1000000
lircd-0.9.3-devel[20309]: Debug: c1000000
lircd-0.9.3-devel[20309]: Debug: trying "BOSE_RC6" remote
lircd-0.9.3-devel[20309]: Debug: decode: enter
lircd-0.9.3-devel[20309]: Debug: <s1000000
lircd-0.9.3-devel[20309]: Debug: sync
lircd-0.9.3-devel[20309]: Debug: timeout: 100000
lircd-0.9.3-devel[20309]: Debug: failed on header
lircd-0.9.3-devel[20309]: Debug: decode: 0
lircd-0.9.3-devel[20309]: Debug: decoding failed for all remotes
I can't undestand who is responsible for the problem. Linux' kernel stuff (cdc_acm, usb settings), lirc's irtoy driver, my lirc config or the device. So I can't corretly address my question.
Given that the IrToy has a funny response on timeout (which we probably do not want to fix), this should be a lirc or driver problem. Therefore my recommendation.
[quote author="Barf"]Given that the IrToy has a funny response on timeout (which we probably do not want to fix), this should be a lirc or driver problem. Therefore my recommendation.[/quote]
You mean this: viewtopic.php?f=29&t=965&hilit=delay+linux+lirc (http://dangerousprototypes.com/forum/viewtopic.php?f=29&t=965&hilit=delay+linux+lirc)
I created a ticket on LIRC sourceforge page.
But why there is no such treads on this forum? Why I'm the first, who faced this problem?!
Ticket #100. I'm lucky =)
https://sourceforge.net/p/lirc/tickets/100/ (https://sourceforge.net/p/lirc/tickets/100/)
I have read the LIRC irtoy drivers sources. And found the sampling mode manual (http://http://dangerousprototypes.com/docs/USB_IR_Toy:_Sampling_mode). I wrote a simple program, that turns device in sample mode and prints received raw bytes. I have found that after a pause in 3 seconds the next IR command will probably fails with error (0xFFFFFFFFFFFF indicates that). It's a big problem - almost 50% of delayed pressures will fail to be recognised. And there must be a pause of silence after the error for 1.7s, but user didn't know about that and keeps pressing the remote.
Why the errors occurs?
Log file and the reader program source code is attached.
A have tried a lot of Linux Kernel options in Power, Network and USB sections with no luck.
Maybe it's some kind of a hardware autosuspend problem (HTPC uses Intel Atom)?
I have programmed the remote to another codes (my remote: http://worldwide.bose.com/axa/assets/pd ... ecodes.pdf (http://worldwide.bose.com/axa/assets/pdf/owner_guides/HomeTheatre/cinemate_remotecodes.pdf)), now it behaves like one of a Sharp TV (code 10818 - it's impulse series were cute - legths were equal). Now it works almost fine.
So the problem was in combination of RC-6 remote + Intel Atom Gentoo Linux + IRtoy. I can't find out what exactly was wrong, but my attempts is finished. Ticket #100 on LIRC is meaningless - closing.
I finally have found RC-5 compatible mode of the remote (Phillips - code 11454). So I can use IrMan mode with correspondent IrMan driver. This is the best solution.
I fixed the three times 0xffff problem in the firmware of the device: all problems with lirc are gone: no funny delays etc. It just recognizes RC as it should without strange pauzes etc.
See my other post!