Hi Fred, >> we should check for eSCO and transparent SCO support. We do need both. And we also need to figure out on how to handle the incoming situation correctly, >> >> Is the error ECONNABORTED a correct one. > > My understanding of Vinicius comment is that some adapters may not > support esco but still have transparent data support thanks to Setup > Sync Conn. Transparent data on these adapters can be supported for > cheap since the connection establishment would be the same. > > If we choose to go for eSCO AND transparent SCO support, then these > adapters get unused features. > > One possibility is to check for Setup Synchronous Connection command bit > instead of Esco feature bit. But that makes a ugly bunch of tests : > if cvsd is requested > check esco feature bit. > if transparent data is requested > check setup sync conn command bit and transparent data feature bit. > > The only problem so far is that I have yet to see these adapters :) doing transparent SCO on an adapter without eSCO support is useless. I would not bother supporting this at all. Especially for HFP 1.6 with mSBC we have the fact it mandates eSCO. > About the error ECONNABORTED, it is what the patch does : abort a connection. It is not used for other purposes. If you really want to > change, I'm ok with EOPNOTSUPP, otherwise please suggest. I am not sure which error to use. This is more like an open discussion on getting some valid consensus here. Since as a matter of fact once connect() or accept() + read() fails, we need to re-negotiate the codec via HFP. So that must be possible from the API. Hence we need a clear error code. Regards Marcel -- 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
