Kodi Community Forum

Full Version: Intel DG45ID integrated IR receiver not working
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Summary so far: The Intel DG45ID motherboard includes an integrated Consumer IR (CIR) module. That module is not properly enabled by 3.0.0-23-generic kernel in XBMCbuntu 10.0. A quick fix was found to enable the CIR module but it does not appear to be functioning even after being enabled.

Original Post:

Hi all,

I've run into a problem trying to enable my infrared receiver. It looks like it is being misidentified during boot as a UART (serial port). It also looks like this is a known problem, but I can't tell if a kernel fix was ever implemented nor do I know how to work around it on my own.

The hardware in question is an Intel DG45ID motherboard which incorporates the G45 Express chipset with a Winbond WPCD377I Super I/O. The Winbond chip includes support for Consumer Infrared (CIR) and the motherboard features a "standard" CIR header. I have connected an Inteset CIR module to the CIR header and the motherboard BIOS is up-to-date. The hardware is known good and works in Windows 7 once the proper driver is installed.

I am trying to get this remote receiver working in the latest 11.0 release of XBMCbuntu. I had hoped it would work out-of-the-box since this is mature hardware and I thought support for the Winbond Super I/O CIR was picked up somewhere in the 2.6 kernel.

I begin troubleshooting with dmesg, where I found the following error that indicates that the CIR could not be enabled because something else was already mapped to its memory region:

Quote:[ 5.591489] Winbond CIR 00:04: Region 0x2f8-0x2ff already in use!
[ 5.591720] Winbond CIR 00:04: disabled

[ 5.591725] Winbond CIR: probe of 00:04 failed with error -16

This led me to check /proc/ioports to see what that region was allocated to:

Quote: 0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
02f8-02ff : serial
03f8-03ff : serial
0400-047f : pnp 00:0a

Which in turn led me back to dmesg to gather more information, where I found the following related messages:

Quote:[ 0.199579] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.199783] pnp 00:04: [io 0x0a50-0x0a5f]
[ 0.199785] pnp 00:04: [io 0x0a40-0x0a4f]
[ 0.199787] pnp 00:04: [io 0x02f8-0x02ff]
[ 0.199792] pnp 00:04: [irq 3]
...
[ 3.467397] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 3.487763] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 3.604073] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A

So it looks like the CIR module is being identified early in the boot at a UART, which prevents it from later being configured correctly as an infrared receiver. Some googling turned up a thread in the Linux-Kernel mailing list where this issue was discussed in 2010, but I'm not clear what fix (if any) was ever officially sanctioned.

At this point I'm stuck. Can anybody suggest what steps I can take next to try to get this infrared receiver working?

Thanks!

Update:

I contacted one of the participants in the original Linux-Kernel thread for suggestions. He was kind enough to clarify two possible workarounds, neither of which has made it into the upstream. The workaround I implemented to make progress was to add "8250.nr_uarts=1" to my kernel options in /boot/grub/grub.cfg (immediately before "ro quiet splash").

After rebooting it appears that the Winbond CIR is being correctly configured. I find the following in dmesg:

Quote:[ 5.769630] IR NEC protocol handler initialized
[ 5.782533] IR RC5(x) protocol handler initialized
[ 5.797614] IR RC6 protocol handler initialized
[ 5.804447] Registered IR keymap rc-rc6-mce
[ 5.805167] input: Winbond CIR as /devices/pnp0/00:04/rc/rc0/input6
[ 5.805247] rc0: Winbond CIR as /devices/pnp0/00:04/rc/rc0

[ 5.807598] IR JVC protocol handler initialized
[ 5.812270] IR Sony protocol handler initialized
[ 5.818785] lirc_dev: IR Remote Control driver registered, major 248
[ 5.820589] rc rc0: lirc_dev: driver ir-lirc-codec (Winbond CIR) registered at minor = 0
[ 5.820592] IR LIRC bridge handler initialized

Reviewing /proc/ioports shows:

Quote: 0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
02f8-02ff : winbond-cir
03f8-03ff : serial
0400-047f : pnp 00:0a

