Hi Marcel, > actually we want to convert our Android support over to bt_gatt. We have the full PTS documentation and the guys are working on end-to-end test cases using the Android HAL APIs. So hopefully such a conversion will not cause any big issues. However that said, it is a conversion that we want. Sooner than later. > Of course, moving the Android code over to bt_gatt makes sense, though until then it's probably ideal not to cause any regressions in the GAttrib code path. My idea was to start using bt_gatt in the D-Bus daemon and get it unit tested first so that we can flush out any bugs and then start Android discussion once we have all the confidence that things work as intended. > I think the only problem is BtIO and that gives us a GIOChannel. However BtIO has caused us a few issues already in the past and we might need to take a step back and just take the file descriptor and free the GIOChannel after that. At the end of the day, GIOChannel has to be removed from the whole source code. So why not start with GATT. I think it is a perfect candidate for giving this a trial run. > Sounds good to me. Actually, for LE connections at least, is there a desire to move away from BtIO eventually? Why not just directly set the socket options and open the connection in device.c? What does BtIO do that I'm missing? Cheers, Arman -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
