On 1/18/2014 10:13, Szymon Janc wrote:
Hi,
On Saturday 18 January 2014 16:05:26 David Herrmann wrote:
Hi
@Simon and Frank:
This patch might help fix your DS4 issues.
Cheers
David
Just for clarification, this does not add DS4 support, just detection for it
in input server. There is some problem with getting SDP records from DS4 by
bluetoothd (works with sdptool) which prevents idev from being created.
I'm working on fixing this, but no ETA yet.
With this and the IMTU patch I was able to get my controller paired. I
played around with it and from watching the traffic in btmon, there are
still two issues that are stopping full two way communications:
1. The Dualshock 4 sends communications to the host on PSM 19, but will
only receive packets on PSM 17. Currently the bluetooth stack is trying
to send data to the controller on PSM 19 so the data packets still
aren't reaching the it.
2. The hidp layer always assigns a report type of 0xA2 (HIDP_TRANS_DATA
| HIDP_DATA_RTYPE_OUTPUT) to every HIDP_OUTPUT_REPORT. The Dualshock 4
only accepts reports with type 0x52 (HIDP_TRANS_SEND_REPORT |
HIDP_DATA_RTYPE_OUTPUT). I was able to work around this with a kludge
in net/bluetooth/hidp/core.c to catch the Dualshock 4 packets and use
the value that the controller wants, but I don't think anyone wants a
device-specific hack in a core protocol file. Unfortunately, there
seems to be no elegant way to work around this.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
