[mythtv-users] Jetway motherboard IR receiver

Wed Jun 1 03:13:14 UTC 2011

On May 31, 2011, at 9:46 AM, lists.md301 wrote:

> On Wed, May 25, 2011 at 6:08 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
> On Feb 12, 2011, at 1:46 PM, lists.md301 wrote:
> 
> > On 2/11/11, Jarod Wilson <jarod at wilsonet.com> wrote:
> >> On Feb 11, 2011, at 4:16 PM, lists.md301 wrote:
> >>
> >>> I recently purchased a Jetway Atom D525 (dual-core) Nvidia ION2 mini-ITX
> >>> barebone machine (HBJC231C98-525-B), a Newegg promo, to use as a frontend
> >>> only...
> >>> [snip].
> >>>
> >>> I haven't been able to find any definitive info about what the IR chipset
> >>> is, or how it might be supported by LIRC.  The Jetway website has a
> >>> Windows driver for it which seems to indicate that it is a Fintek CIR
> >>> chip, but my internet searches have turned up nothing about Linux support,
> >>> or even anyone asking the question that I am.  The motherboard is a Jetway
> >>> NC98-F.  I've tried one of the latest kernels (2.6.35) with patches for
> >>> some other Atom 330 motherboards (ASRock), as well as all the other
> >>> "stock" modules from LIRC 0.8.7.  As the barebone is a relatively new
> >>> offering, I'm not surprised.  Anybody know something?
> >>
> >> Yes. There's no Linux driver for that hardware yet. Its planned,
> >> but I don't have an ETA.
> >>
> >
> > Thanks for the reply, Jarod.  I considered the best way to contact you
> > about this (IRC/email), but figured I'd start here so that anyone else
> > interested might learn something.  It's doubtful I'd have the time,
> > but I have thought about taking a crack at it myself.  I'm a
> > hardware/embedded engineer in my day job, so it might be interesting,
> > but I face a learning curve on the specifics.
> >
> > I'll keep an eye out for any progress.  Glad to hear it's on your radar.
> 
> https://patchwork.kernel.org/patch/816562/
> 
> Success!  Thanks Jarod!
> 
> 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.

I probably should have included the media_build doc link... Its entirely
possible to use this driver as-is with older kernels, it just requires an
entire replacement v4l/dvb/rc stack. :) I've successfully used the driver
with a 2.6.32-based kernel myself.

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

"Basic" Approach works.

> 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.
> 
> 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),

It wasn't. The fintek-cir driver works with the rc-core ir-lirc-codec plugin,
which provides a classic /dev/lirc0 interface to the hardware.

> I upgraded to lirc-0.9.0 via an overlay ebuild.

That part was definitely required (that, or patching lirc 0.8.7).

> 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.

Ideally, /dev/input/by-id/ links should be set up for all rc-core drivers, but
that's not the case for any of the pnp-based drivers yet, only the usb ones.
On my TODO list to figure out how to remedy that.

> My final mistake was thinking that the lircd.conf for the MCE USB and a devinput device are the same.

Yeah, not even close.

>  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.

Well, I have one that I use myself, but it may or may not line up with how you
have things mapped.

> 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.

That's only required if you're using the classic /dev/lirc0 interface. For in-kernel
decode and lircd in devinput mode, echoing something into protocols will actually
disable your remote, more or less.

> 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.
> 
> 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.
> 
> Once again, thanks Jared.  I expect this will be appearing in the Linux 3.0.0 kernel!  ;)

Yep, its queued up to be in 3.0.0-rc2, iirc.

-- 
Jarod Wilson
jarod at wilsonet.com