PDA

View Full Version : LIRC + Fedora 7



__Adam__
29th July 2007, 06:08 PM
hello

i have problem with LIRC under fedora 7
i installed from atrpm repos:
lirc-lib-0.8.2-68.fc7
lirc-0.8.2-68.fc7
lirc-kmdl-2.6.22.1-33.fc7-0.8.2-68.fc7
lirc-devices-0.8-4.fc7

my kernel: 2.6.22.1-33.fc7

when trying:


/sbin/modprobe lirc_gpio
FATAL: Error inserting lirc_gpio (/lib/modules/2.6.22.1-33.fc7/updates/drivers/lirc/lirc_gpio.ko): Unknown symbol in module, or unknown parameter (see dmesg)




dmesg | grep lirc
lirc_dev: no version for "struct_module" found: kernel tainted.
lirc_dev: IR Remote Control driver registered, at major 61
lirc_gpio: Unknown symbol bttv_get_cardinfo
lirc_gpio: Unknown symbol bttv_get_gpio_queue
lirc_gpio: Unknown symbol bttv_get_cardinfo
lirc_gpio: Unknown symbol bttv_get_gpio_queue
lirc_gpio: Unknown symbol bttv_get_cardinfo
lirc_gpio: Unknown symbol bttv_get_gpio_queue
lirc_gpio: Unknown symbol bttv_get_cardinfo
lirc_gpio: Unknown symbol bttv_get_gpio_queue

darkknight9
30th July 2007, 02:42 PM
I have the same problem here. Anyone got LIRC working on F 7?

danwaineo
1st August 2007, 06:15 AM
I have the same problem here. Anyone got LIRC working on F 7?

It doesn't work for me either. I think the issue is with the 2.6.22 kernel rather than with F7. It worked for me before the update. Also, I think there is a patch for lirc floating around online, if you'd like to compile it yourself. I think I'll just wait for a new lirc rpm package.

SoldierSvejk
10th August 2007, 01:22 PM
Yeah, the same problem here, and that's quite likely to be 2.6.22 kernel problem:
https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/125384
I don't have time to dig into the kernel stuff - I'll just wait till some smarter guys make a patch usable by "yum -y update"....

danwaineo
10th August 2007, 03:49 PM
Yeah, the same problem here, and that's quite likely to be 2.6.22 kernel problem:
https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/125384
I don't have time to dig into the kernel stuff - I'll just wait till some smarter guys make a patch usable by "yum -y update"....

From what I read, I don't think it's a problem with the kernel. Rather the kernel API has changed and the lirc developers have to adapt their module to the new API.

darkknight9
11th September 2007, 08:01 PM
I've found numerous references on the web to using the linux input layer instead of lirc_gpio:

http://www.linuxtv.org/v4lwiki/index.php/Remote_controllers#Using_with_lircd

However, I cannot seem to get my remote detected. Has anyone else had any success with this method?

dr death
15th September 2007, 10:29 AM
I've managed to get it working without the atrpms RPMs. Here's how:

1) FInd your device

$ cat /proc/bus/input/devices
Look for your video card. Here's mine:
--------------------------------------------------------------------------
I: Bus=0001 Vendor=107d Product=6606 Version=0001
N: Name="bttv IR (card=34)"
P: Phys=pci-0000:05:07.0/ir0
S: Sysfs=/class/input/input3
U: Uniq=
H: Handlers=kbd event3
B: EV=100003
B: KEY=10afc336 2150a48 0 0 0 404 80010000 190 4801 1e0000 4400 100000 10000ffc
--------------------------------------------------------------------------

2) If you have a Leadtek Winfast (like me) then you need to recompile the module (see end of post)

3) Record your keystrokes (check /dev/input/by-path/ for your filename)

# irrecord -H dev/input -d /dev/input/by-path/pci-0000:05:07.0--event-ir /tmp/irrecord

It asks you to hold down a key. Careful here, not all keys auto-repeat. I used the "volume down" key which I know does auto-repeat.

# cp /tmp/irrecord /etc/lircd.conf

4) Update configuration

Edit /etc/sysconfig/lirc so that the options line reads:
LIRCD_OPTIONS="-H dev/input -d /dev/input/by-path/pci-0000:05:07.0--event-ir"

5) Restart lirc
# /etc/init.d/lircd restart

if you now run irw as a normal user you should see the button presses coming in. Run irexec as per other LIRC guides.

2) Recompiling the module:

2.1) Install kernel-devel RPM

