On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl [off-list ref] wrote:

On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek [off-list ref] wrote:

quoted

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@gmail.com