On Apr 5, 2011, at 2:48 AM, VeNoMouS wrote:
> Is xbox support code going to be put into either of these other two?
Probably not, it likely calls for a new driver. I'm afraid it was only
recently that I figure out the xbox remotes supported by lirc_atiusb
use an entirely different key acquisition routine from the ati remotes,
which means they don't fit very well into either of the ati_remote
drivers. In theory, we could just strip lirc_atiusb down to support
only the xbox remotes and then rename it lirc_xbox or something like
that, but if someone is going to go to that much trouble, I think its
actually a better use of time to copy, say, ati_remote.c to create a
new xbox_remote.c or similar. Patches welcome, as the saying goes,
otherwise, no clue on when I might be able to get around to it myself.
> On Sat, 26 Mar 2011 11:56:09 +0100, Steffen Barszus wrote:
>> On Fri, 25 Mar 2011 18:47:35 -0700
>> Jeff Dwork <
>> > wrote:
>>> The lirc_atiusb driver (lirc-0.8.7) doesn't work with recent kernels
>>> because of the kfifo. The size of a kfifo must be a power of 2, but
>>> the driver wants 5 or 6 or 3, and kfifo_alloc rounds the request down
>>> to a power of 2.
>>> I can make it work by not using the kfifo:
>>> #undef LIRC_HAVE_KFIFO
>>> in lirc_dev.h
>>> I also made it work by changing code_length and decode_length in
>>> lirc_atiusb from 5 to 4. My remote, Snapstream Firefly, type ATI1,
>>> emits 4 byte codes. But this may not work for other remotes.
>>> I've tried increasing the allocated size of the kfifo to 8, but that
>>> doesn't work. Perhaps the read and write sizes also need to be powers
>>> of 2?
>>> Since lirc-0.9.0 always uses the kfifo, I can only make it work by
>>> changing the code_length to 4.
>> I believe, Jarod is considering this driver obsolete. The best bet
>> should be the ati_remote driver, as with that you have an in kernel
>> driver, which (with small adaptions) provides easier access. If you
>> want lirc from that driver, you can use eventlircd.
>> Another possibility would be the atilibusb driver. I would say if out
>> of 3 possibilities one is going away its not to bad. From my
>> perspective ati_remote should be better maintained, then its ok.