On Wed, Dec 2, 2009 at 2:50 PM, Jon Smirl <jonsm...@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
> <mche...@redhat.com> 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 
>>>> 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.
> IR devices transmit vendor/device/command triplets. They are easy to
> tell apart and create an evdev device corresponding to each
> vendor/device pair or something else along those lines.

I forgot about fixed function receivers - ones that only receive codes
from a specific vendor/device pair and decode them in hardware. Those
devices would just create a fixed entry in the configfs which would
then allow a keycode mapping to be loaded. Or a parallel scheme for
setkeys IOCTL. These device can only receive from a single remote.

> If I tell a programmable remote to send out the same commands as my
> Sony remote that's the same thing as owning two identical Sony
> remotes. I'd expect them to be indistinguishable. If you want to be
> able to tell your remotes apart, don't program them to emulate each
> other.
> I've published code that can split these devices apart, it's not
> impossible to do.
> 802.11 receivers have the same problem, there is one receiver and many
> transmitters. The networking code doesn't have problems with sorting
> this out and separating the streams.
>> 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.
> Reusing the keycode is fine if they on different evdev devices. A key
> feature is creating one evdev device for each remote.
>>>>> (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.
>> Cheers,
>> Mauro.
> --
> Jon Smirl
> jonsm...@gmail.com

Jon Smirl
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