ASRock ION 330HT nettop running Sabayon Linux [Solved]

[cloc3]

***
OMISSIS
***

above, there was my troubles about this problem:
hacking the asrock lirc_wb677 source code to work with:

1. >app-misc/lirc-0.8.7
2. kernel 2.6.36*
3. other staging lirc drivers included in kernel sources (such as the Terratec T3 dvb_usb related).

my omissis was very long and higly noisy. but the solution came to me from Fitzcarraldo in the following post.
Now I'm using nuvoton_cir driver manually patched inside linux-2.6.36-gentoo-r7 kernel and app-misc/lirc-0.9.0-pre1.

I've not tested nothing about the power issue bug.
I'll came back later to relate about.

[Fitzcarraldo]

cloc3, with the LIRC move to in-kernel drivers, plus various changes by ASRock to their Ubuntu lirc_wb677 driver's source code, it's just too difficult to get something working with the latest kernels by hacking ASRock's lirc_wb677 source code.

However, I have just been doing some googling and it seems that LIRC developer Jarod Wilson wrote an ir-core driver for the ASRock ION 330HT in October 2010 (see his announcement post Patchwork IR: add driver for Nuvoton w836x7hg integrated CIR). It's called nuvoton-cir. The output of the command modinfo nuvoton_cir quoted on the LIRC Mailing List on 30 January 2011 was:

filename: /lib/modules/2.6.37-12-generic/kernel/drivers/media/IR/nuvoton-cir.ko
license: GPL
author: Jarod Wilson <jar...@redhat.com>
description: Nuvoton W83667HG-A & W83677HG-I CIR driver
srcversion: 98C832A95EDC5626195F2C2
alias: acpi*:NTN0530:*
alias: pnp:dNTN0530*
alias: acpi*:WEC0530:*
alias: pnp:dWEC0530*
depends: ir-core
vermagic: 2.6.37-12-generic SMP mod_unload modversions
parm: debug:Enable debugging output (int)

I don't have time at the moment to investigate this further on my ASRock ION 330HT, but perhaps you can. I have just successfully merged lirc-0.9.0_pre1 on one of my laptops with the 2.6.37-sabayon kernel, using the ebuild created by using the patch given in Gentoo Bugzilla Bug Report No. 345833, so I just need to get some time to actually repeat that on my ASRock ION 330HT, but it's looking promising based on the kernel build I produced on this laptop in January:

Code: Select all

$ locate nuvoton
/lib/modules/2.6.37-sabayon/kernel/drivers/media/IR/nuvoton-cir.ko
/usr/local/portage/app-misc/lirc/files/lircrc_nuvoton
/usr/src/linux-2.6.37-sabayon/drivers/media/IR/nuvoton-cir.c
/usr/src/linux-2.6.37-sabayon/drivers/media/IR/nuvoton-cir.h
/usr/src/linux-2.6.37-sabayon/include/config/ir/nuvoton.h

I suppose it would be too much to hope that it works out of the box?!

Anyway, give it a try.

Apparently the new driver still has a small power-on bug -- see the post about a bug fix just yesterday by Jarod Wilson in the following thread: Asrock ION 330HT Remote - Power on issue. But that will be fixed in the 2.6.38 or 2.6.39 kernel (or you can fix it yourself, as the details are given in that thread).

[cloc3]

I confirm.

nuvoton-cir is well working for me.

[Fitzcarraldo]

OK, today I finally got around to updating my ASRock ION 330HT nettop to the 2.6.37-sabayon kernel using Entropy, and I installed lirc-0.9.0_pre1 using a Portage local overlay because it's not in the Portage main tree or Entropy yet.

The kernel config for the 2.6.37-sabayon kernel already has the new nuvoton-cir driver configured as a module, and all I needed to do after booting was to enter the command modprobe nuvoton-cir and the ASRock remote works. I can't find which key selects Home in XBMC, but I'll play with the remote controller key config file later. I'll also specify the nuvoton-cir module in the file /etc/conf.d/modules so that the module is loaded automatically at boot.

