Re: upcoming imon driver split

[Jarod W. <ja...@wi...>]

On Dec 28, 2009, at 6:02 AM, Christoph Bartelmus wrote:

> Hi!
> 
> you have merged all the imon config files into the source?

Yeah, more or less.

> The kernel interface to set new keymaps is extended to 64 bit already?

No. But its definitely on the TODO list. And having this driver in would add impetus to make that happen.

> Where is the irrecord counterpart to create new keymaps?

It'll more or less be getkeycode/setkeycode, once properly extended, I believe.

> Isn't there still enough common code for the display which makes it worth  
> keeping this a single driver?

At this point, the display code is about the only thing still more or less the same. It has been suggested that perhaps we have 3 modules here, one that provides the display functionality (and any other shared functionality), then require that from the two main drivers. Experimenting with that is also on the TODO list, albeit not very high. I'm not sure putting a whole lot of effort into a driver that only supports rather old and incredibly rare imon parts is worth it. At least, in all my travels, I've only come across one person with one of the devices that doesn't do onboard decode, 99% of people have had the ffdc and newer stuff.


> Jarod Wilson "ja...@wi..." wrote:
> 
>> As part of the effort to get the lirc kernel drivers into the upstream
>> kernel, I sent lirc_imon up for review. It was determined that it really
>> needs to be two different drivers, one for the older devices that don't do
>> onboard decoding, which would keep using the lirc_dev interface, and a
>> second driver for the onboard decoding devices that operates as a pure
>> kernel input layer device. Well, tonight, I sent the pure input layer device
>> driver upstream for review. Hoping it can get merged in 2.6.33, and once
>> merged, I'll be neutering lirc_imon in cvs to only support the older devices
>> on kernels 2.6.33 and newer.
>> 
>> Note that you can still use the new imon driver with lirc, just use the
>> devinput lircd userspace driver, and it works peachy.
>> 
>> As for the rest of the lirc bits' progress towards upstream... I spent some
>> time this afternoon hacking things up to support the new kfifo api that was
>> merged into 2.6.33-rc2, and it compiles, but I have yet to test it. Will
>> hopefully do some more work on it tomorrow, and then send lirc_dev and
>> lirc_mceusb up for review again, and hopefully, we've got things hashed out
>> to the point where it can go into at least the staging tree.

-- 
Jarod Wilson
ja...@wi...