Bluetooth Extension #127

Closed
timwindsor opened this Issue Jan 2, 2013 · 13 comments

Comments

Projects
None yet
3 participants
Member

timwindsor commented Jan 2, 2013

An Extension is needed for WebWorks that would allow search and discovery of Bluetooth devices, connecting, and communication over Bluetooth.

Current proposal:

discover - Returns the list of all discovered devices.
The WebWorks sends nothing.
The Native side will returns a list of Bluetooth devices in JSON

bluetoothActive - Indicate whether or not a device is active
The WebWorks sends the device identification.
The Native side returns a true/false flag.

discoverableActive - Indicate whether or not a device is currently discoverable by other Bluetooth devices
The WebWorks sends the device identification.
The Native side returns a true/false flag.

toggleBluetoothActive - Toggle the active state of a device
The WebWorks sends the device identification.
The Native side toggles the device active state.

toggleDiscoverableActive - Toggle the discoverability of a device
The WebWorks side sends the device identification.
The Native side toggles the device discoverability.

DeviceInfo - Returns the Bluetooth related information about a device
The WebWorks sends the device identification.
The Native side returns an aggregate of Bluetooth information pertaining to the device.

startSPPServer - Starts a local SPP service (server mode)
The WebWorks sends the device identification. This has to be a local Bluetooth device.
The Native side returns Pass/Fail.

connectToSPPService - Establishes a connection to a remote SPP service (client mode)
The WebWorks sends the device indentification.
The Native side returns a Connection ID and Pass/Fail.

sendSPPMessage - Sends a message to the remote peer on a SSP connection.
The WebWorks sends the string containing the message.
The Native side returns Pass/Fail.

ReceiveSPPMessage - Receive a message from the remote peer on a SSP connection.
The WebWorks sends the device to receive from, and the buffer string where to put the received message.
The Native side fills the buffer string if data was received and returns the size of the received data along with Pass/Fail status.

closeSPPConnection - Closes the SPP session (in client and server mode)
The WebWorks sends the connection (Connection ID).
The Native side returns Pass/Fail.

Contributor

peardox commented Oct 16, 2013

Hehe - I just did something similar as you know for uPnP

This may prove a useful addition to the GamePad discussion we're having ATM

Contributor

rtholmes commented Sep 2, 2014

Tim, do you know if anyone ever tried to do this? The webworks versions of either of these would be awesome!

https://github.com/blackberry/Cascades-Community-Samples/tree/master/CscMonitor https://github.com/blackberry/Cascades-Community-Samples/tree/master/HeartMonitor

Member

timwindsor commented Sep 2, 2014

This is being worked on right now, by @jcmurray who did those Cascades Bluetooth samples. He's making great progress on it and I expect it will be out "soonish". We haven't had many demands for something like this so we backburner'd it until now.

Contributor

peardox commented Sep 2, 2014

Should be fairly simple to hook the driver into WW as well

We've done this before with other drivers

I thought 10.3 had this?i

Soz, Tim, simply comments on obvious solutions (we're fixed worse)

On Tue, Sep 2, 2014 at 9:36 PM, Tim Windsor notifications@github.com
wrote:

This is being worked on right now, but @jcmurray
https://github.com/jcmurray who did those Cascades Bluetooth samples.
He's making great progress on it and I expect it will be out "soonish". We
haven't had many demands for something like this so we backburner'd it
until now.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Member

timwindsor commented Sep 2, 2014

Yeah, due to all the work we've done so far, the code is largely just dropped in place. It's really just about wiring the parts together and deciding what we want the API to look like, and what Bt profiles to support. I sent John the template and I think he had a working prototype the very next day. It's John so I wasn't really surprised, but I'd still be reading API docs at this point.

Contributor

peardox commented Sep 2, 2014

What the hell am I talking about

We had BT in 2.1 - it's how we got the damned JoySticks working

The only real issue is device identification - you can get most of that
from Linux

lsusb / lspci gives you the devid of a shit load of stuff and BT typically
fakes itself a USB

God, I'm a genius idiot sometimes :)

On Tue, Sep 2, 2014 at 10:11 PM, Simon Booth simon@peardox.com wrote:

Should be fairly simple to hook the driver into WW as well

We've done this before with other drivers

I thought 10.3 had this?i

Soz, Tim, simply comments on obvious solutions (we're fixed worse)

On Tue, Sep 2, 2014 at 9:36 PM, Tim Windsor notifications@github.com
wrote:

This is being worked on right now, but @jcmurray
https://github.com/jcmurray who did those Cascades Bluetooth samples.
He's making great progress on it and I expect it will be out "soonish". We
haven't had many demands for something like this so we backburner'd it
until now.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

peardox commented Sep 2, 2014

You can hard code the devid in a lookup table - I do this for the BT sticks
I have

It's rather simple and with your connections should be very easy for you to
get a fairly definitive list

We did some work about a year ago with one of your BT guys - worth talking
too

Most of the companies that produce these chips are Chinese / Taiwanese -
wish I wasn't still working, only takes a day or two to get this info (some
are harder)

On Tue, Sep 2, 2014 at 10:17 PM, Tim Windsor notifications@github.com
wrote:

Yeah, due to all the work we've done so far, the code is largely just
dropped in place. It's really just about wiring the parts together and
deciding what we want the API to look like, and what Bt profiles to
support. I sent John the template and I think he had a working prototype
the very next day. It's John so I wasn't really surprised, but I'd still be
reading API docs at this point.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

peardox commented Sep 2, 2014

Rat's (again)

You can take the original stick code - remove the I want a stick - and
you'll get everything

I'm talking about the NDK version

I've connected unknown BT devices to my crap and updated the code to
identify everything

Yeah, I did this with a limited number of devices but it works

Essentially what you want is a devid -> device list

I'll TRY to give you a little code this week - I've done far too for you
little since some idiot decided to pay me

On Tue, Sep 2, 2014 at 10:23 PM, Simon Booth simon@peardox.com wrote:

You can hard code the devid in a lookup table - I do this for the BT
sticks I have

It's rather simple and with your connections should be very easy for you
to get a fairly definitive list

We did some work about a year ago with one of your BT guys - worth talking
too

Most of the companies that produce these chips are Chinese / Taiwanese -
wish I wasn't still working, only takes a day or two to get this info (some
are harder)

