On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> writes: > > > Event input has the advantage that the keystrokes will provide an unique > > representation that is independent of the device. > > This can hardly work as the only means, the remotes have different keys, > the user almost always has to provide customized key<>function mapping. > Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... > > Perhaps the raw RCx data could be sent over the input layer as well? > Something like the raw keyboard codes maybe? > Curreently the "scan" codes in the input layer serve just to help users to map whatever the device emits into a proper input event code so that the rest of userspace would not have to care and would work with all types of devices (USB, PS/2, etc). I would not want to get to the point where the raw codes are used as a primary data source. > We need to handle more than one RC at a time, of course. > > > So, the basic question that should be decided is: should we create a new > > userspace API for raw IR pulse/space > > I think so, doing the RCx proto handling in the kernel (but without > RCx raw code <> key mapping in this case due to multiple controllers > etc.). Though it could probably use the input layer as well(?). > I think if the data is used to do the primary protocol decoding then it should be a separate interface that is processed by someone and then fed into input subsystem (either in-kernel or through uinput). Again, I would prefer to keep EV_KEY/KEY_* as the primary event type for keys and buttons on all devices. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
