| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This allows to handle incoming connection from unknown devices.
If device happens to be sixaxis input device is created after
SDP was queried and then connection is authorized.
|
|
|
|
| |
Allow this symbol to be exported and usable from external plugins.
|
|
|
|
| |
Allow this symbol to be exported and usable from external plugins.
|
|
|
|
| |
Allow this symbol to be exported and usable from external plugins.
|
|
|
|
|
|
|
|
| |
By the time and incoming connection arrives it is not possible to
determine the role, so this changes the UUID to A/V_RemoteControl which
according to assigned number page bellow is the profile UUID for AVRCP:
https://www.bluetooth.org/en-us/specification/assigned-numbers/service-discovery
|
| |
|
|
|
|
| |
This parameter is always false so it never do anything.
|
|
|
|
| |
This parameter is always false so it never do anything.
|
| |
|
| |
|
|
|
|
|
| |
In case record is not registered it means no endpoint is available so
return -ENOPROTOOPT to indicate that it is currently not available.
|
|
|
|
|
|
| |
This is now done on demand by avdtp_register_sep and avdtp_unregister_sep
so the server socket is only registered when there is an endpoint
available and the record is properly registered.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the code does not assign a player if version is bellow 1.3,
but sometimes the version may not be initialized correctly e.g: record
could not be fetch.
Futhermore by assigning a player for 1.0 CT it won't break backward
compatibility as no commands will be sent but adds the possibility to
respond properly in case the CT is sending commands above its own
version which is a violation of the spec but unfortunately there exists
such stacks on the market.
|
|
|
|
|
| |
If position changes send a status changed event to force the position to
be resynced.
|
|
|
|
|
| |
track_watch is no longer used for anything since MPRIS interfaces was
adopted.
|
|
|
|
| |
This tracks Seeked signal and update the position in case it happens.
|
|
|
|
|
|
|
|
|
| |
If a request is outstanding in the processed list its transaction shall
not be reused as it can cause the wrong callback to be called.
This can be reproduced in very rare occasions where e.g. a notification
using the same transaction of the current request arrives before the
response itself.
|
|
|
|
|
|
| |
This pushes discover specific data to a struct which is a common practice
if the field contains callback and user_data specific to certain
operations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the session is disconnected while process_discover is pending the
source id is not removed causing the following crash:
at 0x414C08: finalize_discovery (avdtp.c:1050)
by 0x414C5A: process_discover (avdtp.c:3346)
by 0x3D46047E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3D46048157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3D46048559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A3B6: main (main.c:595)
Address 0x5e25de8 is 1,144 bytes inside a block of size 1,176 free'd
at 0x4A074C4: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3D4604D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4152F2: connection_lost (avdtp.c:1206)
by 0x4162C4: cancel_request (avdtp.c:2662)
by 0x4164BD: request_timeout (avdtp.c:2672)
by 0x3D46048962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3D46047E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3D46048157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3D46048559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A3B6: main (main.c:595)
|
| |
|
|
|
|
|
| |
auth_cb function is not used before definition so no need to forward
declare it.
|
| |
|
|
|
|
| |
This better describes what list contains.
|
|
|
|
| |
It is not used anywhere and can be removed.
|
|
|
|
| |
It is not used anywhere and can be removed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Both AV Remote and AV Remote Controller service classes are mandatory
by AVRCP CT role from 1.3 onwards. Also the assigned numbers page mention
that AV Remote must appear before AV Remote Controller:
"The AVRCP specification v1.3 and later require that 0x110E also be
included in the ServiceClassIDList before 0x110F for backwards
compatibility."
|
|
|
|
|
|
|
| |
bnep.ko, besides others, can be disabled in custom kernels if
network-support is not required. To avoid strange error messages, handle
EPROTONOSUPPORT as a special case and emit a warning that kernel support
is missing.
|
|
|
|
|
| |
Make adapter in charge of updating SDP database. This allow to decouple
SDP of code used for notifying adapters about SDP database change.
|
|
|
|
|
| |
Make adapter in charge of updating SDP database. This allow to decouple
SDP of code used for notifying adapters about SDP database change.
|
|
|
|
|
| |
Path and adapter address can be obtained easily from btd_adapter
and there is no need to keep local copy.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This replaces dbus_connection_send_with_reply with
g_dbus_send_message_with_reply which does not alter message order.
|
|
|
|
|
|
| |
The UHID_{START,STOP,OPEN,CLOSE} events should be ignored by us to avoid
triggering the warn(). It is safe to do that. Add few comments that
explain why we don't have to handle these.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The service watch is not removed so once the client disconnects the
callback is called using the data already freed:
Invalid read of size 8
at 0x428CFE: server_remove_sessions.isra.0 (server.c:605)
by 0x428D80: server_disconnect (server.c:626)
by 0x475426: service_filter (watch.c:486)
by 0x47569A: message_filter (watch.c:554)
by 0x32F840F9E5: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x474347: message_dispatch (mainloop.c:76)
by 0x3383648962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3383647E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3383648157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3383648559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A2CF: main (main.c:583)
Address 0x4eb5f00 is 32 bytes inside a block of size 56 free'd
at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x338364D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x429663: server_unregister (server.c:848)
by 0x33836648F7: g_slist_foreach (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x454180: adapter_remove (adapter.c:2886)
by 0x45C940: index_removed (adapter.c:5651)
by 0x467FDF: received_data (mgmt.c:252)
by 0x3383647E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3383648157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3383648559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A2CF: main (main.c:583)
|
|
|
|
|
|
|
|
|
|
|
| |
The position should stop at UINT32_MAX after that the progress can no
longer be calculated, this should also prevent the position to change
when the remote stack doesn't support it which is also indicated with
UINT32_MAX which apparently is the case of Spotify on Android 4.3:
[CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Position: 0xffffffff
[CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Status: playing
[CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Position: 0x000000
|
|
|
|
|
| |
Rename the option for all in-tree users. This frees up GATT_OPT_CHR_UUID to be used
for UUIDs of type bt_uuid_t* (in a next patch).
|
|
|
|
|
| |
Any request processed before the connection completes will likely fail
in avctp_browsing_send so instead delay the processing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While accepting the connection via DEFER_SETUP a second connection can
be created by using avctp_connect_browsing which will not detect one is
in course as the state has not yet changed, this can cause memory leaks
or crashes as the following:
profiles/audio/avctp.c:avctp_confirm_cb() AVCTP: incoming connect from XX:XX:XX:XX:XX:XX
profiles/audio/avctp.c:avctp_set_state() AVCTP Browsing Connecting
profiles/audio/avctp.c:avctp_connect_browsing_cb() AVCTP Browsing: connected to XX:XX:XX:XX:XX:XX
profiles/audio/avctp.c:avctp_set_state() AVCTP Browsing Connected
profiles/audio/avctp.c:avctp_connect_browsing_cb() AVCTP Browsing: connected to XX:XX:XX:XX:XX:XX
profiles/audio/avctp.c:avctp_set_state() AVCTP Browsing Connected
profiles/audio/avctp.c:session_browsing_cb() AVCTP Browsing: disconnected
profiles/audio/avctp.c:avctp_set_state() AVCTP Connected
Invalid read of size 8
at 0x41EB28: session_browsing_cb (avctp.c:842)
by 0x32F5447E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5448157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5448559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A28F: main (main.c:583)
Address 0x20 is not stack'd, malloc'd or (recently) free'd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the remote stack respond to GetCapabilities before connecting to
browsing channel connect it immediatelly as some events might depend on
it to work properly.
The spec actually recommends the browsing channel to be connected
immediatelly after the control channel:
AVRCP 1.5 - Page 23
"4.1.1 Connection establishment
...
If a browsing channel is supported by both devices it shall be
established after control channel establishment. It is recommended that
the browsing channel is established immediately after the control
channel is established and released immediately before the control
channel is released to avoid unsatisfactory latency when a browsing
command is sent."
|
|
|
|
|
| |
If remote stack for some reason don't connect the browsing channel
connect it after a timeout (1 sec.)
|
|
|
|
|
| |
The record already contain the additional protocol containing the
browsing channel but the feature is not set as it is supposed to.
|
|
|
|
|
|
|
|
|
|
| |
Both controller and target services can initiate the connection but
probably only one of the services will be in CONNECTING state which may
happen to not have browsing feature set.
Currently this happens when connecting BlueZ vs BlueZ where the CT record
does not have browsing feature set so if the corresponding service start
connecting it wont connect the browsing channel due to lack of feature.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the remote stack support both AVAILABLE_PLAYER_CHANGED and
ADDRESSED_PLAYER_CHANGED the player twice are inited twice leaking
the memory allocated in the first time:
16 bytes in 1 blocks are definitely lost in loss record 45 of 236
at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x32F544D89E: g_malloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5464BF7: g_memdup (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4247CC: avrcp_get_media_player_list_rsp (avrcp.c:2432)
by 0x41ECAB: session_browsing_cb (avctp.c:826)
by 0x32F5447E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5448157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5448559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A28F: main (main.c:583)
16 bytes in 1 blocks are definitely lost in loss record 46 of 236
at 0x4A082F7: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x32F544D946: g_realloc (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5466D43: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5467032: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5435287: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x421E62: avrcp_set_browsed_player_rsp (avrcp.c:2349)
by 0x41ECAB: session_browsing_cb (avctp.c:826)
by 0x32F5447E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5448157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x32F5448559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x40A28F: main (main.c:583)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By convention, BlueZ code checks for "Gsource id" like variables using:
if (source_id > 0)
...
Also fix the variable type to match that returned by
g_attrib_unregister().
|
|
|
|
|
|
|
| |
If device is removed while there is no connection, scan->attrib will be
NULL, because its reference is managed by attio connect/disconnect
callbacks. This means that on disconnect any resources owned by GAttrib
will be properly destroyed.
|