On Tue, Sep 2, 2014 at 10:17 PM, Tim Windsor notifications@github.com
wrote:

Yeah, due to all the work we've done so far, the code is largely just
dropped in place. It's really just about wiring the parts together and
deciding what we want the API to look like, and what Bt profiles to
support. I sent John the template and I think he had a working prototype
the very next day. It's John so I wasn't really surprised, but I'd still be
reading API docs at this point.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

peardox commented Sep 2, 2014

Soz - quick look

https://github.com/peardox/NDK-Samples/tree/master/Gamepad

Remove the screen from discovery in main.c and you get everything

I've got more code for this stuff but tracking it down is not so simple

As I said, a year later - I'll try to get my crap doing other shit

Gimme a few hours

On Tue, Sep 2, 2014 at 10:30 PM, Simon Booth simon@peardox.com wrote:

Rat's (again)

You can take the original stick code - remove the I want a stick - and
you'll get everything

I'm talking about the NDK version

I've connected unknown BT devices to my crap and updated the code to
identify everything

Yeah, I did this with a limited number of devices but it works

Essentially what you want is a devid -> device list

I'll TRY to give you a little code this week - I've done far too for
you little since some idiot decided to pay me

On Tue, Sep 2, 2014 at 10:23 PM, Simon Booth simon@peardox.com wrote:

You can hard code the devid in a lookup table - I do this for the BT
sticks I have

It's rather simple and with your connections should be very easy for you
to get a fairly definitive list

We did some work about a year ago with one of your BT guys - worth
talking too

Most of the companies that produce these chips are Chinese / Taiwanese -
wish I wasn't still working, only takes a day or two to get this info (some
are harder)

On Tue, Sep 2, 2014 at 10:17 PM, Tim Windsor notifications@github.com
wrote:

Yeah, due to all the work we've done so far, the code is largely just
dropped in place. It's really just about wiring the parts together and
deciding what we want the API to look like, and what Bt profiles to
support. I sent John the template and I think he had a working prototype
the very next day. It's John so I wasn't really surprised, but I'd still be
reading API docs at this point.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

peardox commented Sep 2, 2014

Found it (I think)

Take this junk...

