On Tue, Dec 15, 2009 at 3:45 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > On Tue, Dec 15, 2009 at 3:33 PM, Pavel Machek <pavel@xxxxxx> 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@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