With some anticipation I pointed my MCE remote at the IR receiver and started pushing buttons. Nothing happened. Oh well, time to dig in some more. I found the excellent "How-to get a seamless remote experience" thread and tried following the instructions there to debug. I really don't have a fundamental understanding of how all this is supposed to work so I'm just trying to follow instructions while I piece it all together.

  1. I ran irw, pointed the remote at the receiver, and pushed buttons. Nothing happened.
  2. I did sudo /etc/init.d/lirc stop and received confirmation that LIRC had stopped.
  3. I ran sudo ir-keytable -c -p NEC,RC-5,RC-6,JVC,SONY -t, pointed the remote at the receiver, and pushed buttons. Nothing happened.

I'll keep googling for ideas. I guess the key discovery so far is that the integrated CIR in the DG45ID isn't properly detected/configured by the current kernel, and I would guess that this may be true of the integrated CIR in other Intel motherboards as well.

For reference, here is the output of sudo ir-keytable:

Quote:Found /sys/class/rc/rc0/ (/dev/input/event6) with:
Driver Winbond CIR, table rc-rc6-mce
Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
Enabled protocols: NEC RC-5 RC-6 JVC SONY
Repeat delay = 500 ms, repeat period = 125 ms

Any tips on what I should try next would be appreciated, I'll be taking another look at the problem tonight. This is the third time I've tried building a XBMC dedicated HTPC, and this is the third time where the remote control seems to be the sticking point in getting it all to work right (with different hardware each time).
Did you

Code:
dpkg-reconfigure lirc

Chose "Linux-Input Layer event X"

As Transmitter you should chose "none"

Then go and test buttons again with

Code:
irw

(2012-07-27, 13:21)David1977 Wrote: [ -> ]Did you

Code:
dpkg-reconfigure lirc

Prior to making that change there was an error in boot.log

Code:
root@xbmc:/var/log# grep -i lirc boot.log
* Loading LIRC modules
* Unable to load LIRC kernel modules. Verify your
* selected kernel modules in /etc/lirc/hardware.conf

After running dpkg-reconfigure as suggested above I now longer have that error. However, irw still shows nothing.

Based upon a suggestion I received elsewhere I also tried "mode2" unsuccessfully:

Code:
root@xbmc:/etc/lirc# mode2 -d=/dev/lirc0 -r
mode2: error opening =/dev/lirc0
mode2: No such file or directory

I now see the following error in syslog, but I'm not sure yet how to fix it:

Code:
Jul 27 07:35:56 xbmc lircd-0.9.0[897]: error reading '/dev/lirc0'
Jul 27 07:36:43 xbmc lircd-0.9.0[897]: accepted new client on /var/run/lirc/lircd
Jul 27 07:36:52 xbmc lircd-0.9.0[897]: error reading '/dev/lirc0'
Jul 27 07:36:52 xbmc lircd-0.9.0[897]: error reading '/dev/lirc0'
Jul 27 07:36:52 xbmc lircd-0.9.0[897]: you are using an obsolete devinput config file: Bad address
Jul 27 07:36:52 xbmc lircd-0.9.0[897]: get the new version at http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput: Bad address
Jul 27 07:36:52 xbmc lircd-0.9.0[897]: error reading '/dev/lirc0'




Now this is to much for my understandings Wink

This thread helped me to get my remote to work:

http://forum.xbmc.org/showthread.php?tid...pid1062125

Maybe you can compare things and could use it for your own.

Nice weekend
I think I'm giving up on getting this to work. Here are the last things I've tried before surrendering Sad
  • The hardware is all known good. It works if I install and boot to Windows, but the objective here is to get it working in XBMCbuntu.
  • After reading about kernel mode IR drivers, I decided I would be less confused if I completely uninstalled lirc. So I did "apt-get remove lirc" before proceeding.

I believe the Winbond CIR has been detected and configured:
Code:
(snipped from /proc/bus/input/devices)