So, there you have it boys and girls: ir-core in Linux kernel 2.6.36 and onwards gives you plug-and-play IR remote control for your ASRock ION 330HT. No need anymore to break your head like I had to do a year ago.

A big "thank you" to LIRC developer Jarod Wilson for writing the ir-core nuvoton-cir driver, and also to Nuvoton for giving him an ASRock ION 330HT nettop, the datasheet for the IR chip and LIRC driver source code for the IR chip so that he could write and test the ir-core driver. I wish all manufacturers were as Linux-friendly as Nuvoton.

[cloc3]

I'll also specify the nuvoton-cir module in the file /etc/conf.d/modules so that the module is loaded automatically at boot.

this step seems non needed for me.
nuovoton-cir module is loaded by itself without any particular configuration in /etc/udev.

A big "thank you " ...

yes. I agree.

[Fitzcarraldo]

Does your kernel config have CONFIG_IR_NUVOTON=m (module) or CONFIG_IR_NUVOTON=y (in-kernel)?

I have CONFIG_IR_NUVOTON=m and, indeed, after I reboot the module is loaded even without me adding nuvoton-cir to /etc/conf.d/modules:

Code: Select all

# lsmod | grep nuv
nuvoton_cir            10402  0
ir_core                10387  9 rc_rc6_mce,ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,nuvoton_cir,ir_nec_decoder

[cloc3]

I have CONFIG_IR_NUVOTON=m

I have too CONFIG_IR_NUVOTON=m.

and the module is correctly loaded by itself, without any kind of configuration.

[cloc3]

ok. I've solved my main problem with nuvoton-irc driver.

but a minor issue still remain around the remote control.
when I flow up and down any list in xbmc, the pointer jumps two lines for any click.

and this behaviour shows some funny aspects:

1. The problem affects just the Up, Down, Left and Right remote control buttons. No any other button is affected.
2. Stopping lircd all remote control buttons are no more actives in xbmc, but the four ones above. If I stop or kill lircd Up, Down, Left and Right buttons are working again in xbmc, and I can move up and down the focus with them. But I can't send (for example) a return command with the Ok button.
3. I'm not able to find any anomalous input, connected with remote buttons from any /dev/input device. Just the cat /dev/lircd0 command collects noise from remote.
4. This behaviour does not depends from any other phisycal receiver. I have a usb terratec T3 dvb card which can receive remote control signals but I don't use it for this service and, to be sure, I cover it with a cooking foil.

A simple (but uncorrect, I think) way to workaround the problem is to comment all Up, Down, Left and Right buttons definitions in /etc/lirc/lircd.conf.

Which may it be the misterious channel that doubles remote arrows signals to xbmc?

[Fitzcarraldo]

It appears as if you have one of the LIRC modules loaded as well as the ir-core nuvoton-cir module, doesn't it?

Here's a thread that might be of help: Lirc update broke functionality, as that Arch Linux LIRC user was also experiencing double key presses when he pressed a key once.

Or I wonder if you are experiencing the bug discussed in the following LIRC mailing list thread: Detecting button presses twice?

On a separate note, when I built lirc-0.9.0_pre1 on my ASRock ION 330HT, the result was that /etc/init.d/lircd was removed, so the LIRC daemon obviously isn't running on my nettop, although some of the ASRock remote controller's keys work due to the nuvoton-cir module (I am not using my ASRock at the moment but, if I recall correctly, the keys that function are: ENTER, Volume +, Volume -, Channel +, Channel -, Play, Pause, Stop, Mute, <, >, ^, v ). Now, I notice the following is hard-coded inside lirc-0.9.0_pre1.ebuild:

Code: Select all

if kernel_is -ge 2 6 36; then
      MY_OPTS="--with-driver=userspace"

