Hello, > -----Original Message----- > From: David Herrmann [mailto:dh.herrmann@xxxxxxxxx] > Sent: 05 August 2014 14:26 > To: Aravind Parvathala > Cc: Luiz Augusto von Dentz; Murat Kilivan; linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: Re: HoG: Support multi output report > > Hi > > >> > Ok, I now took the time to read through the HoG specs. It says: > >> > > >> > "For data transferred to HID Device from Report Host, > >> > Report ID is removed from data received from a > >> > USB HID Class driver before being transmitted to the > >> > HID Device (usually a write command to a Report > >> > characteristic value or as a write request to a > >> > Report characteristic value for HID Service data)." > >> > > >> > Each UHID_OUTPUT message received by BlueZ contains the report-ID > >> > as 1-byte prefix of the message. Therefore, you're supposed to > >> > strip it from the message and forward it to the right target. > >> > > >> > I have no idea how GATT works, but I assume you write to an > >> > attribute that is named after the report-ID of the output report. > >> > So you parse this 1-byte prefix, select the correct attribute based > >> > on this information and then send the message (without the 1-byte > >> > prefix) to the selected attribute. > > > > For each report (note that it is not for each report ID, because you could > have an input, an output as well as a feature report all of which are using the > same report ID), there is a corresponding characteristic which is discoverable. > The report map indicates which are all the report IDs and the corresponding > type (purpose). As shown by Murat, the debug logs show that all those > report IDs were discovered from the report map. > > > > Each dedicated characteristic for each of the reports, carry a "Report > Reference characteristic descriptor" which specifies the report ID and report > type associated with that characteristic. Hence I would imagine the blue-z > driver would need to keep the mapping of report ID/Type Vs the > Characteristic handle. > > > > For an output report, the driver would direct the contents of the report > over the corresponding handle as "Write request". This data will not have > (and does not need to have) the report ID as the BLE device already knows > which report ID is associated with the characteristic handle. > > > > For an input report, it’s the same except that the BLE device will issue a > write request to the Blue-z host on the corresponding handle. Again the > payload will not have any report ID, because the Blue-z host is expected to > be able to map the payload of the originating characteristic handle to the > corresponding input report ID. > > > > Same is applicable to the feature report as well but in this case , I imagine it > is a read/write request-response type of exchange as you would > reading/writing static configuration data rather. > > > > > > So it is not really a Characteristic attribute named after the report-ID, but > mapped to a report ID. As stated earlier, the associated " Report Reference > characteristic descriptor " holds the information which is key to translate > from the BLE data to the HID data and vice-versa. > > Yes, this was really helpful, thanks! The BlueZ code looks almost right, except > for the code that maps UHID_OUTPUT events from the kernel to the correct > attribute. It currently only uses the type information. I will send a patch to fix > this. Excellent thanks, that makes sense. If it is only using the type information it would probably be expecting that a given HID raw device will ever have only a single report of a given type. While this might be the majority case, HID doesn't impose such restrictions. So your patch would be quite useful. I don't know if Murat (or anyone) mentioned this, but apparently it was implemented correctly on the Android hosts (I believe 4.4.x). I was told that's a variant of Blue-z called Bluedroid, but that could be a reference if there is any further confusions on what might be the right thing to do. Cheers, Aravind Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