I: Bus=0019 Vendor=10ad Product=00f1 Version=0004
N: Name="Winbond CIR"
P: Phys=wbcir/cir0
S: Sysfs=/devices/pnp0/00:04/rc/rc0/input6
U: Uniq=
H: Handlers=kbd event6
B: PROP=0
B: EV=100013
B: KEY=fff 0 0 200 108fc32e 2376051 0 0 0 7 158000 4192 4001 8e9680 0 0 10000000
B: MSC=10

I think this should show me the raw IR (similar to mode2 in lirc):
Code:
% cat –v /dev/input/event6
(showed nothing)

I think this should show me if any IR signals are being decoded (similar to irw in lirc):
Code:
% ir-keytable

Found /sys/class/rc/rc0/ (/dev/input/event6) with:
        Driver Winbond CIR, table rc-rc6-mce
        Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
        Enabled protocols: RC-6
        Repeat delay = 500 ms, repeat period = 125 ms

% ir-keytable -p RC6 –t
(showed nothing)

I've basically run out of troubleshooting ideas and don't know enough to debug any further. Unless some kind soul has a suggestion I think I will be looking for another solution. I'm leaving this here to document my problems with the DG45ID with Inteset module in case someone else has the same issues.
Hi,

Just received an Inteset CIR receiver and could not get it working, stumbled on this thread. I have an Intel DG45ID motherboard also.
I'm using openelec 1.95.5 (2.0 beta 5), which has a newer kernel:
Code:
% uname -a
Linux openelec 3.2.21 #1 SMP Fri Jul 6 03:43:09 CEST 2012 x86_64 GNU/Linux

after adding "8250.nr_uarts=1" to the kernel options the CIR driver registers properly and is working in openelec/XBMC:

Code:
[    6.046804] Registered led device: cir::activity
[    5.527443] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
>[    5.925111] systemd-udevd[225]: starting version 186
[    6.046804] Registered led device: cir::activity
[    6.046845] Registered IR keymap rc-rc6-mce
[    6.047156] input: Winbond CIR as /devices/pnp0/00:03/rc/rc0/input3
[    6.047189] rc0: Winbond CIR as /devices/pnp0/00:03/rc/rc0
[    6.047333] input: MCE IR Keyboard/Mouse (Winbond CIR) as /devices/virtual/input/input4
[    6.057897] coretemp coretemp.0: Using relative temperature scale!
[    6.057905] coretemp coretemp.0: Using relative temperature scale!
[    6.082917] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[    6.082968] snd_hda_intel 0000:00:1b.0: irq 43 for MSI/MSI-X
[    6.083028] snd_hda_intel 0000:00:1b.0: setting latency timer to 64

Your suggestions in the above post show no output when i tried them. irw does, however:

Code:
% irw
185 0 KEY_DVD devinput
185 0 KEY_DVD_UP devinput
160 0 KEY_OK devinput
160 0 KEY_OK_UP devinput

(single OK button press with harmony 300, default delay settings)
I'm having some problems with the CIR receiver myself now, both under openelec and XBMCbuntu.
Installed XBMCbuntu, found CIR receiver is detected but not working. ir-keytable lists no supported protocols. Did "do-release-upgrade" to 12.04 LTS (kernel 3.2.0-29) and now ir-keytable -c -p RC-6 -t receives IR commands. Following the tutorial at http://forum.xbmc.org/showthread.php?tid=104541 should work now.

One problem remains. It seems the previous IR command is always repeated once when receiving the next command:

Remote is Harmony 300, Microsoft Windows Media Center SE as emulated device.
single MCE OK press:
Code:
1345025784.143772: event MSC: scancode = 800f041e
1345025784.143774: event sync
1345025784.248699: event MSC: scancode = 800f0422
1345025784.248701: event sync
1345025784.357401: event MSC: scancode = 800f0422
1345025784.357403: event sync

single MCE LEFT press:
Code:
1345025938.930134: event MSC: scancode = 800f0422
1345025938.930135: event sync
1345025939.033784: event MSC: scancode = 800f0421
1345025939.033786: event sync
1345025939.142887: event MSC: scancode = 800f0421
1345025939.142888: event sync

