Maxim Levitsky <maximlevitsky@xxxxxxxxx> writes: > There are many protocols, Few of them really popular. > There are many receivers, and all have different accuracy. Receivers? Accuracy? What do you mean exactly? > Most remotes aren't designed to be used with PC, thus user has to invent > mapping between buttons and actions. Of course. You can't change that. Being designed to be used with PC is not relevant. > Its is not possible to identify remotes accurately, many remotes send > just a 8 bit integer that specifies the 'model' thus many remotes can > share it. I have never seen a remote that sends "model" number. But I admit I only used few universal (including programmable) and few simple bundled remotes. > Some don't send anything. How do they communicate with the receiver? > There are some weird remotes that send whole packet of data will all > kind of states. Of course. This is called "encoding". > Think about it, video capture device is also an input device, a scanner > is an input device too, sound card can work as input device too. But their primary function isn't passing keystrokes, is it? > Kernel job is to take the information from device and present it to > userspace using uniform format, that is kernel does 1:1 translating, but > doesn't parse the data. Why do you think so? This is less efficient, and more complicated. And would require incompatible changes to drivers already in the kernel. Keyword: "regression". > lirc is well capable to decode it, and its not hard to add > auto-detection based on existing configuration drivers, so IR devices > will work with absolutely no configuration. Really? You don't know what you're talking about. Forget this idea, there is absolutely no way to use this without prior configuration. You can get as far as suggesting default "bundled" model, if there was something bundled with the receiver of course. > Then as soon as you press a key, lirc can scan its config database, and > find a config file to use. Forget it. > Also don't forget that there are pure userspace drivers. They won't have > access to in-kernel decoder so they will still have to parse protocols, > so will have code duplication, and will still need lirc thus. This is not a problem. BTW I have nothing against lirc. It can get keystrokes from input layer. That's the way I use it in fact. -- Krzysztof Halasa -- 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
