Martin,
when I read your reply to Zoltan, I have a different impression of the
work remaining to be done.
At the end of the day, I would favour a very pragmatic approach :
- how can we enable multi user support fir BT in tizen 3.0
- how to have a unified implementation (Samsung/Intel)
- keep in sync with upstream projects (in particular BlueZ)
I expect that some options required to achieve those goals will be tough
but they should be our focal points.
Regards
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
Le 15/11/2014 02:57, Xu, Martin a écrit :
Dominique/Corentin:
Thank you very much for your summary.
Looks like we still have some works to do. But if that is all we
have, I do not find any big issue here. I believe we can work together
to resolve the.
And I am also open to the option to use old framework, if after
evaluation, we can quite sure that it is more stable and easy to use
than NTB, why not use old one?
I hope you know that my ultimate goal is to contribute Bluetooth and
contribute Tizen-3.0. not work for NTB.
Besides, could you let me know what is the feature list of Bluetooth
for Tizen-3.0 common, that is the first thing we need to know. ;)
Please see my comments.
Thanks!
*From:*Corentin Lecouvey [mailto:[email protected]]
*Sent:* Friday, November 14, 2014 7:42
*To:* Xu, Martin; Zheng, Wu; Le Foll, Dominique; MECHIN Bruno
*Subject:* NTB integration status
Hi all,
I would like to expose the progress and blocking points of NTB
integration into Common.
According to the multi-user bluetooth wiki page, phase 1 seems to be
almost accomplished.
[Martin] we really hope we have understood your phase 1 request
correctly. And we need your clearly confirmation that our phase1 is
ready. Since phase1 multi-user function is very important for us. J
But some bluetooth C API don't work as expected.
[Martin] Can you tell me the detail? Thanks!
Let me detail the current status of NTB integration :
[Martin]: The bugs owner is Coretine, and I find Coretine is working
on the two bugs, right? If you need any help, please let us know.
*- dedicated user :*
https://bugs.tizen.org/jira/browse/TC-1981
<TC-1981https://bugs.tizen.org/jira/browse/TC-1981> : user privileges
record file is not created
https://bugs.tizen.org/jira/browse/TC-1972 : dedicated 'bluetooth' user
*[Martin] I have add comments to your patches to fix the bugs, I hope
that can help you. **J***
--> there are some difficulties to activate dbus obex service on dbus
session when it go through systemd dbus service activation.
If obex is only run as 'bluetooth' user, we could activate it on dbus
system and apply security with security-manager.
Then security-manager could set some relevant permissions/rights and
move transferred data to the right user directory...
We need to know how obex will be launched.
[Martin] Let’s talk in the Conference meeting. I’d like to know more
detail. I believe we can find right solution. J
*- NFC :*
https://bugs.tizen.org/jira/browse/TC-1970 : Add OOB feature in NTB
https://bugs.tizen.org/jira/browse/TC-1971 : OOB pairing mechanism is
broken on NFC manager daemon
[Martin] we can fix it next week
--> According to the Zheng Wu's latest comment, there is a plugin in
BlueZ 5 now and so the related code from nfc-manager-neard can be removed.
*- OPP : *
https://bugs.tizen.org/jira/browse/TC-2088 : user can not send file
using OPP client C API
https://bugs.tizen.org/jira/browse/TC-2090 : unable to receive file
with OPP server C API
[Martin] That feature should be ready long long time ago. Maybe there
has some bug there.
Besides, have you set obex simple agent so user can confirm to acquire
the file when remote send the file?
But even not do that it should not segment fault. The issues should be
fixed before next Monday.
--> OPP server/client CAPI are not working now. Zheng Wu told me that
it will be fixed in few days.
*- Telephony :*
https://bugs.tizen.org/jira/browse/TC-2091 : Add Telephony C APIs
based on OFONO
--> There is a need to get (at least for IVI) some HFP HF profile C
API based on OFONO.
[Martin]I am not sure we need HFP HF CAPI , because oFono as the same
comms service layer with BlueZ can talk with each other to handle HFP
HF well.
And I think UI can talk with oFono directly, and Bluetooth HFP HF
should just be a HF modem from oFono. So the dial UI can call oFono
directly to use Bluetooth HF function.
Maybe we need Telephony CAPI here. but that is out of our scope here.
*Other questions :*
- How obex agent is supposed to be handled ? Does it need to be
register in popup app as it is done for pairing popups ?
If yes, a new Jira bug can be filed.
[Martin] If I did not remember wrong, we need to have a popup UI and
let user to confirm to accept the file transferred from remote device.
- If obex is only run on 'bluetooth' user for all other users, can
obex service run on dbus system instead of session ?
[Martin] in my knowledge, obex should run as DBus session. Only root
user run as system Dbus. I can’t find any issue here. Let’s talk in
next Conference meeting.
- Is there a need to also get HFP AG profile C API in NTB based on OFONO ?
[Martin] My answer is no or at least the current Bluetooth HFP AG
profile CAPI is not useful, since that is for Samsung telephony stack.
Currently do we need to support HFP AG? I believe HFP HF is more
important for IVI.
- There maybe a bug with .bt_userprivileges, when pairing with NTB and
unpairing with bluetoothctl. I'm not sure the file is synced in that
case...
[Martin] Please work with Zhengwu and make sure resolve the possible
issues
*Multi-user in Samsung bluetooth-frwk :*
If we move to the Samsung bluetooth-frwk, we will also have to
integrate the mulit-user phase 1 task.
- I guess that retrieving the UID from the user who requests the
pairing in bt-service could be done as in NTB.
- Notifications are already handled.
- I don't know how obex is used on this bt-frwk.
- Adapt bt-service to be run as a dedicated user.
- ...
[Martin] you can have a evaluation on the efforts to use Samsung
Bluetooth framework, if it is much easy than NTB, we can do that.
But It maybe not easy. Samsung Bluetooth-frwk does not support
multi-user at all. And obex is run almost same with NTB. As I know
Samsung has a team to make the framework work and stable on each of
their specific products.
I am sure whether we need to spend same efforts on IVI. Besides, I am
not sure our multi-user patches can be accepted.
We have a lot of experience on both framework. One year ago, we really
suffering to integrate Samsung framework, and upgrade BlueZ to 5.x.
And that make me decide to write the new one.
Until now, I was mainly focused on Web Bluetooth API which doesn't
offer all of these bluetooth profiles.
So I haven't tested yet other bt profiles CAPI (hid, avrcp, a2dp,...).
[Martin] I was complaining that there are some web API issue, that is
what you are working on? Can you tell us detail about that?
[Martin] as Bluetooth integrator, I hope you can tell us what is the
feature list of Bluetooth on tizen-3.0 common. That is the first thing
we need to know, I believe.
You know there are huge of Bluetooth profiles, as an OS we can’t claim
to support very thing, we need clearly tell people what profile we
need to support.
Thanks!
Best regards,
Corentin
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
