Bug 462212

Created attachment 316690 [details]
Log from x86_64

Not a clue what's up here. Can you try on the i686 box with the addition of 'debug=1' to the module options for both lirc_dev and lirc_atiusb and post the resulting spew here? I don't actually have any hardware that uses this driver to test with. :(

I broke down and bought a remote wonder II kit on ebay. Won't be here for a week or so though.

Created attachment 319659 [details]
debug output

This is

fgrep lir /var/log/message >lir.log
echo dmesg >>lir.log
dmesg | fgrep lir >>lir.log

after having set

options lirc_atiusb debug=1
options lirc_dev debug=1

in /etc/modprobe.conf

My rwII kit showed up much quicker than expected. No problem reproducing the problem, but its an easy fix: just blacklist ati_remote and/or ati_remote2. Not sure why it didn't trigger on x86_64, probably module load order, but on my i686 box, the ati_remote2 driver got loaded before lirc_atiusb, which prevented lirc_atiusb from fully initializing.

Herein lies the problem of having multiple drivers for the same device, and the reason we're dropping lirc_atiusb for kernel inclusion in the lirc patchset sent upstream... :)

Thanks! It works.

Changing bug title to reflect the actual problem. I believe we'll ultimately wind up dropping lirc_atiusb in the future, as ati_remote and ati_remote2 are already upstream.

Further reason we can simply nuke lirc_atiusb: those who don't want to use ati_remote and wish to continue using lirc can use the atilibusb mode of lirc, which talks directly to the receiver over libusb, achieving essentially the same functionality.

Nuked lirc_atiusb in rawhide as of kernel-2.6.27.3-35.rc1.fc10.

Unfortunately, atilibusb only supports a small subset of the ATI remotes (only USB vendor id: 0bc7) and thus isn't a valid substitute for lirc_atiusb. My remote is shown by lsusb as:

Bus 002 Device 004: ID 0471:0602 Philips ATI Remote Wonder II Input Device

Vendor ID 0471 is supported by lirc_atiusb and was working just fine with the standard Fedora kernels until it was removed. lirc's atilibusb driver doesn't find the remote, which makes perfect sense when looking at the source for atilibusb given that it only supports vendor id 0bc7 (an older generation of the remote).

Can you please re-enable the compilation of lirc_atiusb as a result.

I personally simply put ati_remote2 in my blacklist and everything works fine, letting lirc_atiusb take control.

Yeah, support for the RWII should probably be added to atilibusb, but you might also be able to use the devinput lirc userspace driver with the RWII.

Re-enabling lirc_atiusb is not the right fix though. Two different device drivers for the same hardware only leads to more problems than it solves, and ati_remote2 is already in the upstream kernel.

FWIW, I actually have an RWII of my own, and getting it working with lirc again, one way or another, is on my TODO list, I just haven't got there yet...

I am currently using ati_remote2 via devinput, and that works reasonably well, except that you loose the "virtual mouse" joystick thing in the middle. No events reported for that gizmo, and once lircd's devinput driver accesses the "/dev/input/event[0-9]+" device, Xorg no longer sees that input as either a mouse or keyboard (a good thing it doesn't see the keyboard, but it would great if it could still see the "virtual mouse").

The only way to have a fully functional RWII is through the lirc_atiusb module. Yes, it would be great if atilibusb supported RWII, but right now, it doesn't. So why limit the usability of a device that's been supported for years in Fedora? I understand your reservations with regards to having two different drivers support the same device, but they support it in vary different ways, and one doesn't fully support it. So why not re-enable lirc_atiusb and blacklist it by default. This way they'd be no conflict, no confusion, yet the functionality would still be there.

Nb: with current lirc in Fedora 12, the mouse events are passed through to the input subsystem if you're using the remote with the userspace devinput driver.

Please revert this change. lirc_atiusb provides more functionality than ati_remote for my hardware, at least.

Adding a blacklist is easy. I really *DO* need lirc_atiusb in Fedora.

I had an old F-8 box that I just upgraded, where I am using this device. Now I can't use it anymore. 

Should I file a new bug?

