Re: [RFC v2] Another approach to IR

On Wed, Dec 2, 2009 at 2:33 PM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> 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.

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.

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
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC v2] Another approach to IR
    ... But if driver does not allow access to ... We really need only one interface for those devices. ... The only device that the driver can actually see is the IR receiver. ... I'm assuming that, by remote, you're referring to a remote receiver (and not to ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... We really need only one interface for those devices. ... The only device that the driver can actually see is the IR receiver. ... IR devices transmit vendor/device/command triplets. ... These device can only receive from a single remote. ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... But if driver does not allow access to ... We really need only one interface for those devices. ... The only device that the driver can actually see is the IR receiver. ... I'm assuming that, by remote, you're referring to a remote receiver (and not to ...
    (Linux-Kernel)
  • Re: How does this remote extender work?
    ... your TV remote from a different room. ... Most devices in this class works by having an infrared receiver sitting in ... the room where you use the remote, transmit the signal wirelessly to an ...
    (sci.electronics.design)
  • Re: IR raw input is not sutable for input system
    ... digital code the remote sent. ... I have never heard of such receiver, ... that data to lircd via the input layer. ... would avoid another kernel interface. ...
    (Linux-Kernel)