lyn...@orthanc.ca:
> Bluetooth (and BLE) support woould be *very* nice to have.
I have a native bluetooth host implementation for Plan 9, not ported
from anything (it's written from scratch based on published bt specs.)
I don't regard it as sufficiently debugged for a release ... it's
missing some
Now that I have a little experience, I've formed an opinion
> Advice sought:
> 1. Would it be helpful to have a timestamp in the devices record to
> give the time the device was last seen (for some value of "seen")?
Yes; this would be a good feature.
> 2. When should a device disappear from the
you could just set the mtime to the time of the last successful
operation on that device
What do you mean exactly by "sees"? ...
all devices that are listening on inquiry scan channels and respond to
inquiry requests.
It looks like your requirement might be satisfied by one or
th
> Presumably there's still a medium sized asteroid of pain to go through
> to get something like,
> say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
> working sensibly?
A2DP will need synchronous connections which aren't implemented
yet (sorry).
AVRCP itself looks straightforwa
> it would be neat if the plumber and thus auth/fgui could be pressed
> into service for entering the pairing PIN.
I don't quite see the connection between plumber and fgui - doesn't
fgui just read directly from /mnt/factotum/needkey?
At present there's a needkey-like mechanism for PINs - the equ
>> What do you mean exactly by "sees"? ...
>
> all devices that are listening on inquiry scan channels and respond to
> inquiry requests.
It looks like your requirement might be satisfied by one or
the other of these things in the /net/bt/devices record:
- a discoverable (ie "responded to most r
Thanks a million for all your work on this:
it means I'll probably be running plan9 seriously soon:-).
To be selfish for a moment ...
Presumably there's still a medium sized asteroid of pain to go through
to get something like,
say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
w
Fantastic work Richard, I too will be very interested in playing
with this once you are ready.
The only one thought - probably not mentioned as it is so obvious,
it would be neat if the plumber and thus auth/fgui could be pressed
into service for entering the pairing PIN.
-Steve
> What do you mean exactly by "sees"? A device may be known
> because it responded to an inquiry (probe for all devices)
all devices that are listening on inquiry scan channels and respond to
inquiry requests. (i'm just learning the details and my terminology
may be a bit off).
> I was going to comment that you should use %q instead of '%s'
I do, of course. The funny apostrophe was MacOS's idea.
> Does Bluetooth specify UTF-8 as the string encoding sent over
> the network?
No, just that the device name is encoded as UTF-8 (up to 248 octets).
> 00236c9dd69f 38010c 'Richard Miller’s MacBook'
I was going to comment that you should use %q instead of '%s'
but now I notice that the apostrophe is 0x2019 not a simple '.
Does Bluetooth specify UTF-8 as the string encoding sent over
the network?
Russ
>> ... or because you paired with the device at some time in
>> the past and have a stored link key for it.
>
> Shouldn't factotum be in charge of storing keys? Or do you mean just
> keys that happen to be resident in the stack right now?
No, I mean keys which are kept in non-volatile store insi
On Thu, Sep 24, 2009 at 09:22:17AM +0100, Richard Miller wrote:
> What do you mean exactly by "sees"? A device may be known
> because it responded to an inquiry (probe for all devices) or a
> page (probe for specific device), or because it sent you an inquiry
> or a page, or because you paired wit
>> cat /n/bt/devices
>> (see what devices have been found)
Typo - should be /net/bt/devices - currently gives you device address,
class, and friendly name for all "known" devices (see below). First
on list is self.
term% cat /net/bt/devices
00025b0011bf 020104 'atom'
00236c9dd69f 38010c 'Ri
> thank you for doing this. like nemo, i'd like to offer testing.
To echo nemo and skip, I do own one USB bluetooth radio and many
mobile handsets. Count me in, if you wish.
++L
> echo inquiry M N >/net/bt/ctl
> (spend up to M seconds looking for up to N devices)
> cat /n/bt/devices
> (see what devices have been found)
the application i have in mind inventories all device id's it sees
with a time stamp. i need to measure the flow between two endpoints
based o
> what does the device id discovery look like?
At present:
echo inquiry M N >/net/bt/ctl
(spend up to M seconds looking for up to N devices)
cat /n/bt/devices
(see what devices have been found)
If it's useful, I'd love to beta test or alpha test or whatever.
thanks a lot for your effort!
> import -A bt!00123456789A!77 / /n/blue
what does the device id discovery look like?
> aux/listen1 bt!*!77 /bin/exportfs
> import -A bt!00123456789A!77 / /n/blue
beautiful!
> A very superficial glance a long time ago suggested that it was a
> twisty little maze of de-facto and de-vulgus standards.
> i.e. the death of a thousand committees.
The core standard (defining the communication layers) is actually
not too bad, compared to some I've had to look at. It's huge
> anyone looked at this or given it any thought?
I've been working on a bluetooth implementation which should be
ready for initial release soon. Just the core communication layers
(usb-hci transport, hci, l2cap, rfcomm), and fairly rudimentary:
I've tried to pick a minimal useful subset rather th
A very superficial glance a long time ago suggested that it was a
twisty little maze of de-facto and de-vulgus standards.
i.e. the death of a thousand committees.
Then there's the hardware ...
On 22 Sep 2009, at 20:34, Skip Tavakkolian wrote:
anyone looked at this or given it any thought?
On Sep 22, 2009, at 3:34 PM, Skip Tavakkolian wrote:
anyone looked at this or given it any thought?
I was going to check into it after I did some tests in the audio
system. Although I probably won't finish my tests till early-mid
october.
anyone looked at this or given it any thought?
25 matches
Mail list logo