which I believe is the same as --with-driver=none. I assume this means that LIRC 0.9.0_pre1 is built without any of the old LIRC modules. In this case should the initscript /etc/init.d/lircd still be created? If yes, why isn't it created in my case? I have tried to build lirc-0.9.0_pre1 with LIRC_DEVICES="userspace", LIRC_DEVICES="mceusb" and LIRC_DEVICES="wpc8769l" but in none of these cases is the file /etc/init.d/lircd created. So how come one is created in your case when you merge lirc-0.9.0_pre1?

By the way, I notice that the package media-tv/v4l-utils provides the utility ir-keytable, which is supposed to be used with the new ir-core modules. I'm not sure what that utility does precisely, nor how to use it, but I assume it is used to create a key table for the remote controller, which seems to be what I need to get the rest of the keys working. I'm not sure what to do, and unfortunately so far there seems to be very little documentation and posts on the Web about these new ir-core modules. That Arch Linux thread looks like it might contain a solution, but I have to leave on a business trip tomorrow so I won't get a chance to play with my ASRock ION 330HT for a couple of weeks unless I burn the midnight oil tonight, which I don't fancy doing. See if you can come up with something.

[Fitzcarraldo]

OK, so I'm going to burn a little midnight oil after all.

I powered up my ASRock ION 330HT and merged v4l-utils (it's not in Entropy, so I had to use Portage). The utility ir-keytable has the following command set:

Code: Select all

# ir-keytable --help
Usage: ir-keytable [OPTION...] --device [/dev/input/event* device]
  or:  ir-keytable [OPTION...] --sysdev [ir class (f. ex. rc0)]
  or:  ir-keytable [OPTION...] [for using the rc0 sysdev]

Allows get/set IR keycode/scancode tables
You need to have read permissions on /dev/input for the program to work

On the options bellow, the arguments are:
  DEV      - the /dev/input/event* device to control
  SYSDEV   - the ir class as found at /sys/class/rc
  TABLE    - a file wit a set of scancode=keycode value pairs
  SCANKEY  - a set of scancode1=keycode1,scancode2=keycode2.. value pairs
  PROTOCOL - protocol name (nec, rc-5, rc-6, other) to be enabled
  DELAY    - Delay before repeating a keystroke
  PERIOD   - Period to repeat a keystroke
  CFGFILE  - configuration file that associates a driver/table name with a
keymap file

Options can be combined together.

  -a, --auto-load=CFGFILE    Auto-load a table, based on a configuration file.
                             Only works with sysdev.
  -c, --clear                clears the old table
  -d, --device=DEV           ir device to control
  -D, --delay=DELAY          Sets the delay before repeating a keystroke
  -k, --set-key=SCANKEY      Change scan/key pairs
  -p, --protocol=PROTOCOL    Protocol to enable (the other ones will be
                             disabled). To enable more than one, use the option
                             more than one time
  -P, --period=PERIOD        Sets the period to repeat a keystroke
  -r, --read                 reads the current scancode/keycode table
  -s, --sysdev=SYSDEV        ir class device to control
  -t, --test                 test if IR is generating events
  -v, --verbose              enables debug messages
  -w, --write=TABLE          write (adds) the scancodes to the device
                             scancode/keycode table from an specified file
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Report bugs to Mauro Carvalho Chehab <mchehab@redhat.com>.

Reading through that Arch Linux thread I referenced earlier, it is for a MCEUSB IR receiver, not the ASRock's Nuvotron IR receiver, and most of the Arch Linux users who posted in that thread 'solve' the problem by blacklisting or removing the ir-core mceusb module and re-instating the old LIRC lirc_mceusb module. Which is not a solution, really, it's a 'work-around'.

Anyway, one of the things in that thread that caught my eye was the showkey command. I tried it in a Konsole, and it displays a key code for every key I press on the ASRock remote. And it seems that some (all?) of the keys on the remote are being interpreted as if I am pressing a key or keys on my keyboard. For example, if I press the ON/OFF key at the top right of the remote, KDE pops up its logout window ('the one which prompts the user to click on 'Logout', 'Turn Off Computer' or 'Restart Computer'). If I press ENTER on the remote then I get five carriage returns in a KWrite window. If I press the ^ key on the remote then the cursor moves up five lines in a KWrite window. And so on.

The command cat /proc/bus/input/devices shows the following:

Code: Select all

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
U: Uniq=
H: Handlers=kbd event0
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
U: Uniq=
H: Handlers=kbd event1
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0003 Vendor=0603 Product=00f2 Version=0110
N: Name="NOVATEK USB Keyboard"
P: Phys=usb-0000:00:04.0-3/input0
S: Sysfs=/devices/pci0000:00/0000:00:04.0/usb2/2-3/2-3:1.0/input/input2
U: Uniq=
H: Handlers=sysrq kbd event2
B: EV=120013
B: KEY=10000 7 ff9f207a c14057ff febeffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=0603 Product=00f2 Version=0110
N: Name="NOVATEK USB Keyboard"
P: Phys=usb-0000:00:04.0-3/input1
S: Sysfs=/devices/pci0000:00/0000:00:04.0/usb2/2-3/2-3:1.1/input/input3
U: Uniq=
H: Handlers=kbd event3
B: EV=13
B: KEY=7fff8000 0 2000000 3878 d801d001 1e0000 0 0 0
B: MSC=10

I: Bus=0003 Vendor=045e Product=00d1 Version=0111
N: Name="Microsoft Microsoft Optical Mouse with Tilt Wheel"
P: Phys=usb-0000:00:04.0-4/input0
S: Sysfs=/devices/pci0000:00/0000:00:04.0/usb2/2-4/2-4:1.0/input/input4
U: Uniq=
H: Handlers=mouse0 event4
B: EV=17
B: KEY=170000 0 0 0 0 0 0 0 0
B: REL=1c3
B: MSC=10

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/devices/platform/pcspkr/input/input5
U: Uniq=
H: Handlers=kbd event5
B: EV=40001
B: SND=6

I: Bus=0019 Vendor=1050 Product=00b4 Version=0073
N: Name="Nuvoton w836x7hg Infrared Remote Transceiver"
P: Phys=
S: Sysfs=/devices/virtual/rc/rc0/input6
U: Uniq=
H: Handlers=kbd event6
B: EV=100013
B: KEY=fff 0 0 0 108fc326 2176051 0 0 0 7 158000 4190 100001 9e9680 0 0 10000000
B: MSC=10

I: Bus=0001 Vendor=10ec Product=0885 Version=0001
N: Name="HDA Digital PCBeep"
P: Phys=card0/codec#0/beep0
S: Sysfs=/devices/pci0000:00/0000:00:08.0/input/input7
U: Uniq=
H: Handlers=kbd event7
B: EV=40001
B: SND=6

You can see from the above output that the remote is being seen as a normal input device by the kernel.

Also, to reiterate, in my case the lirc daemon is not running (no /etc/init.d/lircd initscript exists and the daemon is definitely not running).

So my conclusions (which may be wrong!) are as follows:

a) No LIRC daemon is needed to use the ir-core modules. I'm not sure what, if anything, of the app-misc/lirc package is actually needed when using the nuvotron-cir module.

b) Only the ir-core modules are needed. In my case I think the only ones I need loaded to enable me to use the ASRock remote are the following (I used rmmod -f to remove the others, and the remote is still driving XBMC):

Code: Select all

# lsmod | grep lirc
ir_lirc_codec           2716  0
lirc_dev                6598  1 ir_lirc_codec
ir_core                10387  4 ir_lirc_codec,ir_rc6_decoder,nuvoton_cir

c) I need to find a way to map the keys on the remote to the keys and mouse clicks that XBMC understands. How to do that is the $64,000 question.