Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
> That is why I think we should go the other way around - introduce the
> core which receivers could plug into and decoder framework and once it
> is ready register lirc-dev as one of the available decoders.

The core needs to allow for RF remotes too.

-Bluetooth remotes are already in kernel somehow, I don't know how they work,
-RF4CE, the 802.15.4 stack has been recently merged, the remotes use a
protocol on top of that. These remotes will hit the consumer market
next year. Sony, Panasonic and other big names are behind this.
-Zwave, the Harmony remotes use Zwave. There is no Zwave support in
the kernel that I am aware of. Zwave is proprietary.

After these protocols are decoded you end up with scancodes. The
scancodes need to get injected into input somehow and then flow
through the mapping process. Decoding down to the scancodes probably
happens over in the networking code.

After an in-kernel IR decoder runs it needs to hand off the scancodes
into the input subsystem. This same API can be used by the networking
code to hand off RF scancodes.

-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux