On Thu, Nov 26, 2009 at 10:58:59PM -0500, Jon Smirl wrote: > > > >> Code is only lightly tested. Encoders and decoders have not been > >> written for all protocols. Repeat is not handled for any protocol. I'm > >> looking for help. There are 15 more existing LIRC drivers. > > > > And there's the hangup for me. The lirc drivers and interface have been > > pretty heavily battle-tested over years and years in the field. And there > > are those 15 more drivers that already work with the lirc interface. I'm > > woefully short on time to work on any porting myself, and about to get even > > shorter with some new responsibilities at work requiring even more of my > > attention. > > > > If we go with a hybrid approach, all those existing drivers can be brought > > in supporting just the lirc interface initially, and have in-kernel decode > > support added as folks have time to work on them, if it actually makes sense > > for those devices. > > > > Just trying to find a happy middle ground that minimizes regressions for > > users *and* gives us maximum flexibility. > > You are going to have to choose. Recreate the problems of type > specific devices like /dev/mouse and /dev/kbd that evdev was created > to fix, or skip those type specific devices and go straight to evdev. > We've known for years the /dev/mouse was badly broken. How many more > years is it going to be before it can be removed? /dev/lirc has the > same type of problems that /dev/mouse has. The only reason that > /dev/lirc works now is because there is a single app that uses it. > Pardon my ignorance here but it does not seem that /dev/lirc actually multiplexes data stream from different receivers but rather creates a device per receiver... Multiplexing is the main issue with /dev/mouse for me. What are the other issues with LIRC interface _for lircd-type applications_ do we see? I see for example that it is not 32/64 bit clean so that is somethign that we may consider re-evaluating before just acceptig it into kernel. Is there anything else? > Also, implementing a new evdev based system in the kernel in no way > breaks existing lirc installations. Just don't load the new > implementation and everything works exactly the same way as before. > > I'd go the evdev only route for in-kernel and leave existing lirc out > of tree. Existing lirc will continue to work. This is probably the > most stable strategy, even more so than a hybrid approach. The > in-kernel implementation will then be free to evolve without the > constraint of legacy APIs. As people become happy with it they can > switch over. > If by evdev-based system you mean adding EV_IR event to the input core I think it would be a mistake. Such data (EV_IR/IR_XXX) will have to be read from an event device, processed (probably in userspace) and re-injected back through uinput as (EV_KEY/KEY_XXX) for consumption again. Such looping interface would be a mistake IMHO. Still, the end result of the transformation should be EV_KEY/KEY_XXX delivered on one of the event devices (preferrably one per remote, not one per receiver), I believe everyone agrees on that. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
