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

Reply via email to