this sems very weird.
It seems to be driver related?
Hi P5ycho,

I had decided to abandon the CIR approach and was moving towards a USB based receiver instead. I still am having some minor problems even with USB but it is basically working.

Your observations regarding OpenELEC and the kernel versions are interesting, I might try putting the CIR receiver back in and doing some further experiments. Unfortunately I don't have much more time to play with trying to get this to work, as I need to get this system configured and into day-to-day use as a family media center.

FYI - A patch has been submitted for this kernel bug. It can be viewed at ( http://permalink.gmane.org/gmane.linux.d...ture/51554 ) - I have no insight into if or when it will ever make it into a production kernel.

You need to keep an eye on the wife acceptance meter, i understand. I have an older but working solution on the same system with an old XBOX remote that was working, but the xbox remote driver was axed when moving to kernel based IR handling. I can still dualboot to it.

I'm planning to get this fixed one way or another though, as the XBOX remote has to go and i want to move to a more recent kernel.

If you update XBMCbuntu to 12.04 LTS you should be able to use the CIR module. The only problem that remains is the repeated events. I tested with both Harmony 300 and 525, it's not the remote. I mailed the winbond-cir driver maintainer, but have not received a reply yet. There probably is some difference in handling the more recent Intel boards with the WPCD376I and the older DG45ID with the WPCD377I chip. Let's hope the driver maintainer can help out.
Hi P5ycho,

Confirming that I can duplicate everything you report.
  1. Hardware is an Intel DG45ID motherboard, Inteset CIR module, Dell RC1534034/00 (RC6) IR Remote
  2. Installed a fresh copy of OpenELEC1.95.6 (2.0 Beta 6).
  3. Did "mount -o remount,rw /flash" to make /flash editable.
  4. Added "8250.nr_uarts=1" to /flash/extlinux.conf (immediately before "ssh quiet")
  5. Rebooted
  6. Remote immediately begins working, with the "duplicate keypress" issue you describe.
Unfortunately, I think I have to draw the line here. I have the last quirks worked out with my USB IR receiver and I'm handing the box over to wife and kids later today. I will follow this thread with interest. Smile
Thanks for verifying, Zoofinator.
I'm still waiting for a reply from the driver maintainer, i'll update when i make any progress.
Two more quick notes:

From my point of view, there is one main advantage of the CIR module over a USB module; you can theoretically power up from the S5 state (while USB can typically only wake from the S3 state). I did confirm that wake from S5 works with the above solution. I think this is a bonus for wife/child acceptance factor and therefore CIR would still be better than USB if it could work reliably.

Regarding the "double key-press". I noticed that if you press a few keys and then set the remote down, sometimes the buffered keystroke will "pop" out on its own after a couple minutes. I couldn't get this to duplicate reliably.
Good news. The driver maintainer suggested using the latest source of the kernel module. I've compiled a new winbond-cir kernel module for XBMCbuntu (12.04 LTS, 3.2.0-29-generic-pae), the duplicate keypress issue is gone now.

Procedure:
- sudo apt-get install linux-headers-`uname -r`
- create a temp dir
- Get latest winbond-cir.c from kernel.org
- add Makefile:
Code:
obj-m = winbond-cir.o
KVERSION = $(shell uname -r)
all:
        make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean:
        make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean
- make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules
replace /lib/modules/`uname -r`/kernel/drivers/media/rcwinbond-cir.ko with your shiny new version.
Thanks for the folllow-up.

My USB remote receiver that was "trouble free" in testing has actually been pretty troublesome in use. I won't detail the problems here, but it has me thinking whether I should give the CIR module another attempt. Recompiling kernel module might be in my ability. Unfortunately the box is now in use as our primary media center so I'd have to take it offline.

I guess the really good news here is that it sound like all the changes are working their way though the distribution stream. Hopefully at some future date XBMCbuntu will just "work" with the DG45ID without any tweak.

There is a lot of good information in this thread for any owner of the DG45ID trying to get their CIR working. Potentially this may be of interest to other early-implementation Intel CIR boards (not really sure).