Installing Lirc support should be simpler

Bug #65174 reported by Fredrik
62
Affects Status Importance Assigned to Milestone
lirc (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Binary package hint: lirc

Should it be so hard to make the most user friendly and best updated linux distro eable to use a remote control without you bing a doctor in science?

More and more people want to build media center PC:s and this is a problem.

Make some descent Lirc packages that does not need compiling and stuff.

Related branches

Revision history for this message
Andrew Conkling (andrewski) wrote :

Agreed. I think the inclusion of a lirc-modules package would go a long way and would definitely be the first step.

For instance, see bug 53111, bug 47997, bug 44726, and numerous forum threads for the headache that configuring the LIRC modules causes.

Also, udev rules for hotplugging would help greatly. Bug 56539 covers that.

Those that are using the stock Ubuntu kernel should benefit from modules for their LIRC devices compiled for the same.

Changed in lirc:
status: Unconfirmed → Confirmed
Revision history for this message
Panagiotis Issaris (t4k1s) wrote :

I fully agree. I have spent several hours for the last four days trying to get lirc working but to no avail. And the hardware is fine, as my previous KnoppMyth installation had it working at first boot. I'm a nerd and I can't get it running... so I'm pretty sure a newbie (or should I say "Human being") won't ever get a remote control working on Ubuntu.

There should be precompiled modules for this, or at least a compilable source package. And frankly, I don't think a user should even have to choose which driver to use, as lspci should return sufficient information to determine which driver is needed from within a script.

Revision history for this message
Kees Cook (kees) wrote :

Adding a kernel-tracking "lirc-modules" package has been proposed to the kernel team, and perhaps in future versions of Ubuntu, lirc will be included in the kernel rebuild process. For the time being, using "m-a" should be used to rebuild the modules as needed:
  sudo m-a -v -t prepare
  sudo m-a -v -t build lirc-modules
  sudo m-a -v -t install lirc-modules

Changed in lirc:
importance: Undecided → Wishlist
Revision history for this message
Martin Emrich (emme) wrote :

I'd say a good idea would be to make lirc-modules-source depend on modules-assistant and to recommend Kees' instructions via a debconf message window.

Currently, lirc-modules-source does not build the lirc modules for 2.6.x correctly, and also places them into the wrong location, here on feisty amd64.

Revision history for this message
nyékhelyi gábor (n0gabor) wrote :

I Agree.
It was a pain to build lirc-modules-source, because the misleading documentation in README, README.Debian, and debconf.
But if the documentation were correct, it would be difficult for linux-newbies to compile stuff, so a lirc-modules package for the current kernel is needed!

Revision history for this message
Arnaud Quette (aquette) wrote :

This bug will be addressed upstream by a sub project of the Ubuntu Media Center Team.

https://wiki.ubuntu.com/RemoteControls

I have already started to discuss with Christoph Bartelmus (LIRC project leader) and Jon Smirl, who has started some work.
Kernel hackers needed. If you're interested in, contact me back.

Revision history for this message
encompass (encompass) wrote :

I can create a gui for the device setup. I program in python. I also have a generic IRC reader... one that is recommended by lirc project. If you can tell me how to implement this device without having to recompile from source, I would be more than happy to make a gui frontend to do all that. :D

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

I don't think our immediate requirement is configuration guis and the such. Our immediate requirement is a better-than-modules-assistant (i.e not having to build and install from source) method of getting lirc drivers. While I'm on the subject, why is m-a so immature? I mean compared to DKMS which does all of the rebuilding for you behind the scenes so that as a user you don't have to know how to build kernel modules? If M-A were at that level of integration then it would be acceptable to use a source distributed package.

Revision history for this message
encompass (encompass) wrote :

Just tell me when your ready. :) I would be happy to do it for Gutsy +1.

Revision history for this message
Matt Domsch (matt-domsch) wrote :

https://bugs.launchpad.net/ubuntu/+bug/121676 for including DKMS in Ubuntu.

Revision history for this message
Oliver Gerlich (ogerlich) wrote :