2.2) Get the following files from the kernel source (I don't like having to download the source each time, so I just keep a copy of these few files locally)
drivers/media/video/btcx-risc.h
drivers/media/video/bt8xx/*h
drivers/media/video/bt8xx/*c

2.3) Patch bt8xx/video/bttv-input.c with this patch from http://marc.info/?l=linux-video&m=116099140716390&q=p3
It just adds one line and changes the value of the keycode mask. I am using 0x8f8, but try 0x0f8 as in the patch. If it doesn't work, then you may need to use 0x8f8.
--------------------------------
--- bttv-input.c.orig 2006-10-15 18:57:11.000000000 +0300
+++ bttv-input.c 2006-10-15 18:28:08.000000000 +0300
@@ -65,6 +65,8 @@
(ir->mask_keyup && (0 == (gpio & ir->mask_keyup)))) {
ir_input_keydown(ir->dev,&ir->ir,data,data);
} else {
+
+ if (btv->c.type == BTTV_BOARD_WINFAST2000) ir_input_keydown(ir->dev,&ir->ir,data,data);
ir_input_nokey(ir->dev,&ir->ir);
}

@@ -313,7 +315,7 @@

case BTTV_BOARD_WINFAST2000:
ir_codes = ir_codes_winfast;
- ir->mask_keycode = 0x1f8;
+ ir->mask_keycode = 0x0f8;
break;
case BTTV_BOARD_MAGICTVIEW061:
case BTTV_BOARD_MAGICTVIEW063:
--------------------------------

2.4) Copy and recompile (Change the paths for kernel version and download path as required)
# cd /usr/src/kernels/2.6.22.5-76.fc7-i686/drivers/media/video/
# cp ~/IR\ Remote/video/btcx-risc.h .
# cp ~/IR\ Remote/video/bt8xx/{*c,*h} bt8xx/
# cd ../../../
# make CONFIG_VIDEO_BT848=m M=drivers/media/video/bt8xx/
# mv /lib/modules/2.6.22.5-76.fc7/kernel/drivers/media/video/bt8xx/{bttv.ko,bttv.ko.orig}
# cp drivers/media/video/bt8xx/bttv.ko /lib/modules/2.6.22.5-76.fc7/kernel/drivers/media/video/bt8xx/

2.5) Reload the module
# rmmod bttv
# modprobe bttv

pgolda
22nd September 2007, 03:33 PM
dr death, I have followed those steps on fedora 6 and my remote works now. The only problem is that irrecord doesn't recognize all the buttons on the remote. I have Leadtek Winfast Deluxe. The Deluxe version has extra buttons that the standard doesn't have and those extra buttons don't work.

dr death
23rd September 2007, 11:28 AM
Well, for what it's worth, my remote has the model number: Y0400052. If I can figure out how, I'll try to attach a picture here.

Also try different values for the mask. Try 0x1f8, 0x0f8 or 0x8f8 to see if any of them work any better.

__Adam__
23rd September 2007, 09:13 PM
yeeah :), it's work perfect, i have fc7 and avermedia tv card

i uninstall lirc from atrpm, and install lirc from fedora repo

John@TunerUK
15th October 2007, 11:39 PM
I have a Leadtek Winfast DVT 1000 T, and also can't get the remote to work in Fedora 7.
I've tried uninstalling lirc from atrpms, but this also uninstalled mythtv suite (This is the main purpose of the machine so not an option).

Is there another way? Please bare in mind that I have only been using linux for approximately a month so it's all a bit fresh for me.

Thanks in advance :cool:

danwaineo
16th October 2007, 01:53 AM
Hi John,

I'm using mythtv too but with a different remote. Has it ever work for you? Do you have lirc-kmdl installed that matches your kernel version? Try:


uname -r
yum list installed lirc-kmdl*

__Adam__
16th October 2007, 08:12 AM
in yumex (GUI of yum) yum must:
list 'lirc' installed rpm, and select it to uninstall
list 'lirc' avaliable rpm from fedora repo, and select it to install
then click "update"
packages from atrmps and fedora repo have the same files
so you don't remove any application

John@TunerUK
17th October 2007, 10:04 PM
Cheers for replying guys. To be honest I've never been able to get lirc to work, even when I tried with my hauppauge nova T 500 card and remote. Every howto I tried was different in some way, and my system would always throw in some error at one point or other.

I'll give both of those a try. Fingers crossed :)

__Adam__
18th October 2007, 01:28 PM
you must do step by step in case from "dr death"
what's kind of error do you have ?

KimBP
19th October 2007, 10:27 PM
My lirc is partly working :-)

I'm, running kernel 2.6.22.4-65

I have KWORLD DVB-T 220 with an IR receiver I haven't been able to get working.
I've now build one of those simple serial ones.
If I in a shell issue the following commands and press keys on a remote (like e.g. my KWORLD remote) I get responses:

setserial /dev/ttyS0 uart none
modprobe lirc_serial
mode2

If I add the following lines to my /etc/modprobe.conf

alias char-major-61 lirc_serial
# Lirc on COM1
options lirc_serial irq=4 io=0x3e8
install lirc_serial /bin/setserial /dev/ttyS0 uart none;\
/sbin/modprobe --ignore-install lirc_serial

and reboots I still get /dev/lirc and /dev/lirc0 created just as well as
lsmod|grep serial returns lirc_serial
and lsmod|grep tty returns nothing

executing mode2 doesn't return anything.

Output from dmesg by the way in the latter case is
# dmesg|grep lirc
lirc_dev: no version for "struct_module" found: kernel tainted.
lirc_dev: IR Remote Control driver registered, at major 61
lirc_serial: auto-detected active low receiver
lirc_dev: lirc_register_plugin: sample_rate: 0

I think I've traced the problem to be caused by voltage at the RTS pin which stay on minus 11V compared to ground. Anyone who can explain why it doesn't work when being part of the boot process?

I'm running at an VIA EPIA EN12000


When I have only the alias line in /etc/modprobe.conf (i.e. when I manually start lirc and get it working) dmesg |grep lirc returns this right after boot:

dmesg |grep lirc
lirc_dev: no version for "struct_module" found: kernel tainted.
lirc_dev: IR Remote Control driver registered, at major 61
lirc_serial: port 03f8 already in use
lirc_serial: use 'setserial /dev/ttySX uart none'
lirc_serial: or compile the serial port driver as module and
lirc_serial: make sure this module is loaded first

just like it attempts to load / configure lirc_serial.
lsmod |grep lirc returns nothing.

Don't know if this tells anything about the situation where it doesn't work though

/KimBP

KimBP
26th October 2007, 07:51 PM
Hi guys

Think I should keep you updated.

First of all using my internal comport (irq=3 and io=0x2f8) I get my lirc_serial driver installed at boot.
So far so good.

I've also managed to get my lirc daemon started at boot. chkconfig is the answer :-)
So far so good.
I have problems with irrecord, but managed to had it make a raw mode conf. Trick is to start pressing an RC-key before pressing Enter on PC keyboard. Otherwise I get a comment about no gap found for 10sec.

Never the less, if I'm lucky I get a response or two when using irw.
Looking into my lircd.conf I found it rather strange that the different keys where build from pulse/space trains of very different length, so I took my receiver and attached to a 12V supply and an oscilloscope. What I here saw was a nice signal that I could easily decode. I could even measure the pulse space trains and have now build the first part of a lircd.conf with the right values. (The format by the way looks a lot like many other remotes having first a long start pulse a long space and then ones and zeros build from long and short spaces respectively)

Unfortunately it still doesn't work as supposed to. What's the problem? In all threads I've been able to find people seems to blame lircd.conf. In my situation I don't think that's the case.
When I had a closer look at the output from mode2 I can relate part of it to how I now know it is supposed to be. But I do e.g. occassionally see both pulses and spaces of length 0.
I realized xmode2 could give me my 'scope' picture and it clearly shows a picture different from what I saw on the real scope.

Hope some of you can use some of the information above.

I also hope that just one of you can tell me how to fix this lirc_serial problem. I haven't tryed yet though to have the oscilloscope attached when the receiver is plugged into my PC. This might be next step. I have tryed to force my PC (VIA EPIA EN12000 for those who might have forgotten) to stay at 1200Mhz. It doesn't change anything

Attached you see xmode2 output from pressing key '1' 10 times.

puterboy
7th November 2007, 05:59 AM
dr death, I have followed those steps on fedora 6 and my remote works now. The only problem is that irrecord doesn't recognize all the buttons on the remote. I have Leadtek Winfast Deluxe. The Deluxe version has extra buttons that the standard doesn't have and those extra buttons don't work.

I have a similar problem on my Winfast 2000XP Deluxe.
1. The "." key is not recognized at all
2. 14 pairs of keys give the same hex code and hence can't be distinguished:
SLEEP POWER
GREEN CH+
4 BOSSKEY
6 RED
7 YELLOW
8 BLUE
PIP 5
BACK TV/FM
PLAY FULLSCREEN
NEXT VOL+
TIMESHIFTING 1
SLEEP 2
RECORD 3
SNAPSHOT VOL-

I believe this is some type of "mask" issue because when I looked at an old pre-2.6.22 lircd.conf using the old gpio method, I noticed that each of those pairs have key codes that differ by exactly 0x40.
This could also explain the lack of a '.' keycode since in the old lircd.conf, it corresponded to the 0x40 version of a code (but there was no pair associated with it).

I have tried setting ir->mask_keycode to 0x0f8, 0x1f8, 0x8f8 without detectable difference.

Has anyone else been successful here?

dr death
7th November 2007, 07:24 AM
I haven't gone through the code, so I can't say for sure how the mask works, but try the following:
Use a mask of 0xffffffff (I think it's a 32-bit unsigned integer...) and insmod with debug=1. See if the keycodes appear in your /var/log/messages. If they do, then you need to find the bits that change and make sure that they appear in the mask.

puterboy
7th November 2007, 08:07 AM
Actually, I misspoke before.
It works fine with mask_keycode set to 0x8f8 (which is different from the patch).

Using irrecord, I get the following WORKING lircd.conf:

# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.8.3-CVS(dev/input) on Tue Nov 6 17:04:54 2007
#
# contributed by: Jeff Kosowsky
#
# brand: LeadTek
# model no. of remote control: Y0400046 (bundled with Winfast 2000XP Deluxe)
# devices being controlled by this remote: LeadTek Winfast 2000XP Deluxe

# brand: Leadtek
# model: Y0400052 (bundeled with Winfast PVR2000 TV-card)
#
# Note: Only CH_UP, CH_DOWN, VOL_UP and VOL_DOWN will repeat. This
# seems to be a limitation of the remote control.

begin remote

name crap2.conf
bits 16
eps 30
aeps 100

one 0 0
zero 0 0
pre_data_bits 16
pre_data 0x8001
gap 423871
toggle_bit_mask 0x80010073

begin codes
POWER 0x0074
MTS 0x0188
TV/FM 0x0182
VIDEO 0x0189
DISPLAY 0x0166
CH+ 0x0192
CH- 0x0193
VOL- 0x0072
VOL+ 0x0073
FULLSCREEN 0x0174
TELETEXT 0x0184
SLEEP 0x008E
BOSSKEY 0x0163
MUTE 0x0071
RED 0x018E
GREEN 0x018F
YELLOW 0x0190
BLUE 0x0191
1 0x0002
2 0x0003

3 0x0004
4 0x0005
5 0x0006
6 0x0007
7 0x0008
8 0x0009
9 0x000A
0 0x000B
. 0x0034
FINETUNE+ 0x004E
FINETUNE- 0x004A
PIP 0x00E2
ENTER 0x001C
RECALL 0x0195
BACK 0x019C
PLAY 0x00A4
NEXT 0x0197
TIMESHIFTING 0x0169
STOP 0x0080
REC 0x00A7
SNAPSHOT 0x00EA
end codes

end remote

dr death
7th November 2007, 08:13 AM
Yeah, that's the code I have to use too (mentioned in section 2.3 of my earlier post #7). Unfortunately the manufacturers have a habit of changing this sort of thing from time to time, so it's best to cover all bases. Perhaps the keycode mask should be a module parameter.

puterboy
7th November 2007, 09:53 AM
OK - now this is really WEIRD.

If I start the lircd service (and don't have any other lirc clients running) then some of the buttons on the remote control write to the current focus window. Indeed, using xev, it seems like the keys are writing x keycode/keysyms to the active window. However, this only works for the numerical keys and maybe half of the other keys. Indeed, lirc behaves as if irxevent has been run even though it hasn't!

The remote even writes to the X login/password screen when you are logged off.

Even weirder, the remote continues to be active this way even after stopping the lircd service. The remote stops writing though if you unload the bttv module. Then after reinstalling the bttv module, it won't write again until you have restarted the lircd service.

This doesn't make sense to me! I assume though it may have something to do with the /dev/input method.

Any idea what is going on?

dr death
7th November 2007, 10:02 AM
Indeed. Make sure that you don't press the sleep or power buttons - they can have nasty side effects. I think that they even write to the terminal if you don't have X running.

What I do is run "irexec --daemon", which processes my ~/.lircrc file. Once that is running, it grabs the buttons before they are sent through the normal event process. You can run it from /etc/rc.local, although I prefer to run it (actually I run a script that kills any running instances and starts it up again) from Gnome through the "Startup Programs" since I have auto-login enabled.

puterboy
7th November 2007, 04:53 PM
Indeed. Make sure that you don't press the sleep or power buttons - they can have nasty side effects. I think that they even write to the terminal if you don't have X running.

What I do is run "irexec --daemon", which processes my ~/.lircrc file. Once that is running, it grabs the buttons before they are sent through the normal event process. You can run it from /etc/rc.local, although I prefer to run it (actually I run a script that kills any running instances and starts it up again) from Gnome through the "Startup Programs" since I have auto-login enabled.

Couple of comments/questions:
1. Did this behavior also occur under the 'old' lirc-gpio method or is it unique to using the /dev/input method?

2. Woudn't running irexec --daemon potentially interfere with other liric clients that don't use irexec? Although, according to my testing it doesn't interfere with mythtv.
Also, this solution seems to work best if you have a single user machine that auto logs in (as you do). What do you do in a a multi-user context?

3. I agree this can be dangerous. Hasn't anybody figured out a way to 'fix' it?
It especially seems broken that lircd is required to 'start' it but that the behavior continues even after lircd is killed.
I imagine part of the problem is that at least with /dev/input, the keycodes are assigned (using ir-keymaps.c) using the same keysyms just as if the remote were any linux keyboard device and then the corresponding events if not trapped by a lirc client are treated just like any linux key events and affect whatever console (or window) has focus. X is then just a special case of a window type (note: I verified that the behavior happens even in a non-X console screen). The problem seems to be due to the fact that ir-keymaps.c assigns keysyms that overlap with standard linux keyboard keysyms so that linux doesn't know where they are coming from if they are not trapped by the lirc application.
If the above is correct, it seems to me that 2 things would need to be corrected:
- First, when lircd is running, all such events should be trapped even when no client is running. This would be analogous to running a 'dummy' irexevent when there is no other lirc client active.
- Second, when lircd is terminated, either the events should no longer be captured or they should at least still be trapped.

Any thoughts?

dr death
8th November 2007, 08:10 AM
1. Did this behavior also occur under the 'old' lirc-gpio method or is it unique to using the /dev/input method?


Nope didn't occur using the old method.



2. Woudn't running irexec --daemon potentially interfere with other liric clients that don't use irexec? Although, according to my testing it doesn't interfere with mythtv.
Also, this solution seems to work best if you have a single user machine that auto logs in (as you do). What do you do in a a multi-user context?


I don't know about interfering with other programs, but if there is nothing to pick up the keystrokes in /dev/input then they seem to go to the default input (stdin for terminal, xev for X).
For a multi user machine, I assume that there is just 1 remote for the machine. There are many options here, for example:
1) Have irexec running from /etc/rc.local with a global configuration.

2) Have each user run it on startup - you could put the settings in /etc/skel/ so that when the accounts are created, the default settings are loaded. I don't know what the gnome equivalents of .xinitrc and .xsession are, but a google search will tell you that.



3. I agree this can be dangerous. Hasn't anybody figured out a way to 'fix' it?
It especially seems broken that lircd is required to 'start' it but that the behavior continues even after lircd is killed.
I imagine part of the problem is that at least with /dev/input, the keycodes are assigned (using ir-keymaps.c) using the same keysyms just as if the remote were any linux keyboard device and then the corresponding events if not trapped by a lirc client are treated just like any linux key events and affect whatever console (or window) has focus. X is then just a special case of a window type (note: I verified that the behavior happens even in a non-X console screen). The problem seems to be due to the fact that ir-keymaps.c assigns keysyms that overlap with standard linux keyboard keysyms so that linux doesn't know where they are coming from if they are not trapped by the lirc application.


Agreed, except for the fact that there may exist IR input devices that are supposed to operate this way (e.g. IR keyboard - don't know if those exist). I also suspect that the remotes are specifically designed to do this sort of thing (i.e. when you press the button "1", the remote generates an 8-bit number which when combined with the mask gives 0x31 - the ascii code for "1").

darkknight9
24th April 2008, 09:57 PM
Hi dr death, the patch no longer works against the 2.6.24 series kernels. Do you have a workaround? Thanks in advance.

darkknight9
24th April 2008, 11:55 PM
Never mind, copying the bttv source files anew did the trick. Thanks anyway.