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.
open()/read() is more common on BlueZ code. Incidentally, get rid of
this compilation error (using gcc 4.6.3):
plugins/autopair.c: In function ‘autopair_init’:
plugins/autopair.c:154:8: error: ignoring return value of ‘fread’,
declared with attribute warn_unused_result [-Werror=unused-result]
This patch makes the autopair plugin try a fixed "0000" pincode for
keyboards that reject the pincode too fast (less than 500ms). This too
short delay rejecting the pincode means that the user didn't have time
to type the random pincode in the bluetooth keyboard and was the
keyboard who actually rejected it.
The autopair plugin tries standard pincodes for different devices with
dumb pincodes. It also generates a random 6 digit pincode for keyboards
that support any pincode but fallbacks to the agent call in case the
random generated pincode didn't work.
The plugin's pin code callback doesn't know about the pairing process.
It just provides a pin code based on the information provided to this
function. Although limited state could be added through other new
callbacks, this fix achieves this by providing more information to the
callback itself. The new argument "attempt" states the pin callback
attempt of the particular plugin for the current pairing of the device.
This allows a plugin to try different pincodes for the same device in
the same pairing process.
To signal that the plugin doesn't provide any pin code for the provided
device the current implementation returns 0 (an empty pin code).
Analogously, with this fix, a plugin should return 0 when it doesn't
have any other pin code to provide for the given device.
Message might not contain State field and CPS needs to be set to
unknown before processing message from neard. This fix processing
RequestOOB called without parameters.
Devices with private addresses cannot persistently be identified by
their address. Therefore it doesn't make sense to store any information
about them as the information couldn't be looked up later once the
remote address has changed.
Once the kernel receives support for private address resolution we'll
start getting the public address of such devices to user space. However,
until then we just have to ignore such devices from a storage
perspective.
If pretty hostname is not set fallback to static hostname (if it is
set). If static or pretty hostname is not set appropriate properties
are empty strings not NULLs. This behaviour is recomended by hostnamed.
