[mythtv-users] Jetway motherboard IR receiver

lists.md301 lists.md301 at gmail.com
Tue May 31 13:46:26 UTC 2011


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/
>
> --
> Jarod Wilson
>
> 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.

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

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.

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.

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!  ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20110531/8d37ad23/attachment.html 


More information about the mythtv-users mailing list