On Wed, Dec 02, 2009 at 05:33:34PM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > >> The raw interface applies only to the devices that doesn't have a hardware > >> decoder > >> (something between 40%-60% of the currently supported devices). > > > > 50% is quite a number I think. But if driver does not allow access to > > the raw stream - it will refuse binding to lirc_dev interface. > > Ok. > > > We need to cater to the future cases as well. I don't want to redesign > > it in 2 years. But for devices that have only hardware decoders I > > suppose we can short-curcuit "interfaces" and have a library-like module > > creating input devices directly. > > We really need only one interface for those devices. However, protocol > selection > is needed, as it is associated with the scantable on those devices. > a sysfs entry would solve this issue. > > Also, we need a better schema to cleanup the keycode table. Currently, the > only way > I'm aware is to run a loop from 0 to 65535 associating a scancode to > KEY_UNKNOWN or > to KEY_RESERVED.
I guess we could entertain EVIOCSKMAPFLUSH or something... > > >> In the case of the cheap devices with just raw interfaces, running > >> in-kernel > >> decoders, while it will work if you create one interface per protocol > >> per IR receiver, this also seems overkill. Why to do that? It sounds that > >> it will > >> just create additional complexity at the kernelspace and at the userspace, > >> since > >> now userspace programs will need to open more than one device to receive > >> the > >> keycodes. > > > > _Yes_!!! You open as many event devices as there are devices you are > > interested in receiving data from. Multiplexing devices are bad, bad, > > bad. Witness /dev/input/mouse and all the attempts at working around the > > fact that if you have a special driver for one of your devices you > > receive events from the same device through 2 interfaces and all kind of > > "grab", "super-grab", "smart-grab" schemes are born. > > The only device that the driver can actually see is the IR receiver. There's > no way to > know if there is only one physical IR sending signals to it or several > different models, > especially if we consider that programmable IR's can be able even to generate > more than one > protocol at the same time, and can emulate other IR types. > > You might create some artificial schema to try to deal with different IR's > being received > at the same IR receiver, but, IMHO, this will just add a complex abstraction > layer. > > Also, this won't give any real gain, as either both IR's will generate the > same scancodes (and you can't distinguish what IR generated that code), or > the scancode is different, and you > can handle it differently. No it will. User will have _an option_ of assigning a particular remote to a particular application. Whether he or she will chose to entertain this option is up to that user. > > >>> (for each remote/substream that they can recognize). > >> I'm assuming that, by remote, you're referring to a remote receiver (and > >> not to > >> the remote itself), right? > > > > If we could separate by remote transmitter that would be the best I > > think, but I understand that it is rarely possible? > > IMHO, the better is to use a separate interface for the IR transmitters, > on the devices that support this feature. There are only a few devices > I'm aware of that are able to transmit IR codes. -ENOOPINION at the moment. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
