http://www.doctort.org/adam/general/update-on-twinhan-remote-for-mythbuntu-810.html

Change /usr/share/hal/fdi/preprobe/20thirdparty/lirc.fdi with the line
match key=”info.product” contains_ncase=”saa7134 ir”
to
match key=”info.product” contains_ncase=”IR-receiver inside an USB DVB receiver”

Thanks Adam for your useful site – used it to build my original MythTV box. Recently this box overheated due to dust build up causing the HDD to lose data.

Rebuilt the box using Mythbuntu 8.10 Intrepid Ibex but spent a lot of time trying to get my Twinhan VP7045 remote working.
hexdump -C /dev/input/irremote did not work. irw did not work.

Switched to tty using Ctrl-Alt-F1, logged in as root. hexdump and irw worked. ‘lsmod | grep evdev’ in the tty and from within the X terminal shows that the evdev module being referenced differently when hexdump and irw worked / did not work.

Found the comment by Mario Limonciello at https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/164627 last night and this fixed my problem. Use lshal to find out the input.product string – ‘IR-receiver inside an USB DVB receiver’ in my case.

xyz@iota:~$ lshal | grep input.product
input.product = ‘Macintosh mouse button emulation’ (string)
input.product = ‘Power Button (CM)’ (string)
input.product = ‘Power Button (FF)’ (string)
input.product = ‘PC Speaker’ (string)
input.product = ‘IR-receiver inside an USB DVB receiver’ (string)
input.product = ‘IR-receiver inside an USB DVB receiver’ (string)
input.product = ‘Logitech USB Receiver’ (string)
input.product = ‘Logitech USB Receiver’ (string)

Change the file /usr/share/hal/fdi/preprobe/20thirdparty/lirc.fdi from

true

to match your input.product string. Mine was changed to:

true

And the remote works now.

Rebuilt the box using Mythbuntu 8.10 Intrepid Ibex but spent a lot of time trying to get my Twinhan VP7045 remote working.
hexdump -C /dev/input/irremote did not work. irw did not work.

Switched to tty using Ctrl-Alt-F1, logged in as root. hexdump and irw worked. ‘lsmod | grep evdev’ in the tty and from within the X terminal shows that the evdev module being referenced differently when hexdump and irw worked / did not work.

Found the comment by Mario Limonciello at https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/164627 last night and this fixed my problem. Use lshal to find out the input.product string – ‘IR-receiver inside an USB DVB receiver’ in my case.

xyz@iota:~$ lshal | grep input.product
input.product = ‘Macintosh mouse button emulation’ (string)
input.product = ‘Power Button (CM)’ (string)
input.product = ‘Power Button (FF)’ (string)
input.product = ‘PC Speaker’ (string)
input.product = ‘IR-receiver inside an USB DVB receiver’ (string)
input.product = ‘IR-receiver inside an USB DVB receiver’ (string)
input.product = ‘Logitech USB Receiver’ (string)
input.product = ‘Logitech USB Receiver’ (string)

Change the file /usr/share/hal/fdi/preprobe/20thirdparty/lirc.fdi from

true

to match your input.product string. Mine was changed to:

true

And the remote works now.

maybe a lil off-topic, but i found this thread googling…..

Does anybody of you know what IR-transistor hardware piece is inside this IR receiver from twinhan, i mean brand and model.

regards,

Sven

Hi Adam,

You mentioned in your article that you had not been able
to get the remote’s POWER button working. If that is still the
case, you might like to try adding the line:
POWER 0×1001d
to the lircd.conf file. This enabled me to define actions for POWER
that seemed to work OK when I pressed the POWER button on my remote.

Hope this helps someone!

Doug.

For 8.04 things seem different and easier. I set up my hardware.conf with
REMOTE_DRIVER=”devinput”
REMOTE_DEVICE=”/dev/input/by-id/usb-Twinhan_Tech_Remote_Control_1111111-event-kbd”

… and that seems to be all that needs doing. Bear in mind the hardware.conf format has changed between Ubuntu 7 and 8 (I originally just copied my old file in, and got annoyed when it wouldn’t work.)

Thanks again for the original guide.

- Angus

/usr/sbin/lircd -H dev/input –device=/dev/input/event2 -n

Then I can get irw to work. So now I just need to setup my own rc.d to run this on boot and I then do the key map to elisa.

The new lirc has a new file format but even with the new format it does not like /dev/input as a driver.

root@firefly02:~# vi /etc/lirc/hardware.conf
root@firefly02:~# /usr/sbin/lircd -n
lircd-0.8.3pre1[7014]: config file contains no valid remote control definition
lircd-0.8.3pre1[7014]: lircd(userspace) ready
lircd-0.8.3pre1[7014]: accepted new client on /dev/lircd
lircd-0.8.3pre1[7014]: could not get file information for /dev/lirc
lircd-0.8.3pre1[7014]: default_init(): No such file or directory
lircd-0.8.3pre1[7014]: caught signal
Terminated
root@firefly02:~# vi /etc/lirc/hardware.conf
root@firefly02:~# /etc/init.d/lirc restart
* Stopping remote control daemon(s): LIRC [fail]
* Loading LIRC modules [ OK ]
* Starting remote control daemon(s) : LIRC Driver `/dev/input’ not supported.

Dies when I run irw in a new terminal.

The receiver presents itself as a HID class device which means the decoding of the IR code must be done inside the receiver. Programs like irrecord will not be able to access the raw IR data.

The only way I can think of to get another controller to work is to either find a remote control which puts out exactly the same code as the original controller or possibly use a universal remote control to send those same codes.