<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>On Mon, Jun 29, 2015 at 12:27 PM, Jerry Rubinow <<a href="mailto:jerrymr@gmail.com" target="_blank">jerrymr@gmail.com</a>> wrote:<br>
> On Mon, Jun 29, 2015 at 1:04 PM, Mike Thomas <<a href="mailto:mt3@pfw.demon.co.uk" target="_blank">mt3@pfw.demon.co.uk</a>> wrote:<br>
>> On Mon, 29 Jun 2015 18:28:32 +0200<br>
>> Alec Leamas <<a href="mailto:leamas.alec@gmail.com" target="_blank">leamas.alec@gmail.com</a>> wrote:<br>
>>> On 29/06/15 17:31, Jerry Rubinow wrote:<br>
>>> > On Sun, Jun 28, 2015 at 2:50 PM, Jerry Rubinow <<a href="mailto:jerrymr@gmail.com" target="_blank">jerrymr@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> On Jun 28, 2015 13:36, "Alec Leamas" <<a href="mailto:leamas.alec@gmail.com" target="_blank">leamas.alec@gmail.com</a>> wrote:<br>
>>> >>><br>
>>> >>> On 28/06/15 15:54, Jerry Rubinow wrote:<br>
>>> >>><br>
>>> >>>><br>
>>> >>>> Nick, it looks like 3.16, what I've been running, has that patch<br>
>>> >>>> integrated into the kernel driver.  I tried a clean Ubuntu 15.04<br>
>>> >>>> install and the problem is there as well.  Unfortunately the<br>
>>> >>>> bios doesn't let me disable xHCI.    I think it may be time to<br>
>>> >>>> visit newegg for a new ir receiver.<br>
>>> >>><br>
>>> >>><br>
>>> >>> TBH, I havn't read the complete thread. That said, I understand<br>
>>> >>> your situation as if the kernel decoding route is at a dead end<br>
>>> >>> for you (?).<br>
>>> >>><br>
>>> >>> Note, the alternative is to let lirc decode the raw timing data.<br>
>>> >>> I know this has been mentioned before, but perhaps you missed<br>
>>> >>> this opportunity?<br>
>>> >>><br>
>>> >>> Obviously, the existing config files doesn't work for you. One<br>
>>> >>> option would be to use irrecord to create a new config file after<br>
>>> >>> setting the protocol to 'lirc' and re-checking that mode2 still<br>
>>> >>> works as expected. Might work, dunno, but given that mode2 is OK<br>
>>> >>> for you I think you have a fair chance.<br>
>>> >>><br>
>>> >>> Cheers!<br>
>>> >>><br>
>>> >>> --alec<br>
>>> >><br>
>>> >> Alec, that's probably worth trying, I'll try irrecord.  However, my<br>
>>> >> expectation is that the bits coming out of the driver will be<br>
>>> >> faulty due to something in the USB 3/xHCI implementation.<br>
>>> >><br>
>>> >> I'll try that tonight.<br>
>>> >><br>
>>> >> -Jerry<br>
>>> ><br>
>>> > Nope, I tried the config generated by irrecord and maybe one out of<br>
>>> > 10 to 20 presses would generate something it could recognize in<br>
>>> > irw, but usually not the key I pressed.<br>
>>><br>
>>> But you did run irrecord successfully enough to create a config<br>
>>> file?! This does indeed looks strange.<br>
>>><br>
>>> Just a double check: you don't have physical (i. e., IR) disturbances<br>
>>> around? Low energy/fluorescent lamps or so?<br>
>><br>
>> Dear OP,<br>
>><br>
>> You might like to look into the archives for my earlier comments<br>
>> regarding IR disturbances. Some monitors and TV sets produce enough IR<br>
>> on their own that you might as well give up using an infra red remote<br>
>> control. All my monitors and TVs fall into that category. It just so<br>
>> happens that the TV's own remote control protocol is transmitted in the<br>
>> blanks between the IR flashes given off by the back light. I couldn't<br>
>> find another remote control which would transmit in these bursts. I<br>
>> even bought a Sharp IR receiver chip to go with my Sharp TV and that<br>
>> didn't work. It took me weeks of trials before I eventually gave up.<br>
>><br>
>> I settled on a Bluetooth remote control which I ordered from Maplin.<br>
>> This has been flawless. They are coded so it is possible to have<br>
>> several in one building without them conflicting. You just plug it in<br>
>> and it comes up as a HID input device (a keyboard and mouse). No<br>
>> drivers, no nothing. I have the key mappings if you want them.<br>
>><br>
>> Cheers,<br>
>><br>
>> Mike.<br>
>><br>
><br>
> Mike, I've been running this setup (tv, a/v receiver, etc), in this<br>
> room for years.  The only difference between totally working and<br>
> totally not working is swapping in a different frontend computer with<br>
> a newer version of mythbuntu.  No other moved/added/removed devices.<br><br></blockquote></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 29, 2015 at 1:50 PM Roger Heflin <<a href="mailto:rogerheflin@gmail.com" target="_blank">rogerheflin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I had to modify the a kernel driver for xhci to get mine to work.<br>3.16.6 did not work without the change.<br><br>I have not been able to update kernels last time I tried as the newer<br>kernels don't yet have the modification included last time I checked.<br><br>I think I posted the fix someplace, if not yell and I can probably<br>figure out the change that I made.  Without the change lirc did "see"<br>keypresses but none of it made any sense (garbled stuff).<br><br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I can verify that making Roger's change to the usb core fixes the issue. </div><div><br></div><div>To summarize, an older USB IR receiver will not work when plugged into a USB2 or USB3 port that is using xHCI.  Bits will be dropped and scancodes will not be received properly.  This is below the level of lirc or ir-keytables.  I know it happens in 14.04 and later versions.</div><div><br></div><div>Patching config.c in drivers/usb/core fixes the issue (changing a line that says n = 32 to n = 10) and compiling a new kernel.</div><div><br></div><div>Now my only problem is that after recompiling I no longer have any files in /sys/class/rc.  So I can use lirc, but not ir-keytable.  A wrong kernel config option?  Dunno.</div><div><br></div><div>-Jerry</div><div> </div></div></div></div>