This fixes the following build error:
profiles/input/manager.c:102:4: error: implicit declaration of function ‘free’ [-Werror=implicit-function-declaration]
102 | free(uhid_enabled);
| ^~~~
The parameters of bt_uhid_get_report_reply are number followed by
status, not status followed by number, so the order needs to be
swapped.
Fixes: https://github.com/bluez/bluez/issues/880
This adds special handling for non-keyboards so they are destroyed when
disconnected rather than keeping their device node around.
Fixes: https://github.com/bluez/bluez/issues/848
When uhid is in use IdleTimeout was not taking any effect, this also
attempt to force the destroy the input device node to make it useful
for users that don't want to keep the input node forever.
If we cannot sent a message back to the device destroy the UHID device
since it is likely that the driver is trying to reach the remote device
which is no longer connected.
This makes bt_hog_detach not to destroy UHID device which means the
device node don't need to be recreated in case of reconnections which
speeds up the process.
Fixes: https://github.com/bluez/bluez/issues/737
The file has been used for about 8 years now - see commit
fb55b7a6ab ("profiles/hog: Use no suspend
support instead of the dummy FIFO").
Inspired by a Debian patch by Nobuhiro Iwamatsu, which was changing the
/tmp/hogsuspend socket patch to /run. Looking through the codebase we
have a few more sockets that could use a to /run fix, but that will
follow-up at another day.
Cc: Nobuhiro Iwamatsu <iwamatsu@debian.org>
This changes the default of ClassicBondedOnly since defaulting to false
is not inline with HID specification which mandates the of Security Mode
4:
BLUETOOTH SPECIFICATION Page 84 of 123
Human Interface Device (HID) Profile:
5.4.3.4.2 Security Modes
Bluetooth HID Hosts shall use Security Mode 4 when interoperating with
Bluetooth HID devices that are compliant to the Bluetooth Core
Specification v2.1+EDR[6].
Due to changes introduced by 67a26abe53
("profile: Add probe_on_discover flag") profiles may get probed when
their profile UUID are discovered, rather than resolved, which means
the SDP record may not be available.
Fixes: https://github.com/bluez/bluez/issues/614
This is a temporary fix for not handling BT_ATT_OP_HANDLE_NFY_MULT in
GAttr so the code will use g_attrib_attach_client to attach the
bt_gatt_client instance which is then used to register notifications
including those sent with BT_ATT_OP_HANDLE_NFY_MULT.
Fixes: https://github.com/bluez/bluez/issues/71
This fixes the following errors:
profiles/input/hog-lib.c:600:19: warning: Access to field 'handle'
results in a dereference of a null pointer (loaded from variable 'chr')
report->handle = chr->handle;
^~~~~~~~~~~
profiles/input/hog-lib.c:637:11: warning: Access to field 'value_handle'
results in a dereference of a null pointer (loaded from variable 'chr')
start = chr->value_handle + 1;
^~~~~~~~~~~~~~~~~
profiles/input/hog-lib.c:1240:11: warning: Access to field 'value_handle'
results in a dereference of a null pointer (loaded from variable 'chr')
start = chr->value_handle + 1;
^~~~~~~~~~~~~~~~~
Although HIDS spec is quite clear the Report MAP shall be limited to
512 bytes it doesn't seem OS do enforce that on the profile/client side
and since there isn't any qualification test enforcing it either there
are quite many devices which uses Report MAP bigger that 512 bytes
(e.g.: Brydge W-Touch and Lenovo Duet 3 BT Folio).
https://github.com/bluez/bluez/issues/377
On some rare occasions, the peer HID device might disconnect the ctrl
channel when we are trying to connect the intr channel. If this
happens, interrupt_connect_cb() will not be called by btio, and we
will be stuck in "connecting" state. Any future connection attempt to
the peer device will fail because of "busy".
This patch prevents that by checking if we need to report connection
failure when the ctrl channel is disconnected.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
If there is multiple instances the gatt_db of the instances was not
initialized causing the report_map_attr to be NULL which prevents the
report_map to be read and uhid device to be created.
Fixes: https://github.com/bluez/bluez/issues/298
Before prepending the Report ID check if it is non-zero:
BLUETOOTH SPECIFICATION Page 16 of 26
HID Service Specification
Report ID shall be nonzero in a Report Reference characteristic
descriptor where there is more than one instance of the Report
characteristic for any given Report Type.
Fixes: https://www.spinics.net/lists/linux-bluetooth/msg97262.html
With use of UHID_CREATE2 the code needs to wait for UHID_START in order
to know if the reports are numbered or not.
Fixes: https://github.com/bluez/bluez/issues/298
When the GError variable is freeed with g_error_free(), it is not set to
NULL and reusing the same variable again can cause the seg_fault because
it is still pointing the old memory address which is freed.
This patch relaces the g_error_free() to g_clear_error() which frees the
variable and set it to NULL if the variable is used in the function
again.
Fixes: 4ad622d592 ("profiles/a2dp: Fix unchecked return value")
This convert the use of UHID_CREATE to UHID_CREATE2 which gives back
the information of reports being numbered or not thus avoiding the need
to parse the report map in order to check if there are a report number
on them since UHID_START gives that information:
UHID_START:
This is sent when the HID device is started. Consider this as an
answer to UHID_CREATE2. This is always the first event that is sent.
Note that this event might not be available immediately after
write(UHID_CREATE2) returns.
Device drivers might require delayed setups.
This event contains a payload of type uhid_start_req. The "dev_flags"
field describes special behaviors of a device. The following flags
are defined:
- UHID_DEV_NUMBERED_FEATURE_REPORTS
- UHID_DEV_NUMBERED_OUTPUT_REPORTS
- UHID_DEV_NUMBERED_INPUT_REPORTS
Each of these flags defines whether a given report-type uses numbered
reports. If numbered reports are used for a type, all messages from
the kernel already have the report-number as prefix. Otherwise, no
prefix is added by the kernel. For messages sent by user-space to the
kernel, you must adjust the prefixes according to these flags
Since report map is only read after all reports it is possible to start
receiving notifications before uhid has been created, so this adds a
queue to store the events while the report map is pending and once uhid
has been created dequeue the events.
The Report Map must be read after all other attributes otherwise the
Kernel driver may start using UHID_SET_REPORT which requires the
report->id to be known in order to resolve the attribute to send to.
Fixes: https://github.com/bluez/bluez/issues/220
This replaces the uses of g_memdup with util_memdup since the former has
been deprecated:
warning: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead
[-Wdeprecated-declarations]
g_memdup2 requires bumping glib version which would likely have its
own problems thus why util_memdup was introduced.
Currently we silently ignore missing connection (attrib) in read_char(),
but not in the other GATT interfaces (such as write_char, discover_desc,
etc). The code should avoid calling read_char() when there is no active
connection instead, and logging errors will help us trace the offenders.
We need to have active connection to fully discover a HOG instance,
and in the chain
bt_hog_new()->
gatt_db_foreach_service()->
foreach_hog_service()->
hog_attach_instance()
we have not set up hog->attrib yet. So let's skip calling
foreach_hog_chrc() from hog_attach_instance(), especially since
we will be calling bt_hog_attach() pretty much immediately after
bt_hog_new(), and we will be discovering characteristics there anyway.
When calling gatt_write_char(), gatt_read_char(), etc, id == 0 indicates
error. Let's recognize this fact and log it instead of queueing request
that will never be completed.
If UHID_GET_REPORT is received but a report cannot be found, etc, the
would pass bt_hog as user_data instead of report to get_report_cb
leading to a crash.
Fixes https://github.com/bluez/bluez/issues/112
When cable pairing a PS3 clone device, we should try and keep the USB device
name to create a new btd_device so that the joypad is named after its USB name
when connecting through Bluetooth.
If that isn't done, "Shanwan" clone joypads are named like the genuine joypads, and
kernel Bluetooth quirks aren't applied.
gh-issue: https://github.com/bluez/bluez/issues/46
In commit 23b69ab3e4 ("input/hog: Cache the HID report map"), we
optimized HOG reconnection by registering report value callbacks early,
but there was a bug where we also re-register the same report value
callbacks after at CCC write callback. We should handle this case by
avoiding the second callback register if we know we have done it
earlier.
To optimize BLE HID devices reconnection response, we can cache the
report map so that the subsequent reconnections do not need round trip
time to read the report map.
This reverts commit d6cafa1f0c.
In commit d6cafa1f0c ("input/hog: Remove HID device after HoG device
disconnects"), the bt_hog structure is destroyed in order to fix a bug
where the UHID connection is not destroyed. This fix has the cost of
increasing reconnection time because every reconnection would need to
re-read the report map again. An improvement to this fix is, instead of
removing the bt_hog structure, we can just destroy the UHID with
UHID_DESTROY event and use the existing bt_hog structure to keep the
cache of the report map to avoid re-reading the report map at
reconnection.
If the HID subsystem requests a HID report to be read from the
device, we currently incorrectly strip off the first byte of the
response, if the device has report IDs set in the HID report
descriptor.
This is incorrect; unlike USB HID, the report ID is *not* included
in the HOG profile's HID reports, and instead exists out of band
in a descriptor on the report's bluetooth characteristic in the
device.
In this patch, we remove the erroneous stripping of the first
byte of the report, and (if report IDs are enabled) prepend the
report ID to the front of the result. This makes the HID report
returned indentical in format to that of a USB HID report, so
that the upper HID drivers can consume HOG device reports in the
same way as USB.
When destroying UHID, we should also unregister all event listeners so
that they don't get double registered at reconnection. It fixes a bug
where battery report is not available to kernel after reconnection and
also prevents memory leak.
Tested with Logitech M535 mouse:
* Connect mouse to the device running BlueZ
* cat /sys/class/power_supply/hid-{addr}-battery/capacity # works
* Disconnect mouse
* Reconnect mouse
* cat /sys/class/power_supply/hid-{addr}-battery/capacity # still works
