This examples can be done over D-Bus already so it makes no sense to have
it as a plugin and in fact it currently it doesn't even work since it was
never ported to the new code under src/shared.
If the link is disconnected before any profile connects it shall still
reset the attempts as the device actually has been connected, otherwise
the number of attempts may not be respected.
This option is used to configure policy for auto enabling adapters when
found. This includes adapters found on start as well as adapters that
are plugged in later on.
Some distributions use legacy "hciconfig hci0 up" in boot-scripts to
automatically enable controllers on start. But that is causing SMP
kernel code to not being properly initialized.
This patch allows distributions to automatically enable adapters in
race free manner even if no agent is provided eg. in login screen.
This patch fixes the following error when bluez is compiled with clang:
plugins/policy.c:780:6: error: cast from 'int *' to 'size_t *' (aka 'unsigned long *') increases required alignment from 4 to 8 [-Werror,-Wcast-align]
(size_t *) &reconnect_intervals_len,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If state of Control/Remote services changed from CONNECTING to
DISCONNECTED, and error is set to -EAGAIN, set random timer and try
reconnect. This approach is described in AVRCP Spec 1.5 4.1.1:
"If both devices open an AVCTP channel at the same time both channels
shall be closed and each device shall wait a random time
(not more than 1 s and not less than 100ms) and then try to open
the AVCTP channel again."
If service becomes unavailable, due to e.g. the device being removed,
all the related timers should be removed as well otherwise it may cause
crashes such as the following:
Invalid read of size 8
at 0x4A6597: btd_device_get_service (device.c:5335)
by 0x40F49F: policy_connect_ct (policy.c:112)
by 0x4E7F552: ??? (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x4E7EAEA: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x4E7EE87: ??? (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x4E7F1B1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x40BACF: main (main.c:631)
Address 0x73b9ba8 is 360 bytes inside a block of size 592 free'd
at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E847FE: g_free (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x49C83F: device_free (device.c:624)
by 0x4BDB29: remove_interface (object.c:658)
by 0x4BE701: g_dbus_unregister_interface (object.c:1382)
by 0x4A49DC: btd_device_unref (device.c:5173)
by 0x41DC46: avdtp_free (avdtp.c:1138)
by 0x41EE09: connection_lost (avdtp.c:1164)
by 0x422EA5: session_cb (avdtp.c:2263)
by 0x4E7EAEA: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x4E7EE87: ??? (in /usr/lib64/libglib-2.0.so.0.4200.1)
by 0x4E7F1B1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4200.1)
On recent kernels the hid-sony driver exposes leds class entries in
sysfs for setting the Sixaxis LEDs, use this interface and fall back to
hidraw in case using sysfs fails (e.g. on older hid-sony versions).
Setting the LEDs via sysfs is the preferred way on newer kernels, the
rationale behind that is:
1. the Sixaxis uses the same HID output report for setting both LEDs
and rumble effects;
2. hid-sony remembers the state of LEDs in order to preserve them when
setting rumble effects;
3. when the LEDs are set via hidraw hid-sony has no way to know the
new LEDs state and thus can change the LEDs in an inconsistent way
when setting rumble effects later.
Also require libudev >= 172, this is where
udev_enumerate_add_match_parent() has been first introduced.
NOTE: using udev_enumerate_add_match_parent() results in a memory leak
when enumerating child devices, this has been fixed in udev 207; the
commit which fixes the issue is this one:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=51cc07576e119dea6e65478eeba9472979fd0936
Get all the data necessary to set the LEDs in a single function,
returning a leds_data structure to be passed as argument to the
setup_leds() callback.
For now only a 'bitmap' field is used, which is the only thing that
set_leds_hidraw() needs.
Match hid devices and input devices using HID_UNIQ and UNIQ when these
are available, this is the correct way to get matching devices when the
controllers are connected via BT (UNIQ refers to the device bdaddr, PHYS
is the adapter bdaddr, so matching against PHYS will result in all
devices with the same LED number).
Fall back to HID_PHYS and PHYS when needed, hid devices do not define
HID_UNIQ when connected via USB.
This is in preparation for a set_leds_sysfs() function.
Make set_leds_hidraw() return void, as its return value is never used
by the caller: the setup_leds() callback has to always return FALSE.
In the case that the remote starts connecting to us while we're waiting
for the timeout to discover we shouldn't just reset the basic time
keeping variables but also remove the timer.
Properties are defined by GATT specification. This patch moves and
renames the defines related to Characteristic properties bits from
attrib/att.h to attrib/gatt.h
If /dev/urandom cannot be opened or read, just fail the plugin
initialization, as it is very unlikely that a fully working Linux system
does not have a working /dev/urandom. This also simplifies the code
logic.
For dual mode devices there are several state variables that are
independent for each bearer. This patch splits these states up into two
separate variable groups in btd_device and tracks the values based on
what kind of connection is in question.
The information is also used to select which bearer to use with
Device1.Connect and Device1.Pair. The basic rule is that the bearer
that's not connected/paired is selected, or then the bearer over which
the device was last seen is selected.
There were some valid conserns raised against marking plugged device
as trusted. Mainly due to posibility of crafted USB device. With this
patch user will be asked to confirm service connection and device can
be marked as trusted like any other devices.
After searching past the end of the structure, the loop sometimes
found matches in the daemon's address space...
This fixes the loop to end after the elements have been exhausted.
This allows to setup LEDs when device is connected over USB, not
Bluetooth. This coverts two scenarios:
- user plugged PS3 controller and pressed PS3 button before unplugging,
in that case LEDs are set
- user plugged already BT connected PS3 controller to USB, this results
in new /dev/input/jsX device being create but controller is still
transmitting over BT and old jsX device exists. In that case don't
set LEDs as they are already set.
This is not directly related to Bluetooth itself but change is really
small and provides much better and consistent user experience.
This will set controller LEDs according to joystick device number
when controller is connected over Bluetooth. If joystick number is too
big (> 7) or falied to be read, set it to 0 to switch off all LEDs.
This will allow to disable LEDs blinking after connection.
Waiting for events is not really needed when connected over Bluetooth
but this is in preparation for supporting LEDs setup over USB.
When new PS3 controller is detected provide it with default adapter
address. Also create new btd_device with proper PNP info if it wasn't
existing yet.
