lirc_atiusb non functional with snapstream firefly

Bug #787742 reported by Dan Christian
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
lirc (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: lirc-modules-source

In 10.10, I could not get the userspace driver (atilibusb) working, but lirc_atiusb from lirc-modules-source worked fine with a Snapstream Firefly (also called "ATI/NVidia/X10 RF Remote"). atilibusb no longer works in 11.04.

Editing atilibusb out of /etc/modprobe.d/lirc-blacklist allows the module to be loaded, but it still won't pass any buttons to irw or mythtv.

I know that atilibusb is deprecated and that the userspace driver is preferred, but it's best to also document the problem in lirc-modules-source for future reference. Also see bug 787735

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: lirc-modules-source 0.8.7-0ubuntu4.1
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue May 24 12:51:43 2011
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: lirc
UpgradeStatus: Upgraded to natty on 2011-05-22 (1 days ago)

Revision history for this message
Dan Christian (danchristian65) wrote :
Revision history for this message
Jarod Wilson (jarod-wilsonet) wrote :

"Editing atilibusb out of /etc/modprobe.d/lirc-blacklist allows the module to be loaded" is, um, well, nonsensical. Config files in /etc/modprobe.d/ are for configuring kernel module loading params. atilibusb isn't a kernel module. Its a userspace lircd driver plugin.

Revision history for this message
Dan Christian (danchristian65) wrote :

I attempted to file this against lirc-modules-source, not lirc; but something got out of whack. And I meant to say, that "lirc_atiusb no longer works in 11.04".

Since I could not get atilibusb working, I tried the old kernel based driver . This is normally blacklisted by it's presence in /etc/modprobe.d/lirc-blacklist, so you have to edit out the "blacklist" line before modprobe will load it. The lirc_atiusb driver worked in 10.10 (while atilibusb did not).

The stock lirc-blacklist is this:
$ cat /etc/modprobe.d/lirc-blacklist
blacklist lirc_atiusb
blacklist ati_remote

Revision history for this message
Mike Brinson (mbrinson) wrote :

I've got the same issue. I was having issues with my Mythdora setup and so I decided to wipe it and do a fresh install with MythBuntu. Unfortunately now I find that I can't get my Snapstream Firefly remote working with it.
WAF is going to be way low when she finds out. :|

Revision history for this message
Dan Christian (danchristian65) wrote : Re: [Bug 787742] Re: lirc_atiusb non functional with snapstream firefly

Jarod said on bug 787735 that the lirc-modules-source package is deprecated.

May I suggest the package maintainer should doing one of the following:
Remove any drivers that don't work (the whole package?).
Document the fact that this package isn't expected to work.
Make it work right for.

Right now, it's just a trap for anyone that installs it.
-Dan

Revision history for this message
Calin Morar (morarcalin) wrote :
Download full text (3.9 KiB)

I have a ATI Remote Wonder 2 ... and upgrading to Natty is literally a two nights spent getting and tryin all kinds of configuration options with no success whatsoever.

If I use ati_remote2 it is OK, Lirc and irw work fine, except that the remote is seen as a input device. All great, until you want to use that with XBMC and/or disable the remote in X11 so the remote does not mess with the actual mouse+keyboard. With ati_remote2 driver if you want to filter the remote event irw also stops receiving signals - so no choice than to have the remote active in x11 as a input device. This for a triple display setup as I have (2 monitors + 1 tv running on 2 x Nvidia cards) is unacceptable - you don't want someone putting the PC to sleep because they pushed the sleep button on the remote while watching XBM/TV. Now If someone actually has an idea how to get ati_remote2 driver to not be treated as an input device in X11 and to generate standard scan codes in lirc/irw I have no issue. But so far this is a no no .. I could not figure how to get this working properly at all, nothing that was working before is applicable.

So.. I decided to go to lirc_atiusb + lirc_dev , use the linux devinput as I am doing on Ubuntu 9 LTS. Got the lirc-modules-source , built the modules, removed the blacklisted lirc_atiusb etc. But for no avail, lirc_atiusb does not send any events to lirc ?!!!

So here is the driver log when run in debug mode - aka modprobe lirc_atiusb debug
Jun 27 22:39:00 obelix kernel: [ 3866.052474] lirc_atiusb: USB remote driver for LIRC $Revision: 1.88 $
Jun 27 22:39:00 obelix kernel: [ 3866.052476] lirc_atiusb: Paul Miller <email address hidden>
Jun 27 22:39:00 obelix kernel: [ 3866.052478] lirc_atiusb: debug mode enabled: $Id: lirc_atiusb.c,v 1.88 2010/07/25 16:43:33 jarodwilson Exp $
Jun 27 22:39:00 obelix kernel: [ 3866.052504] lirc_atiusb[2]: usb_remote_probe: dev:ffff880323bbe000, intf:ffff880323759000, id:ffffffffa00b9270)
Jun 27 22:39:00 obelix kernel: [ 3866.052507] lirc_atiusb[2]: scanning remote_list...
Jun 27 22:39:00 obelix kernel: [ 3866.052509] lirc_atiusb[2]: remote type = 1
Jun 27 22:39:00 obelix kernel: [ 3866.052511] lirc_atiusb[2]: adding remote to list
Jun 27 22:39:00 obelix kernel: [ 3866.052514] lirc_atiusb[2]: processing endpoint 0
Jun 27 22:39:00 obelix kernel: [ 3866.052516] lirc_atiusb[2]: acceptable inbound endpoint (0x81) found (maxp=8 len=3)
Jun 27 22:39:00 obelix kernel: [ 3866.052520] lirc_atiusb[2]: adding ep=0x81 to list
Jun 27 22:39:00 obelix kernel: [ 3866.052522] lirc_dev: lirc_register_driver: sample_rate: 0
Jun 27 22:39:00 obelix kernel: [ 3866.052589] lirc_atiusb[2]: on usb8:2
Jun 27 22:39:00 obelix kernel: [ 3866.052597] lirc_atiusb[2]: usb_remote_probe: dev:ffff880323bbe000, intf:ffff880323758c00, id:ffffffffa00b9270)
Jun 27 22:39:00 obelix kernel: [ 3866.052600] lirc_atiusb[2]: scanning remote_list...
Jun 27 22:39:00 obelix kernel: [ 3866.052601] lirc_atiusb[2]: prior instance found.
Jun 27 22:39:00 obelix kernel: [ 3866.052603] lirc_atiusb[2]: processing endpoint 0
Jun 27 22:39:00 obelix kernel: [ 3866.052606] lirc_atiusb[2]: acceptable inbound endpoint (0x82) found (maxp=8 len=3)
Jun 27 22...

