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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9e4733910912151338n62b30af5i35f8d0963e6591c@mail.gmail.com>
Date:	Tue, 15 Dec 2009 16:38:14 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	hermann pitton <hermann-pitton@...or.de>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
	kraxel@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR 
	system?

On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl <jonsmirl@...il.com> wrote:
> On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek <pavel@....cz> wrote:
>> Untrue. Like ethernets and wifis, bluetooth devices have unique
>> addresses. Communication is bidirectional.

I read a little about how Bluetooth remotes work. Correct me if I get
things wrong....

They create pairings between the remote and the device. Each of these
pairings is assigned a device type. Multiple devices in the same room
are handled by the remote remembering the pairings and sending
directed packets instead of broadcast. That lets you have two TVs in
the same room.

Bluetooth devices need to advertise what profiles they support. So on
the Linux box you'd run a command to load the Bluetooth profile for
TV. This command would create an evdev subdevice, load the Bluetooth
keymap for TV, and tell the networking stack to advertise TV support.
Next you initiate the pairing from the Bluetooth remote and pick the
Linux box. This causes a pairing established exchange which tells the
Linux box to make the pairing persistent.

I believe the Bluetooth remote profile is handled in user space by the
BlueZ stack. BlueZ should be aware of the remote pairings. When it
decodes a button press it would need to inject the scancode into the
correct evdev subdevice. Evdev would translate it in the keymap and
create the keyevent. This is the same mechanism LIRC is using.

At a more general level we're missing a way for something like Myth to
declare that it is a DVR device. Myth should load, say I'm a DVR, and
then the remote control subsystem should automatically create a
Bluetooth DVR profile, load an IR profile for Motorola DVR on a
universal remote if the box has Bluetooth, IR or 802.15.4.

The whole concept of a remote control subsystem seems like it needs
more design work done. We keep coming up with big areas that no one
has thought about.

-- 
Jon Smirl
jonsmirl@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/