Bug 743573

Summary: Please create a EPEL-6 branch - lirc
Product: [Fedora] Fedora Reporter: Matěj Cepl <mcepl>
Component: lircAssignee: Alec Leamas <leamas.alec>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: bnocera, jarod, jarodwilson, mcepl, mcepl, vaton4
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-01 13:04:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Matěj Cepl 2011-10-05 12:14:18 UTC
It is required for some rpmfusion packages.

Thank you

Comment 1 Matěj Cepl 2011-10-05 19:31:39 UTC
There is no support for it in the kernel.

Comment 2 Jarod Wilson 2011-10-05 19:36:10 UTC
(In reply to comment #1)
> There is no support for it in the kernel.

False. And irrelevant.

Comment 3 Jarod Wilson 2011-10-05 19:37:26 UTC
The RHEL6.1 kernel includes lirc device interface support for rc-core drivers.

$ modinfo lirc_dev
filename:       /lib/modules/2.6.32-131.0.15.el6.x86_64/kernel/drivers/media/rc/lirc_dev.ko
license:        GPL
author:         Artur Lipowski
description:    LIRC base driver module
srcversion:     BC1496FC40DFF1ECE206A45
depends:        
vermagic:       2.6.32-131.0.15.el6.x86_64 SMP mod_unload modversions 
parm:           debug:Enable debugging messages (bool)

And even if it didn't, a fair number of userspace drivers exist.

Comment 4 Jarod Wilson 2011-10-05 19:38:17 UTC
(Doing an el6 epel branch has been on my TODO list for a while now, just haven't got around to it)

Comment 5 vaton 2011-11-14 20:41:07 UTC
At http://wilsonet.com/?p=85 Jarod Wilson wrote:

"..... I plan to submit most of the current lirc_foo drivers into the Linux kernel staging tree, building against the in-kernel lirc_dev, but with a caveat that they’re all being put there with the intent that they be ported to the ir-core interfaces, or dropped entirely ....."

It is nice, just ..... you forgot there are also people who like to design (and add to LIRC) their own hardware!!

In my case, I have designed my own parallel interface. My solution generates interrupt on both rising and falling edges of the IR sensor signal so should work exactly as the serial one, may be bit faster. With the digital scope it works as expected, but now I am fighting for a week with this damn integrated lirc_dev driver.

Tried several distributions (the last one is Scientific Linux 6.1), but do not see any difference. If I compile the official lirc-0.9.0 source (trying the original, unmodified version first, of course), I always get something like this:

# modprobe lirc_parallel
FATAL: Error inserting lirc_parallel (/lib/modules/2.6.32-131.6.1.el6.i686/misc/lirc_parallel.ko):
 Input/output error

Even if I load the integrated lirc_dev module first:

# insmod /lib/modules/2.6.32-131.17.1.el6.i686/kernel/drivers/media/rc/lirc_dev.ko

I get:
 
# modprobe lirc_parallel
FATAL: Error inserting lirc_parallel (/lib/modules/2.6.32-131.17.1.el6.i686/misc/lirc_parallel.ko): Unknown symbol in module, or unknown parameter (see dmesg)

The lircd also fails to run (no suprice as no driver loaded):

# /usr/local/sbin/lircd --driver=parallel
Driver `parallel' not supported.
Supported drivers: default

Problem is well known - the lirc_parallel module is compiled against the lirc-dev included in the LIRC tarbal, which seems to be remarkably different from the module integrated into the kernel.

I could recompile kernel to satisfy my needs, of course, but this is boring, endless job. I guess the lirc-parallel source (and any other driver sources as well) could be tweaked to compile directly against kernel files, just need to know which libraries, which headers, etc. to use.

Would you publish some example how it can be done???

By the way, world is changing. You can forget these good old mainboards with two COM ports. There is just one serial and one parallel internal header on production mainboards. Serial port with its noise imunity is too valuable to be used for IR receiver. The parallel port, on the contrary, is almost useless as all current printers are equipped with the USB interface. So why not use parallel port for IR receiver? My hardware is really simple - just IR sensor TSOP1738, one 74HC86 and few passive components.

Comment 6 Jarod Wilson 2011-11-17 21:49:12 UTC
(In reply to comment #4)
> (Doing an el6 epel branch has been on my TODO list for a while now, just
> haven't got around to it)

Decided I don't actually have time to care about EPEL right now, so not going to happen, unless someone else does it.

Comment 7 Jarod Wilson 2011-11-17 21:56:26 UTC
(In reply to comment #5)
> At http://wilsonet.com/?p=85 Jarod Wilson wrote:
> 
> "..... I plan to submit most of the current lirc_foo drivers into the Linux
> kernel staging tree, building against the in-kernel lirc_dev, but with a caveat
> that they’re all being put there with the intent that they be ported to the
> ir-core interfaces, or dropped entirely ....."
> 
> It is nice, just ..... you forgot there are also people who like to design (and
> add to LIRC) their own hardware!!

Didn't forget. They all exist in the staging tree, and patches will be taken to fix them if they don't work, but I don't have the time or care to prop up crappy drivers for legacy hardware myself.


> Would you publish some example how it can be done???

http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers


> By the way, world is changing. You can forget these good old mainboards with
> two COM ports. There is just one serial and one parallel internal header on
> production mainboards. Serial port with its noise imunity is too valuable to be
> used for IR receiver. The parallel port, on the contrary, is almost useless as
> all current printers are equipped with the USB interface. So why not use
> parallel port for IR receiver?

Because parallel ports suck and should die in a fire. The sane way to go is USB. Then you get actual automatic device detection and automatic driver loading. Do something ftdi-based if you want cheap build-it-yourself that is at least sanely supportable:

http://www.huitsing.nl/irftdi/

Comment 8 Fedora End Of Life 2013-04-03 19:35:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 9 Fedora Admin XMLRPC Client 2013-10-12 09:06:01 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Alec Leamas 2013-11-01 13:04:03 UTC
EPEL branch exists since long, closing.