static void initController(GameController *controller, int player){ //
Initialize controller values. controller->handle = 0; controller->type = 0;
controller->analogCount = 0; controller->buttonCount = 0; controller->
buttons = 0; controller->analog0[0] = controller->analog0[1] = controller->
analog0[2] = 0; controller->analog1[0] = controller->analog1[1] = controller
->analog1[2] = 0; sprintf(controller->deviceString, "Player %d: No device
detected.", player + 1);}

On Tue, Sep 2, 2014 at 10:50 PM, Simon Booth simon@peardox.com wrote:

Soz - quick look

https://github.com/peardox/NDK-Samples/tree/master/Gamepad

Remove the screen from discovery in main.c and you get everything

I've got more code for this stuff but tracking it down is not so simple

As I said, a year later - I'll try to get my crap doing other shit

Gimme a few hours

On Tue, Sep 2, 2014 at 10:30 PM, Simon Booth simon@peardox.com wrote:

Rat's (again)

You can take the original stick code - remove the I want a stick - and
you'll get everything

I'm talking about the NDK version

I've connected unknown BT devices to my crap and updated the code to
identify everything

Yeah, I did this with a limited number of devices but it works

Essentially what you want is a devid -> device list

I'll TRY to give you a little code this week - I've done far too for
you little since some idiot decided to pay me

On Tue, Sep 2, 2014 at 10:23 PM, Simon Booth simon@peardox.com wrote:

You can hard code the devid in a lookup table - I do this for the BT
sticks I have

It's rather simple and with your connections should be very easy for you
to get a fairly definitive list

We did some work about a year ago with one of your BT guys - worth
talking too

Most of the companies that produce these chips are Chinese / Taiwanese -
wish I wasn't still working, only takes a day or two to get this info (some
are harder)

On Tue, Sep 2, 2014 at 10:17 PM, Tim Windsor notifications@github.com
wrote:

Yeah, due to all the work we've done so far, the code is largely just
dropped in place. It's really just about wiring the parts together and
deciding what we want the API to look like, and what Bt profiles to
support. I sent John the template and I think he had a working prototype
the very next day. It's John so I wasn't really surprised, but I'd still be
reading API docs at this point.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

peardox commented Sep 2, 2014

Reply screwed up

Should be this one - apology to go south as well in advance, this is likely
the easiest template to follow (read before send this time....)

bool loadController(GameController *controller){ const char *nameorid; int i
= 0; // Query libscreen for information about this device. if(
screen_get_device_property_iv(controller->handle, SCREEN_PROPERTY_TYPE, &
controller->type) == -1) { return false; } if(screen_get_device_property_cv(
controller->handle, SCREEN_PROPERTY_ID_STRING, sizeof(controller->id),
controller->id) == -1) { return false; } if(screen_get_device_property_iv(
controller->handle, SCREEN_PROPERTY_BUTTON_COUNT, &controller->buttonCount)
== -1) { return false; } // Check for the existence of analog sticks. if (!
screen_get_device_property_iv(controller->handle, SCREEN_PROPERTY_ANALOG0,
controller->analog0)) { ++controller->analogCount; } if (!
screen_get_device_property_iv(controller->handle, SCREEN_PROPERTY_ANALOG1,
controller->analog1)) { ++controller->analogCount; } nameorid = controller->
id; while(gcid[i]) { if(strncmp(&(controller->id[2]), gcid[i], 9) == 0) {
nameorid = gcfriendly[i]; break; } i++; } sprintf(controller->deviceString,
"%s", nameorid); return true;}

On Tue, Sep 2, 2014 at 11:01 PM, Simon Booth simon@peardox.com wrote:

Found it (I think)

Take this junk...

