Recently I have been working on trying to get the patch ready to submit for inclusion in the vanilla Linux kernel. Before I can do this, I need to get confirmation from a number of people that my patch is actually working for others. Please head over to the forum to join the discussion and contribute. Also, the forum is going to serve as the main support location for the patch so that everyone can benefit from solutions. Thanks for helping out!
Just recently why setting up a new front-end to my mythtv
setup I decided I wanted to find a new more user-friendly remote control. My current
remote for my main mythtv box is an ATI Remote Wonder.
The Remote Wonder II looked a
little more sleek than v1, but also seemed to have sort of a funny layout. With a
little research I found that ATI released a Remote Wonder Plus
with its deluxe All-In-Wonder cards the end of last year.
It also seems they have started selling the remote by itself, however ATI seems to be
the only retailed selling the remote, and they are currently out of stock (09/12/06).
With a little searching I found a few people on Ebay selling the remote
so I grabbed one from there.
I knew going into this project that the Remote Wonder Plus uses the same receiver as
the Remote Wonder, however reports online said that the linux driver for the original
(ati_remote) did not work with the plus. I did find one person (Cymen Vig) who had published a patch
for the lirc ati remote module to get the plus working, so I figured with a little
hacking I could get everything set up. It turns out Cymen's site was defaced, but the Google cache came to the rescue.
Last night I spent a few hours and got the ati_remote kernel module so that it works
with my Remote Wonder (v1) and my new Remote Wonder Plus. Below I will provide some of
the technical details I found and also patches for some recent kernel versions.
Here are patches that will work with the ati_remote.c file provided in drivers/usb/input/
for kernels 2.6.15, 2.6.16, 2.6.17. It you take code and port it back to older versions,
send me the diff file and I will post it here.
Update - 11/1/06
I took the time this morning to create a patch for the 2.6.18 kernel. It seems that a the key-press
repeat prevention code has been changed a little and the acceleration code for the mouse pad has
also been changed. I haven't been able to test the patch since I am still running 2.6.17, but if
you try it out and something doesn't work, let me know!. I have always had trouble with key-presses
being repeated, so I hope the new code from the the kernel source will take care of that.
Update - 11/5/06
I tried changing the repeat filtering to 60 instead of HZ / 15 (my previous modified value) since
that is what the 2.6.18 kernel uses. It seems to do a better job of filtering out repeats, so
I have changed all of the patches to do the same.
Update - 3/20/07
I justed added patches for kernels 2.6.19 and 2.6.20. I also wanted to make people aware that
since kernel 2.6.18 you can set the repeat filtering via the kernel module parameter
repeat_filter.
To apply these patches, copy the patch file to your_linux_src_dir/drivers/usb/input, cd to that directory and then run the command:
patch -p1 < ati_remote.c.path.2.6.xx.txt
Here are some technical details about the remote and the data it sends to the driver in
case anyone else wants to play around with stuff. Hopefully this info will save someone
a little bit of time.
The first issue to overcome with using the Remote Wonder Plus is that the initialization
code (as far as I understand it, which I don't really) is different. Honestly, I just pulled
this code from the LIRC patch page I found. I really don't take any credit for it. In the diff
files you can see that instead of two init arrays there are three, and they are different.
Next, a standard keypress/mouse movement on the remote wonder sends 4 bytes to the driver. With
the original Remote Wonder, the first byte was always 0x14. The Remote Wonder Plus instead
send the first byte as 0x15. The kernel ati_remote.c throws an error if the first byte is
not 0x14, so I simply changed it to allow 0x14 and 0x15.
Here was the main issue. At this point the Remote Wonder Plus was sending keypresses every
other time I pressed a key. The original LIRC page mentioned something about alternating
codes, but there were no details. This must have been it.
What I determined is that every other press to a key the remote sends slightly modified bytes.
Perhaps this is an effort to be able to create code that handles repeated keypresses efficiently?
Anyway, it seems that any non-mouse related button would send the original bytes two middle bytes
(such as 0xd2, 0x02) the first time and 0xd2 | 0x80, 0x02 ^ 0x80 the second time. It was nice
that there was an established pattern. For mouse related buttons it seemed there were two
possible mutations. Assuming original code of 0x31, 0x7c the alternating codes would either be
0x31 | 0x80, 0x7c | 0x80 or 0x31 | 0x80, 0x7c. So, I took these variations and coded them into
the lookup function for the key codes.
The very last, and trivial issue was that the italic i key did not seem to map to any
key code. I simply added it to trigger KEY_I.
Update - 9/17/06
With some more testing I have found that the mouse buttons seem to have changed in the plus.
Instead of the remote sending codes when the button are pressed and released, it now only
sends codes when the buttons are pressed. With a little bit of adaptation of the normal button
code I was able to get the mouse buttons to work perfectly. Also note that the newest version of
this patch has changed the repeat key-press filtering time. I found that when I pressed a button
it would be repeated 5 times, now it only does it once.
Update - 11/1/06
The 2.6.18 kernel seems to have changed the key-press filtering code a little. Hopefully this will
take care of the issue. Please note I have removed my tweak to the key-press filtering because
of this.
Update - 11/5/06
I tried changing the repeat filtering to 60 instead of HZ / 15 (my previous modified value) since
that is what the 2.6.18 kernel uses. It seems to do a better job of filtering out repeats, so
I have changed all of the patches to do the same.
Cymen Vig's original LIRC patch page is located over at http://raw-io.com/rwp/. Unfortunately it seems to have been defaced by some hackers. I decided I would mirror the information here so that people can learn about modifying LIRC to work with the Plus. View the LIRC patch page
So why did I choose to modify the kernel module instead of using LIRC with mythtv? Well, I found this wonderful program Gizmo Daemon that allows scripting of input device actions. I could have used LIRC for the remote, however I found the LIRC configuration to always be a bit of a pain, plus I also have two usb gamepads that I remap the buttons on and a usb joystick which I do the same with. If you are looking for a good all-around solution for modifying the behavior of your usb input devices I highly recommend it!