This is now hopefully fixed by https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=0ed8a186eaff7c8e1eef8e3a5f03671920f66d58 On 10.07.19 20:01, Roderick Colenbrander wrote: > Hi Fabian, > > I would like to reply just in relation to the "Bluetooth path" as I'm > not sure what the intended behaviour is for the "write" call is. > > The Bluetooth path taken depends upon the userspace Bluetooth stack > you use. Various Bluetooth stacks use "uhid" though some may take hidp > as well or may even support both. I hope this helps you with your > quest. I recall at least BlueZ supports uhid and Android uses it as > well. > > Thanks, > Roderick > > On Tue, Jul 9, 2019 at 3:32 AM Fabian Henneke <fabian.henneke@xxxxxxxxx> wrote: >> >> Hi, >> >> when testing hidraw's hid-example.c >> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/hidraw/hid-example.c) >> with a Bluetooth HID device, I noticed that the write() call always >> returns 0 on success, even though the entire buffer has been written and >> received by the device. >> Following the chain of calls triggered by the call to write(), I >> identified hidp_send_message in /net/bluetooth/hidp/core.c:98 >> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/bluetooth/hidp/core.c#n98) >> as the plausible origin of the return value. This function always >> returns 0 on success, regardless of the value of its parameter size. >> >> Could you confirm whether this function is really the one used to handle >> writes to Bluetooth HID devices? If so, is it intended behavior to have >> write() return the number of bytes written for USB HID devices, but not >> for Bluetooth HID devices?
