Hello, I can confirm that BLE seems to work on my N9. At least, I've established a connection with my Adonit stylus and read a few values. Additionally, I can confirm it does not work on the N950, which seems to have a WL1271 variant that is too old for BLE.

I've used my own GATT stack, which I hope to eventually reuse in the Jolla device for MetaWatch connectivity and other experiments (since it seems that Jolla device is shipping without working QtBluetooth implement and with Bluez < 5.0).

Now the question is: anyone interested? what BLE devices do you have in mind?

I think the Jolla ships with bluez 4.101, which should be enough for Bluetooth LE (at least it is on a linux machine with a USB dongle).

My Fitbit one is still waiting for a connection, but since the protocol is proprietary (and I haven't seen any free implemetations for the BLE Fitbit devices) I don't have much hope...

Actually no version of Bluez < 5 contains a working LE API. Bluez 4 has "something" (see doc/attribute-api.txt) but it lacks support for very simple GATT features such as subscribing to an attribute for notifications/indications.
Even the Bluez version on the N9 contains some support for BLE, and you can test it just by running:
on a root terminal.

Because they too use Bluez 4, the situation on the Jolla is exactly the same as on the N9: the hardware supports it, but there is no API to use it.

Bluez 5 requires kernel 3.5 (or at least the addr_type field in L2 sockaddr struct), which the Jolla doesn't have.
Many people with Bluez 4 use a tool called "gatttool" as GATT stack, which, despite coming within the Bluez tarball, actually mostly bypasses user-space Bluez and opens kernel bluetooth sockets directly. Additionally, because it is a tool, and not an API, you have to execute it, pass command line arguments, parse the result, etc. etc. This seems to be the approach Qt 5.3 is taking, which I'd not trust very much. But if Qt 5.3 is choosing this I suppose it means we're stuck with Bluez 4 for a while.

So Qt 5x can't even take advantage of Bluez 5, are you sure?
If not entirely correct, I was going to ask would it be too late for us to approach Jolla to implement this:

I am sure. But that is just one of the pieces.

Developers can use one of the following APIs to connect to BLE peripherals on the N9 or the Jolla device:

- Bluez 4 D-Bus API

Requisites: none, it is already available on both N9 and Jolla.
Cons: weird API, minimal functionality, some things just fail (dunno why, possibly too old kernel)

- QtBluetooth 5.3

Requisites: Jolla to upgrade Qt to 5.3 . It will be released sometime next year, dunno when Jolla will push it towards devices.
Cons: I don't think that will ever appear on N9. Also, IMO, scripting "gatttool" doesn't seem like the right choice. No idea how it'll work.
Pros: QT-style API, compatible with Blackberry10

- Bluez 5 D-Bus API

Requisites: Someone to develop it, because it does not exist yet. Plus Mer, Qt, ofono, connman and everyone else to upgrade to Bluez 5 API. Additionally, kernel 3.5.
Cons: dunno when that will happen, if ever. But it could happen. Never on the N9, though.
Pros: If Bluez is arbitrating, you can do scanning and advertising from different programs without conflicts.

- QtBluetooth 5.??? + Bluez 5

Requisites: see above
Cons: Does not exist, but it's probably going to be something very similar to what Qt 5.3 does
Pros: QT-style API, portable

- A custom GATT/ATT library

Requisites: write it (which I'm doing)
Pros: works _right now_ on N9 and (should work on) Jolla. QT-style API. Also will work whatever the version of Bluez is.
Cons: might be redundant in the future, not portable at all

How much of this progress is also applicable to the N900, I don't know if the N9 is even running a similar bluetooth chip.

None at all. I don't remember the WL127x variant of the N900 atm (wl1251?), but considering that the N950 used one that is too old for BLE...

Additionally, neo900's current specs also lack BLE, though I'm sure you could ask the neo900 engineers "nicely" . If you have an use case for BLE, please be sure to mention it in this thread!

Wouldn't it be more wise to move to 3.5 kernel? I've been adding feature to existing 3.5 implementation as mentioned here: http://talk.maemo.org/showthread.php?p=1383872, but at the moment there is no one working on it AFAIK.
I thought that, if someone was to resolve major issues, others would join the effort, but that didn't happen...

Not sure how much it is interesting to you but I read on IRC that Jolla is planing to switch to Bluez 5 (from one of their developper)
And this is actually the reason why currently some API related to Bluez 4 are not authorised in the jolla store because it may change 'soon' (not date announced).
PS: as I am not familiar with this, my words may not be very appropriate but still hope that helps

The 3.5 kernel does not necessarily fix anything other than allowing Bluez 5 (and possibly something regarding private/random BLE address but I have no use case for those atm). The current kernel is more than enough for most use cases.

I am not sure why the current Bluez4 D-Bus BLE/GATT API (present on stock N9) has issues: it may be the kernel, or it may be not.
But, to be honest, the API itself is so obscure that no one even realized it's been there ever since the N9 was originally manufactured. So I am not much interested in it.

I suspect that what Jolla is waiting for is Qt5.2 which would bring QtBluetooth to the table, but without support for BLE at all.
If the Bluez5 migration happens in the meantime (which may happen as Mer is already on it), it just means more delays, as then they'll have to delay QtBluetooth until it's ported to Bluez5.

I hate that there are no logs for the Jolla IRC channels.