| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
device.trusted is a user preference which controls if the devices needs
to be authorized or not so the plugin shall not overwrite it and instead
just honor what user has set and skip authorizing if already trusted.
Fixes: https://github.com/bluez/bluez/issues/372
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While performing static tool analysis using coverity
found following reports for resouse leak
bluez-5.64/plugins/sixaxis.c:425: alloc_arg:
"get_pairing_type_for_device" allocates memory that is
stored into "sysfs_path".
bluez-5.64/plugins/sixaxis.c:428: leaked_storage: Variable "sysfs_path"
going out of scope leaks the storage it points to.
|
| |
|
|
|
|
|
| |
BT core spec 5.3 promotes the usage of inclusive languages.
This CL uses "central" as it is deemed to be more appropriate.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds SPDX License Identifier and removes the license text.
-------------------------------------
License COUNT
-------------------------------------
GPL-2.0-or-later : 7
License: GPL-2.0-or-later
plugins/autopair.c
plugins/hostname.c
plugins/neard.c
plugins/policy.c
plugins/sixaxis.c
plugins/wiimote.c
plugins/external-dummy.c
|
| |
|
|
| |
This adds a NULL check before calling sscanf().
|
| |
|
|
|
| |
If btd_request_authorization_cable_configured() fails, throw an error
and free resources.
|
| |
|
|
|
|
|
| |
If the device went through any kind of pairing once, it might have been
set as trusted. Make sure to set the device as untrusted before starting
the cable pairing authorization so that we don't exit early from
process_auth_queue() (which considers trusted devices to be paired).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Setup PS3 controller through cable pairing
2. Remove device from BlueZ's database
3. Plug original PS3 controller back
As we don't change the master bdaddr on the device itself, the joypad
will likely be trying to connect to BlueZ, and fail to connect after a
small period of time. But the device will appear connected just long
enough for the cable pairing to say "hey, I already have this setup".
Ideally, we would test for whether the device is temporary, or already
trusted, but testing for whether we've setup its internal services *and*
it's connected, rather than *or*, is sufficient.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows to skip SDP search for DualShock 3 devices, since some
DS3 clones do not provide any SDP record. This allows them to operate
nonetheless.
The HID SDP record is lifted straight off an original DualShock 3
controller. The PNPID SDP record is not set as not required to provide
a working device.
Tested with a "SHANWAN" clone controller.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following problems:
plugins/sixaxis.c:443:7: error: ‘version’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!setup_device(fd, sysfs_path, name, source, vid, pid, version, type, adapter))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugins/sixaxis.c:409:34: note: ‘version’ was declared here
uint16_t bus, vid, pid, source, version;
^~~~~~~
plugins/sixaxis.c:443:7: error: ‘source’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!setup_device(fd, sysfs_path, name, source, vid, pid, version, type, adapter))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugins/sixaxis.c:409:26: note: ‘source’ was declared here
uint16_t bus, vid, pid, source, version;
^~~~~~
cc1: all warnings being treated as errors
And many instances of code going over 80 columns.
|
| |
|
|
|
| |
Cancel pending authorization requests when the device is unplugged
while a request is pending.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for "pairing" a Dualshock4 controller over USB
into the sixaxis plugin, similarly to what the Sixaxis/PS3 controller
supported.
Actual bonding happens on first connection, but the device will be
marked as trusted when the agent replies.
This patch is based on DS4 supprt for sixpair tool by t0xicCode:
https://github.com/t0xicCode/sixpair/commit/975c38cb6cd61a2f0be350714f0f64cef5f0432c
|
| |
|
|
| |
And provide wrappers to prepare for the addition of other device types.
|
| |
|
|
|
|
|
|
|
| |
Move the struct containing the Sixaxis-compatible devices to a
header shared with the input profiles code, so as to reduce device
declaration.
Adding support for new devices should be as easy as adding the device's
declaration in profiles/input/sixaxis.h
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, users doing cable configuration of Sixaxis PS3 controllers
would only get asked whether a device was allowed to connect to the
computer when switching it to Bluetooth mode: unplugging it, and
pressing the PS button.
Instead, we should ask the user straight away, through the agent,
whether the pad should be allowed to connect.
This makes it easier to setup those devices, while keeping security.
|
| |
|
|
|
| |
It's done in the kernel since 2014 in linux kernel commit
8025087acf9d2b941bae93b3e0967560e7e03e87
|
| |
|
|
|
|
|
| |
Some games check the device name to recognize a playstation controller.
This changes the device name, when using a PS3 controller over
bluetooth, to match the device name, that is advertised when using the
controller via USB.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 also in preparation of set_leds_sysfs().
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This is necessary to do accurate matching for LE devices.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
If controller is already connected over Bluetooth but was then
plugged-in via USB (eg. to charge battery) there is no need to do
any setup.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
When new device is added plugin will be notified about it.
|
|
|
This plugin will be used to associate PS3 controllers.
|
