On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:
Anyway, we shouldn't postpone lirc drivers addition due to that.
There are still lots of work to do before we'll be able to split
the tables from the kernel drivers.
Indeed. The sysfs bits are future work for both lirc and evdev
drivers. There is no reason to make the lirc merge wait for it.
At this point, my plan is to try to finish cleaning up lirc_dev and
lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
and resubmit them next week.
I'm still on the fence over what to do about lirc_imon. The driver
supports essentially 3 generations of devices. First-gen is very old
imon parts that don't do onboard decoding. Second-gen is the devices
that all got (insanely stupidly) tagged with the exact same usb
device ID (0x15c2:0xffdc), some of which have an attached VFD, some
with an attached LCD, some with neither, some that are actually RF
parts, but all (I think) of which do onboard decoding. Third-gen is
the latest stuff, which is all pretty sane, unique device IDs for
unique devices, onboard decoding, etc.
So the lirc_imon I submitted supports all device types, with the
onboard decode devices defaulting to operating as pure input devices,
but an option to pass hex values out via the lirc interface (which is
how they've historically been used -- the pure input stuff I hacked
together just a few weeks ago), to prevent functional setups from
being broken for those who prefer the lirc way.
What I'm debating is whether this should be split into two drivers,
one for the older devices that don't do onboard decoding (which would
use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy',
and one that is a pure input driver, not unlike the ati_remote{,2}
drivers, with no lirc_dev dependency at all, probably called simply
'imon'.
fair amount of code duplication,