Hi On Tue, Jan 21, 2014 at 3:00 AM, <simon@xxxxxxxxxxxxx> wrote: >> This adds a special case in the HIDP core for the Dualshock 4 > controller. >> The controller only recognizes output reports with the report type 0x52 > and only accepts reports sent via the ctrl channel. > > Which part of the system is 'at fault' here, is it simply the DS4 behaving > incorrectly or that Bluez is not picking up some data or that 'we' are > just the incorrect method to send the data (in the hid-sony kernel > driver)? No-one is at fault. Well, strictly speaking the DS4 is, as it has to accept SET_REPORT and asynchronous OUTPUT_REPORTs, but it doesn't. That's quite common. What we actually want is HIDP to provide to functions, one to call SET_REPORT and one to do the async OUTPUT_REPORT is currently does. I implemented this some time ago here: http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=hid Maybe it's time to get that merged. But that hack here is ugly and not the way to go. Thanks David > > I noticed that the BT HID spec notes a 'HID control' channel in the > example descriptor in table 5.3.3 as 'Parameter 0'. > > The DS4 gives this in it's SDP report > -- > Attribute 0x0004 - ProtocolDescriptorList > Sequence > Sequence > UUID16 0x0100 - L2CAP > UINT16 0x0011 <---------- 'HDI Control' PSM 17 > Sequence > UUID16 0x0011 - HIDP > -- > > Shouldn't Bluez be remembering this and sending accesses to this PSM in > the appropriate mode? > > Just looking to fix the problem where it really exists, without just > working around specifically for the DS4. > > Simon > > -- 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