static void initController(GameController *controller, int player) { //
Initialize controller values. controller->handle = 0; controller->type =
0; controller->analogCount = 0; controller->buttonCount = 0; controller
->buttons = 0; controller->analog0[0] = controller->analog0[1] =
controller->analog0[2] = 0; controller->analog1[0] = controller->analog1[
1] = controller->analog1[2] = 0; sprintf(controller->deviceString, "Player
%d: No device detected.", player + 1); }

On Tue, Sep 2, 2014 at 10:50 PM, Simon Booth simon@peardox.com wrote:

Soz - quick look

https://github.com/peardox/NDK-Samples/tree/master/Gamepad

Remove the screen from discovery in main.c and you get everything

I've got more code for this stuff but tracking it down is not so simple

As I said, a year later - I'll try to get my crap doing other shit

Gimme a few hours

On Tue, Sep 2, 2014 at 10:30 PM, Simon Booth simon@peardox.com wrote:

Rat's (again)

You can take the original stick code - remove the I want a stick - and
you'll get everything

I'm talking about the NDK version

I've connected unknown BT devices to my crap and updated the code to
identify everything

Yeah, I did this with a limited number of devices but it works

Essentially what you want is a devid -> device list

I'll TRY to give you a little code this week - I've done far too for
you little since some idiot decided to pay me

On Tue, Sep 2, 2014 at 10:23 PM, Simon Booth simon@peardox.com wrote:

You can hard code the devid in a lookup table - I do this for the BT
sticks I have

It's rather simple and with your connections should be very easy for
you to get a fairly definitive list

We did some work about a year ago with one of your BT guys - worth
talking too

Most of the companies that produce these chips are Chinese / Taiwanese

  • wish I wasn't still working, only takes a day or two to get this info
    (some are harder)

On Tue, Sep 2, 2014 at 10:17 PM, Tim Windsor notifications@github.com
wrote:

Yeah, due to all the work we've done so far, the code is largely just
dropped in place. It's really just about wiring the parts together and
deciding what we want the API to look like, and what Bt profiles to
support. I sent John the template and I think he had a working prototype
the very next day. It's John so I wasn't really surprised, but I'd still be
reading API docs at this point.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Contributor

peardox commented Sep 2, 2014

Yep - that's the puppy

You want this one - screen_get_device_property_iv that's what I was after

I'm pretty sure if you do a search for all (not just screen), you get
everything

Soz, Tim - spent too much time on this already

And to think, you could have employed me a year ago - hahaha

Hope this points you in the right direction

Final point

http://en.wikipedia.org/wiki/List_of_Bluetooth_profiles

On Tue, Sep 2, 2014 at 11:05 PM, Simon Booth simon@peardox.com wrote:

Reply screwed up

Should be this one - apology to go south as well in advance, this is
likely the easiest template to follow (read before send this time....)

bool loadController(GameController *controller) { const char *nameorid;
int i = 0; // Query libscreen for information about this device. if(
screen_get_device_property_iv(controller->handle, SCREEN_PROPERTY_TYPE, &
controller->type) == -1) { return false; } if(
screen_get_device_property_cv(controller->handle,
SCREEN_PROPERTY_ID_STRING, sizeof(controller->id), controller->id) == -1)
{ return false; } if(screen_get_device_property_iv(controller->handle,
SCREEN_PROPERTY_BUTTON_COUNT, &controller->buttonCount) == -1) { return
false; } // Check for the existence of analog sticks. if (!
screen_get_device_property_iv(controller->handle, SCREEN_PROPERTY_ANALOG0,
controller->analog0)) { ++controller->analogCount; } if (!
screen_get_device_property_iv(controller->handle, SCREEN_PROPERTY_ANALOG1,
controller->analog1)) { ++controller->analogCount; } nameorid =
controller->id; while(gcid[i]) { if(strncmp(&(controller->id[2]), gcid[
i], 9) == 0) { nameorid = gcfriendly[i]; break; } i++; } sprintf(
controller->deviceString, "%s", nameorid); return true; }

On Tue, Sep 2, 2014 at 11:01 PM, Simon Booth simon@peardox.com wrote:

Found it (I think)

Take this junk...

static void initController(GameController *controller, int player) { //
Initialize controller values. controller->handle = 0; controller->type
= 0; controller->analogCount = 0; controller->buttonCount = 0;
controller->buttons = 0; controller->analog0[0] = controller->analog0[1]
= controller->analog0[2] = 0; controller->analog1[0] = controller->
analog1[1] = controller->analog1[2] = 0; sprintf(controller->
deviceString, "Player %d: No device detected.", player + 1); }

On Tue, Sep 2, 2014 at 10:50 PM, Simon Booth simon@peardox.com wrote:

Soz - quick look

https://github.com/peardox/NDK-Samples/tree/master/Gamepad

Remove the screen from discovery in main.c and you get everything

I've got more code for this stuff but tracking it down is not so simple

As I said, a year later - I'll try to get my crap doing other shit

Gimme a few hours

On Tue, Sep 2, 2014 at 10:30 PM, Simon Booth simon@peardox.com wrote:

Rat's (again)

You can take the original stick code - remove the I want a stick - and
you'll get everything

I'm talking about the NDK version

I've connected unknown BT devices to my crap and updated the code to
identify everything

Yeah, I did this with a limited number of devices but it works

Essentially what you want is a devid -> device list

I'll TRY to give you a little code this week - I've done far too for
you little since some idiot decided to pay me

On Tue, Sep 2, 2014 at 10:23 PM, Simon Booth simon@peardox.com wrote:

You can hard code the devid in a lookup table - I do this for the BT
sticks I have

It's rather simple and with your connections should be very easy for
you to get a fairly definitive list

We did some work about a year ago with one of your BT guys - worth
talking too

Most of the companies that produce these chips are Chinese / Taiwanese

  • wish I wasn't still working, only takes a day or two to get this info
    (some are harder)

On Tue, Sep 2, 2014 at 10:17 PM, Tim Windsor <notifications@github.com

wrote:

Yeah, due to all the work we've done so far, the code is largely just
dropped in place. It's really just about wiring the parts together and
deciding what we want the API to look like, and what Bt profiles to
support. I sent John the template and I think he had a working prototype
the very next day. It's John so I wasn't really surprised, but I'd still be
reading API docs at this point.


Reply to this email directly or view it on GitHub
#127 (comment)
.

Member

timwindsor commented Oct 22, 2014

Fixed in #333

@timwindsor timwindsor closed this Oct 22, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment