Hello all, On Mon, Mar 26, 2012 at 5:20 PM, David Herrmann <dh.herrmann@xxxxxxxxxxxxxx> wrote: > Hi > > This is the second revision of the UHID driver. It basically allows to register > hid_ll_drivers in user-space. This is needed to implement Bluetooth HoG (HID > over GATT) as discussed earlier. > We have a first prototype implementation of the HoG plugin working with the uhid driver \o/ I'll send a RFC to the linux-bluetooth mailing list later, but I think it's nice to give some feedback on the uhid module here as well. The only problem I've encountered while testing it was that it doesn't seem to work if I set the 'bus' field on the struct uhid_create_req to BUS_BLUETOOTH. Initially I thought this was just metadata, but changing it to BUS_USB makes it work. Additionally, I don't know if you forgot or did it on purpose, but you didn't add the uhid example to samples/Kconfig and sample/Makefile. > Changes: > - Improved documentation > - Added example which emulates a 3-button mouse with wheel in user-space I've (partially) tested the example, on a X-less virtual machine. I'll try it on a box with X so I can attach the virtual mouse to a pointer in X and see the cursor moving. > - Fixed some remaining bugs > > I didn't change any major parts. I checked that writev/readv work correctly and > I documented how to use it in ./Documentation/hid/uhid.txt. > > For a full example please see ./samples/uhid/uhid-example.c. > > While developing it I also considered moving HIDP to user-space. If we do BT-HoG > in user-space, it should be easier to also move HIDP to user-space. The current > in-kernel HIDP is buggy, anyway. > > Still open points: > - How do I get a proper "parent" pointer for uhid->hid->dev.parent? I could use > the uhid misc device as parent or is there some device-struct inside "struct > file"? > - Should user-space be able to provide "uniq" and "phys" names for HID-devices? > - uhid_event is quite big (>4KB) which makes uhid_device really big (~70KB). > Should I allocate the ring-buffer dynamically to avoid this? > - Should I provide the quirks field to user-space? Probably as part of > UHID_START? > - Could someone review x32 COMPAT stuff? I tried to align all the public > structures correctly so I could even remove the __packed attribute. Anyway, I > thought keeping it is probably better for future extensions. > > I spent some time on the locks and they seem all fine. I couldn't find any > races. > > Jiri, Marcel, could you review the design and tell me what you think? > > A short notice about the protocol: > User-space is allowed to send only as much data as is needed for the event. That > is, when sending the UHID_DESTROY event (which has no payload) it would be > actually enough to only send a __u32 field (ev->type) with write(). > This is not to speed up the write()s or read()s but rather to allow extending > the uhid_event structure in the future. We can actually add arbitrary extra > event-types and still keep ABI compatibility. Therefore, I thought of adding an > "uhid_version" field to UHID_CREATE so user-space can define what UHID protocol > it is using. > > Regards > David > > David Herrmann (1): > HID: User-space I/O driver support for HID subsystem > > Documentation/hid/uhid.txt | 152 ++++++++++++++ > drivers/hid/Kconfig | 21 ++ > drivers/hid/Makefile | 2 +- > drivers/hid/uhid.c | 473 +++++++++++++++++++++++++++++++++++++++++++ > include/linux/Kbuild | 1 + > include/linux/uhid.h | 84 ++++++++ > samples/uhid/Makefile | 10 + > samples/uhid/uhid-example.c | 381 ++++++++++++++++++++++++++++++++++ > 8 files changed, 1123 insertions(+), 1 deletion(-) > create mode 100644 Documentation/hid/uhid.txt > create mode 100644 drivers/hid/uhid.c > create mode 100644 include/linux/uhid.h > create mode 100644 samples/uhid/Makefile > create mode 100644 samples/uhid/uhid-example.c > > -- > 1.7.9.4 > -- João Paulo Rechi Vita Openbossa Labs - INdT -- 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
