I brought up BlueZ4 "harvesting" for Sailfish in this week's Mer Meeting:
http://merproject.org/meetings/mer-meeting/2014/mer-meeting.2014-09-09-15.00.html Calling Hannu Mallat! I am told that you are "the guy" :-) I am forwarding this earlier e-mail thread to the Sailfish development list, for archiving of the conversation, and so that Bluetooth developers on Mer/Sailfish/Jolla can have this additional context. Thanks! Cheers, Bob On Fri, Aug 29, 2014 at 4:22 AM, Bob Summerwill <b...@summerwill.net> wrote: > Thanks for the great summary, Javier. > > I just realized that I never pulled in the authors who Mikko highlighted > earlier in the chain, so I will do so now. > > Remaining questions in my mind ... > > 1. Were the non-upstreamed changes to BlueZ 4 made in Tizen 2.x which > would still have value in BlueZ 5 (and so for Tizen 3.x)? I don't know, > but just wanted to throw that thought into Tizen-world. Somebody would > need to audit that Tizen 2.x version against a vanilla BlueZ 4 and make a > judgment call on that. > > 2. If BlueZ 5 is incomplete, I would assume that BlueZ 4 master is still > being maintained? If so, it would be nice if Tizen could upstream changes > which weren't hacks, so that other distros still using BlueZ 4 could > benefit. That benefit would go beyond just mobile, right? > > 3. And then for Sailfish, it looks like we could just harvest Tizen > changes into the Sailfish BlueZ 4 whether or not any upstreaming happens. > Looks like Javier is entirely on the ball for that. He has mentioned > asking who is the Bluetooth "person" for Sailfish at the next community > meeting. So there is no further TODO for that. It is moot until > Sailfish gets up to Qt 5.4. > > Thanks, everyone! > > > Cheers, > Bob > > > Cheers, > Bob > > > 7745-M: Taesoo Jun <steve....@samsung.com> > 7746-M: wu zheng <wu.zh...@intel.com> > 7747-M: Pyun DoHyun <dh79.p...@samsung.com> > > > On Tue, Aug 26, 2014 at 10:52 AM, Javier S. Pedro <jo...@javispedro.com> > wrote: > >> >> Bob Summerwill <b...@summerwill.net> escribió: >> >> Hey Javier, >>> >>> What was the non-upstreamed functionality you saw in Tizen 2.x? >>> >>> I guess that it may be the case that the additions were additions to >>> BlueZ >>> 4 which were already present in BlueZ? >>> >>> Mikko - please could you confirm that Tizen 3.0 is using BlueZ 5? Is >>> it >>> a full BLE stack, as far as you are aware? Javier said ... >>> >>> https://twitter.com/javispedro/status/497161968508469248 >>> "Wow, Tizen folks went all the trouble to add full BLE support to Bluez4. >>> Pairing, peripheral-role, advertising, everything." >>> >> >> Hello Bob, >> >> that message came from the source files from the Gear2 tarball: >> - bluez-4.101_39 contains a lot of patches (some guarded by #ifdef >> __TIZEN_PATCH__) that enabled many LE functionality (e.g. pairing, key >> exchanges using mgmtops, gatt server/client, advertising control, etc.). >> Apart from this there are some Tizen specific patches that are useless >> upstream (e.g. battery level reading). >> - linux-3.4-exynos3250-1.0 contains the required patches to enable the >> kernel side of this. Without them, the Bluetooth subsystem from 3.4 was way >> too old to handle most LE operations via mgmtops. >> They are enabled by Kconfig's CONFIG_TIZEN_WIP and CONFIG_TIZEN_RANDOM. >> >> Whether these are backports from Bluez5 and/or more recent kernels I >> don't know. I suspect the Bluez patches at least are a fork, because the >> current Bluez5 LE functionality comes, iirc, from a Google employee. So I >> do not think they are useful for upstreaming any longer. >> >> My point was that many systems are stuck with Bluez4, because of the API >> breakage that comes with Bluez5 means rewriting most of the platform BT >> support, and because some parts of Bluez5 are not ready yet (LE among >> others). Thus, enabling LE in Bluez4, keeping API compatibility, is very >> interesting. An example of such platform is Jolla Sailfish, but I suspect >> there are others (Ubuntu comes to mind). >> >> So while I don't think the Tizen changes are useful for upstreaming >> (might be wrong), they would still be useful for e.g. Sailfish as a >> temporary solution until Bluez5 support 'matures'. >> >> In fact, a future version of Qt will allow GATT even under Bluez4 by >> doing something similar to what gatttool does. Qt itself does not talk with >> Bluez5 yet. >> >> Javier. >> >> > > > -- > b...@summerwill.net > > -- b...@summerwill.net
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
