<div class="gmail_quote">On Wed, May 25, 2011 at 6:08 PM, Jarod Wilson <span dir="ltr"><<a href="mailto:jarod@wilsonet.com">jarod@wilsonet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Feb 12, 2011, at 1:46 PM, lists.md301 wrote:<br>
<br>
> On 2/11/11, Jarod Wilson <<a href="mailto:jarod@wilsonet.com">jarod@wilsonet.com</a>> wrote:<br>
>> On Feb 11, 2011, at 4:16 PM, lists.md301 wrote:<br>
>><br>
>>> I recently purchased a Jetway Atom D525 (dual-core) Nvidia ION2 mini-ITX<br>
>>> barebone machine (HBJC231C98-525-B), a Newegg promo, to use as a frontend<br>
>>> only... </div></div></blockquote><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">>>> [snip].<br>
>>><br>
>>> I haven't been able to find any definitive info about what the IR chipset<br>
>>> is, or how it might be supported by LIRC. The Jetway website has a<br>
>>> Windows driver for it which seems to indicate that it is a Fintek CIR<br>
>>> chip, but my internet searches have turned up nothing about Linux support,<br>
>>> or even anyone asking the question that I am. The motherboard is a Jetway<br>
>>> NC98-F. I've tried one of the latest kernels (2.6.35) with patches for<br>
>>> some other Atom 330 motherboards (ASRock), as well as all the other<br>
>>> "stock" modules from LIRC 0.8.7. As the barebone is a relatively new<br>
>>> offering, I'm not surprised. Anybody know something?<br>
>><br>
>> Yes. There's no Linux driver for that hardware yet. Its planned,<br>
>> but I don't have an ETA.<br>
>><br>
><br>
</div></div><div class="im">> Thanks for the reply, Jarod. I considered the best way to contact you<br>
> about this (IRC/email), but figured I'd start here so that anyone else<br>
> interested might learn something. It's doubtful I'd have the time,<br>
> but I have thought about taking a crack at it myself. I'm a<br>
> hardware/embedded engineer in my day job, so it might be interesting,<br>
> but I face a learning curve on the specifics.<br>
><br>
> I'll keep an eye out for any progress. Glad to hear it's on your radar.<br>
<br>
</div><a href="https://patchwork.kernel.org/patch/816562/" target="_blank">https://patchwork.kernel.org/patch/816562/</a><br>
<br>
--<br>
<div class="im">Jarod Wilson<br><br></div></blockquote></div>Success! Thanks Jarod!<br><br>A little more background for the benefit of the list. On this particular frontend-only (Gentoo) machine, before attempting this patch I had previously been running gentoo-sources-2.6.36-r5 kernel, as it was the minimum above my usual local standard of 2.6.35-gentoo-r15 that allowed me to use HDMI audio with the ION2 chipset (nvidia-drivers-260.19.36). Inspecting the patch, I quickly realized I needed to move up a kernel rev, as this patch assumes the new rc-core drivers which replace the ir-core stuff. (Maybe there was another patch available to make this work in a previous kernel, but I couldn't find it.) I had been using an MCE USB IR module which made use of the built-in kernel modules, along with lirc-0.8.7.<br>
<br>Patch applied cleanly to 2.6.38-gentoo-r5, and I was able to select the new fintek_cir module option. Two wrinkles I encountered. First, using my kernel oldconfig when compiling the new one, it built the rc-core stuff into the kernel, instead of as modules. My bad, as I should have paid closer to attention to the first time I ran menuconfig.<br>
<br>Second, this was my first attempt at using a devinput device, which led to a couple of issues. Not sure in hindsight whether it was absolutely necessary (Jared may tell me it was), I upgraded to lirc-0.9.0 via an overlay ebuild. It was in debugging this process that I discovered that rc-core wasn't compiled as a module. It took me a little while to understand how devinput devices are discovered and used. Once I understood what the documentation was telling me, I was able to see that an rc0 system resource was being created and linked to a /dev/input/eventX. The Gentoo wiki entry about LIRC is pretty good at explaining this. I had to create my own udev rule (as none exists in my way-behind udev version) so that a /dev/input/irremote soft link is created when the fintek_module is probed. The Gentoo wiki describes parsing a /sys/class/rc subdirectory to search/grep for the proper link for the handle, and putting that in the /etc/conf.d file, but I preferred the udev rule route.<br>
<br>My final mistake was thinking that the lircd.conf for the MCE USB and a devinput device are the same. They're not. Likewise the keymap names that I previously used are different for the .lircrc that existed in my mythtv home directory. Once I finally got irw to give me an output from the fintek_cir module, I had to recreate my own .lircrc by editing a copy of the one I had been using for the MCE remote. Maybe one existed somewhere, but I didn't have the patience to track it down.<br>
<br>So far, very happy with its performance. Better than the MCE USB receiver, as I'd sometimes get double key presses with that. Not sure why. For the Fintek chip, I did not have to echo at boot anything to /sys/class/rc/rc0/protocols as something somewhere in the doc indicated to prevent double key presses.<br>
<br>An additional benefit of the 2.6.38 kernel (versus 2.6.37) is I no longer have a kernel oops/dump in my dmesg when the HDMI audio is discovered. Never figured out what was causing that, but it did not effect performance. This frontend is a dedicated myth box.<br>
<br>An additional aside, beyond IR. In my first email, I mentioned that I ran a 2.6.32 kernel. Subsequently, as indicated above, I updated to .35 on my master (and only) backend, because I had what ended up appearing as disk I/O issues (write data corruption) when Firewire STB recordings were happening at the same time as HD-Homerun recordings. Firewire was always the instigator, as 2 HDHR recordings were never a problem. Moving up kernels "fixed" it, but I was never sure how. Could not find a system logged reason for it anywhere, and reading kernel commit/updates didn't give me any ideas either. Maybe it was disk I/O, but it could have been an ethernet issue was well.<br>
<br>Once again, thanks Jared. I expect this will be appearing in the Linux 3.0.0 kernel! ;)<br>