Read more...

Revision history for this message
Jarod Wilson (jarod-wilsonet) wrote :

Something is wonky in Ubuntu. lircd tries to get exclusive access to the input device, which prevents any of its events from being delivered to X. It works perfectly fine in other distros -- I have an ATI RemoteWonder II myself, works perfectly fine in Fedora. Not sure what's going on. One guess would be that maybe Ubuntu has lircd feeding keys back into the input layer via uinput. If you do a ps ax |grep lirc, can you see the full lircd command line? If there's a -u or --uinput in there, that's probably the cause.

Revision history for this message
John Doe (b2109455) wrote :

i have two remotes (snapstream firefly and X10). Both of them used to work with lirc_atiusb driver until lucid. I made the mistake of upgrading to natty (through maverick).
Now I can't get any of them to work..
I can see them in lsusb.
Also whenever I start/stop lirc I get following a error (lircd still starts but irw doesn't capture anything)...

root@marut:~# service lirc start
 * Loading LIRC modules
   ...done.
find: `/sys/class/rc/*/': No such file or directory
 * Starting remote control daemon(s) : LIRC
   ...done.

a update/patch will be very helpful..

Changed in lirc (Ubuntu):
status: New → Confirmed
Revision history for this message
John Doe (b2109455) wrote :

I don't think it is natty issue. I uninstalled and reinstalled lirc and it started working.
i still get message though..

find: `/sys/class/rc/*/': No such file or directory

Revision history for this message
Alec Leamas (leamas-alec) wrote :

The new 0.9.4c update has a working atilibusb userspace driver. Given that, (and comment #9) this bug needs to be tested on this version in order to advance. After all. this discussion in 5 years old.

Setting status to incomplete, since we need more info to assert the state against current code.

Changed in lirc (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for lirc (Ubuntu) because there has been no activity for 60 days.]

Changed in lirc (Ubuntu):
status: Incomplete → Expired
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.