Brian: it seems that m-a is not so much immature as "only" badly integrated in Ubuntu... Feature-wise you can run "m-a a-i lirc" and get working LIRC modules installed (it asks a few times in the process for a "y" whether you want to install kernel-headers and bla bla, and then automatically installs kernel-headers and build-essentials).
What's lacking is some GTK GUI integration which hides the "y" pressing :-) and maybe it would be nice if m-a would then be run automatically at every kernel upgrade... It's not lacking very much, in fact it only seems to lack an end-user compatible GUI.

Revision history for this message
Mario Limonciello (superm1) wrote :

I've added a much better solution to gutsy regarding kernel modules. They are now part of the linux-ubuntu-modules package (and consequently rebuilt automatically when the new kernels are rolled out)

See:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=commit;h=6d8a833614bd64bea8b70c7e8ce4e1c04fd1621c
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=commit;h=bfb83800def0c3b6b3efaec0f9e55d50b659ae61

This is only part of the solution however. Work is still going on with regard to lircd.conf and lircrc generation.

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote : Re: [Bug 65174] Re: Installing Lirc support should be simpler

On Sun, 2007-07-22 at 19:24 +0000, Oliver Gerlich wrote:
> Brian: it seems that m-a is not so much immature as "only" badly integrated in Ubuntu...

No, I disagree. I don't think it's any different than it is in Debian.
It's just the way the tool works. It's "sub-optimal" (if you don't want
to use the word "immature").

> Feature-wise you can run "m-a a-i lirc" and get working LIRC modules installed

Indeed. But why should I have to (remember (how) to do this every time
the kernel is upgraded)?

> (it asks a few times in the process for a "y" whether you want to install kernel-headers and bla bla, and then automatically installs kernel-headers and build-essentials).

Yup. More stuff I should not have to (remember (how) to do).

> What's lacking is some GTK GUI integration which hides the "y" pressing :-)

Nope. Completely wrong solution, IMHO.

> and maybe it would be nice if m-a would then be run automatically at every kernel upgrade...

Ahh. Now you are talking about the _maturity_ of DKMS. Instead of
trying to wrangle m-a to do exactly what DKMS actually does, why not
just use DKMS. Probably DKMS could be made to simply call m-a if that's
the way you really wanted to go with it.

> It's not lacking very much, in fact it only seems to lack an end-user compatible GUI.

Again, I disagree. A GUI is the wrong solution. Automation, hidden
from the poor end-user is the right solution.

Or as Mario says in a followup, integration with linux-ubuntu-modules,
so that binary modules come out of the box.

b.

--
My other computer is your Microsoft Windows server.

Brian J. Murrell

Revision history for this message
Mario Limonciello (superm1) wrote :

lirc (0.8.2-0ubuntu3) gutsy; urgency=low

  * Add 14_lirc_i2c.dpatch to fix lirc-i2c on 2.6.22 kernel
    for PVR-150 and HVR-1300. (LP: #128650)
  * Add 15_macmini.dpatch to fix macmini support. (LP: #126955)
  * Add 16_lirc-gpio.dpatch to fix GPIO by backporting deprecated
    functions, until sysfs support is added to GPIO module.
  * debian/lirc.postinst & debian/lirc.templates:
    Add functionality to choose your remote. Automatically load this
    information into /etc/lirc/hardware.conf and choose a /etc/lirc/lircd.conf
    for your remote. (LP: #65174)

 -- Mario Limonciello <email address hidden> Thu, 26 Jul 2007 19:47:03 -0700

Changed in lirc:
status: Confirmed → Fix Released
Revision history for this message
Malcolm Parsons (malcolm-parsons) wrote :

Just installed this, and it broke my working lirc install.

I selected "Linux input layer (/dev/input/eventX)", and /etc/lirc/hardware.conf was rewritten with DRIVER="".
It was DRIVER="dev/input" before upgrading.

/usr/share/doc/lirc/lirc.hwdb contains:
Linux input layer (/dev/input/eventX);devinput;none;hw_devinput;<A HREF="http://linux.bytesex.org/v4l2/faq.html#lircd">generic config file for Linux input layer</A>;

Is ";devinput;" a typo for ";dev/input;" ?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.