(In reply to comment #14)
> Please revert this change. lirc_atiusb provides more functionality than
> ati_remote for my hardware, at least.

Such as?

> Adding a blacklist is easy. I really *DO* need lirc_atiusb in Fedora.
> 
> I had an old F-8 box that I just upgraded, where I am using this device. Now I
> can't use it anymore. 
> 
> Should I file a new bug?    

Before I say "no, because I have absolutely no intention of bringing back what I view as a completely unnecessary driver, given that there's already and upstream driver for this device, and that my own ATI hardware is just as functional as it ever was with lirc_atiusb using the lirc devinput userspace driver instead", I'd like to hear what functionality you believe is missing.

Sure, first of all I use ATI Remote Wonder.

- ati_remote submits keyboard events when I push a button. For instance there is an "A" key on the remote control. When I push this key when the terminal is open, I get an "A" on the terminal if I am using QWERTY. If I am using a software that assigned the "A" key to do some action, then the "A" button on the remote control is doomed to use that action only. I can't make the "A" key on the keyboard and the "A" key on the remote behave differently. When using DVORAK (which I do most of the time) the situation is even worse. Pushing "E" emits a "." etc.

- repeated pushes: When I push a button once, ati_remote sometimes thinks that I pushed it twice. This gets very annoying at times, especially when I am trying to reach a menu item. Many times I have to push up and down buttons repeatedly until it stops jumping two entries at once.

- There is a large circular button in the middle of the remote control that has 8 arrow images. ati_remote always thinks that this is a mouse. But I just want to use those buttons as "up, down, left, right" buttons, not as a mouse.

- ati_remote does not recognize some keys on the remote control (the driver does not send any events when I push the button). Initially I thought that my hardware was broken

... until I discovered lirc_atiusb. lirc_atiusb has none of the problems above.  It doesn't need to work as a keyboard extension only and it is more configurable, since it uses lirc framework.

I recompiled the kernel with the dropped patch and once again, my remote control works flawlessly.

I really do need lirc_atiusb. Please don't force me to maintain another kmod package at rpmfusion (I maintain 3). I really don't like external kernel modules or maintaining them.

Thank you for your time.

You can still use the remote via lirc and have all that same functionality without lirc_atiusb. Pick either the atilibusb lirc userspace driver with ati_remote blacklisted (iirc) or as I've already said, use the devinput lirc userspace driver pointed at the input event device created by ati_remote. lircd takes exclusive control of the device via ioctl (in the devinput case), and then you just map the keys same as before, albeit potentially with slightly different names for keys than they had before. Use the lircd.conf.devinput file from lirc-remotes (or from lirc.org/remotes/devinput/), then map from those names. I still don't see anything there that can't be done without lirc_atiusb, you can still use it with lirc, just via a different method.

okay.

how about the other 3 regressions that I reported above that have nothing to do with the lirc framework but with the ati_remote malfunctionality?

If you're using the device via lirc, you can filter/suppress repeats to your heart's content. The devinput method won't let you use the mouse pad as directional arrows (I think), but the atilibusb method will, and it should, so far as I know, support all the keys on the remote (see http://lirc.sourceforge.net/remotes/atiusb/lircd.conf.atilibusb ).

Another problem with the removal of the lirc_atiusb module is the ability to differentiate between the different "modes".  The remote has buttons aux1 through aux4 as well as a pc mode.  With the lirc_atiusb module you could use the "emit_modekeys=1" module option to enable these.  For example, if you pressed the "play" button, you would see a different mode in lirc if you were in aux1 mode vs. pc mode.

This essentially gives you 5 remotes instead of just one.

I don't see a way to do this using the devinput driver.  Maybe this information is usable with the atilibusb driver, but I don't think that atilibusb supports the Remote Wonder II.

Jarod, I appreciate all your contributions to Fedora and the Linux kernel, but with removing lirc_atiusb you make my life harder everytime I do a major update.

ati_remote just doesn't work properly. The biggest flaw among relatively smaller but important flaws is, it just doesn't recognize some of the most crucial keys.

Pretty, pretty please?

The proper route to take here is to fix the ati_remote and/or ati_remote2 drivers in the kernel.

We're trying to get to the point where we have *no* lirc_foo drivers (i.e., all have been ported to the new rc-core interfaces). Plus, out of tree drivers that aren't heading upstream don't belong in the Fedora kernel -- we even have policies written that prohibit such things.

https://fedoraproject.org/wiki/KernelDriverPolicy

I don't have time to work on anything ati-remote-specific at the moment, so really, your best bets are either to dig into the driver code yourself and provide patches, and/or to file bugs upstream at bugzilla.kernel.org (feel free to cc: me on them). I do hope to get around to porting ati_remote2 (and probably 1) over to rc-core at some point in the relatively near future, and at that time, may be able to address some of the deficiencies.

Thank you for the guidance. I'll get down in into the code whenever I find time, and then let you know.

(In reply to comment #10)
> Unfortunately, atilibusb only supports a small subset of the ATI remotes (only
> USB vendor id: 0bc7) and thus isn't a valid substitute for lirc_atiusb. My
> remote is shown by lsusb as:
> 
> Bus 002 Device 004: ID 0471:0602 Philips ATI Remote Wonder II Input Device
> 
> Vendor ID 0471 is supported by lirc_atiusb and was working just fine with the
> standard Fedora kernels until it was removed. lirc's atilibusb driver doesn't
> find the remote, which makes perfect sense when looking at the source for
> atilibusb given that it only supports vendor id 0bc7 (an older generation of
> the remote).
> 
> Can you please re-enable the compilation of lirc_atiusb as a result.
> 
> I personally simply put ati_remote2 in my blacklist and everything works fine,
> letting lirc_atiusb take control.

How did you get this to work? My remote is listing as,
Bus 001 Device 002: ID 0471:0602 Philips (or NXP) ATI Remote Wonder II Input Device

I installed lirc and blacklisted ati_remote2.

And the /etc/sysconfig/lirc has this,
LIRC_DRIVER="devinput" # Tried the atilib one with know luck either.

And dmesg shows,
[ 1701.340053] usb 1-1: new full speed USB device using uhci_hcd and address 3
[ 1701.482049] usb 1-1: New USB device found, idVendor=0471, idProduct=0602
[ 1701.482060] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

When I run this, irw, I get nothing.

BTW, with ati_remote2 not blacklisted the mouse functionality works.

And using Fedora 14 now.

If you're using devinput, you don't want to blacklist ati_remote2. Its ati_remote2 that creates the input device you need the lircd devinput driver to connect to. :)