This commit implements the dial, answer and hangup callbacks to manage
call when connected to HFP AG device.
This adds +CLIP support to be able to get remote party phone number.
Claim that call waiting notifications are supported.
Required for some devices (e.g. Soundcore Motion 300),
as they stop sending commands if the reply to CCWA is not OK.
Kernel-provided MTU does not work for USB controllers and the correct
packet size to send can be known currently only from RX. So we are
waiting for RX to get it.
The known problem is USB-specific, we shouldn't need the workaround for
other transport types.
Don't wait for POLLIN for non-USB controllers on connect, but ready
things on POLLOUT as usual.
For non-USB controllers, pick some sensible packet sizes to use
initially, before we switch to same size as for RX.
The file is moved into a new "include-private" directory. This is done
because otherwise adjustments would have to be made to the list of installed
headers, the way include tests currently work and which files are
used for generating documentation.
The rfcomm list may contain various AG & HF ones, so the profile must be
checked everywhere they are looked up.
Fix the rfcomm lookups everywhere to do it.
Fixes Pipewire<->Pipewire HFP connections, and sending HFP HF commands
to HSP or AG.
HFP 1.9 adds LC3 as a possible codec in addition to CVSD & mSBC.
E.g. Pixel Buds Pro latest firmware supports it.
Add the RFCOMM side and codec selection for it.
Do relaxed parsing of RFCOMM commands for AG & HF roles, allowing
multiple commands in same buffer.
Use same parser code for all HFP/HSP AG/HF. Parse input in relaxed way,
as some devices emit spurious \n
Use bigger fallback maximum MTU, when kernel fails to tell us, which
shouldn't happen but apparently can. We choose the packet size based on
incoming data, so these values aren't usually needed so we can just bump
them.
Also report errors as necessary.
It may occur that we have RFCOMM connected as both HF and AG. The codec
switching and support checks should in this case always use the remote
HF RFCOMM.
Fix by finding the RFCOMM with the correct profile, remote as HF.
This function sends a DBusMessage on a DBusConnection
and sets the reply callback of the resulting DBusPendingCall,
as well as properly cancelling the pending call if anything fails.
Strip initial \n from commands: some devices (Sennheiser HD 350BT) send
them.
Only reply OK to empty command with terminated command line;
non-terminated lines are invalid.
Add some debug in case the RFCOMM reply contains non-printable
characters.
