Here's my current plan - Venky, let me know what you think.
Move most of the work of the USB driver into a driver below the lirc_imon driver.
So we have a usbimon driver that is neither lcdproc-specific on the VFD side, nor lirc-specific on the IR side.
The usbimon driver allows client drivers to register to receive IR data, giving a callback, a bitmask, and a match-value. It allows the client driver to say "I accept all remotes whose data looks like this".
lirc_imon would be a client to this that says "I accept *ALL* remotes".
imon_pad would be a client to this that says "I accept remotes where when this bitmask is applied, this match-value results"
usbimon counts up the size of the mask, and assigns a priority to the client. Very specific clients have higher priority, and very broad clients have lower priority.
usbimon receives some IR data, and goes down the chain of registered clients, highest priority first.
- Code: Select all
current_handler = imon_pad
if((data & bit_mask) == match_value)
{
current_handler(buffer);
}
current_handler = lirc_imon
if((data & bit_mask) == match_value)
{
current_handler(buffer);
}
Pros:
* It gets VFD code out of the lirc_imon driver
* The lirc_imon driver gets very simple
* It's very easy to gain access to the remote by other means than lirc
Cons:
* I think the lirc_imon driver gets TOO simple, very thin wrapper
* Too many drivers getting loaded into the kernel - yeah, they're small, but do you really need (for example) 5 different drivers to support a single USB device?
One thing that I think would be interesting in the long run is a replacement for lirc that uses DBUS. But that's WAAY too big a project for me to be trying to pick up anytime soon[/quote]