Hello,
I've made a mouse using the HID descriptor of a typical mouse (3 buttons information + X/Y). This works fine with the AVR-USB stack just like it does with a keypad and HIDkeys.
I have now 2 requirements and as I'm new to USB, I don't really know what's possible :
- I would like to send/get 2 bytes of data to/from the mouse
- and if possible, I would like to send/get these 2 bytes using standard (HID) APIs from Windows, that means with just an user application and no driver instalation
These 2 bytes are for configuration purpose of the internal working of the mouse and doesn't have to do with the mouse HID report.
* Could this be done using a control IN/OUT on endpoint 0?
If yes can someone show me an usbFunctionSetup example with what needs to be tested in usbRequest_t to detect a control IN or OUT and return the correct value for usbFunctionWrite/Read to be called or not.
They are examples of HID or Control application with AVR-USB but not both at the same time. Can an user application send/receive these types of transferts with existing APIs (without drivers like libusb)?
* Could this be done ussing a set/get feature or some kind of vendor specific request?
In this case, does the HID mouse descriptor has to be updated and will it still be recognised as a mouse by Windows? Can AVR-USB manage this and how?
That's a lot of questions! Sorry for keeping things rather vague but I have difficulties with all this new USB language terms (report, descriptor, device.... )
regards
HID Mouse Configuration
You have two options:
(1) You use custom USB requests with libusb-win32. This requires an installation of libusb-win32, though.
(2) You use feature reports to transmit your data. In this case there's more than one type of report (the x/y/buttons report) and you will have to use report-IDs to distinguish the reports. This should be compatible with Windows drivers, but probably not with the boot protocol used by the BIOS. It may be possible to omit the report ID for the data report, but I'm not expert enough to comment on this.
On the USB level, feature reports are simple control-in and control-out transfers which are handled by the class driver. In the device, the class driver is in your usbFunctionSetup() and usbFunctionRead()/usbFunctionWrite(). On Windows, you use HidD_SetFeature() and HidD_GetFeature() to send or receive feature reports.
An example for using feature reports can be found in the avr-usb package in the examples subdirectory. See hid-data.
An example for using libusb-win32 calls on HIDs see the hid-custom-rq example.
(1) You use custom USB requests with libusb-win32. This requires an installation of libusb-win32, though.
(2) You use feature reports to transmit your data. In this case there's more than one type of report (the x/y/buttons report) and you will have to use report-IDs to distinguish the reports. This should be compatible with Windows drivers, but probably not with the boot protocol used by the BIOS. It may be possible to omit the report ID for the data report, but I'm not expert enough to comment on this.
On the USB level, feature reports are simple control-in and control-out transfers which are handled by the class driver. In the device, the class driver is in your usbFunctionSetup() and usbFunctionRead()/usbFunctionWrite(). On Windows, you use HidD_SetFeature() and HidD_GetFeature() to send or receive feature reports.
An example for using feature reports can be found in the avr-usb package in the examples subdirectory. See hid-data.
An example for using libusb-win32 calls on HIDs see the hid-custom-rq example.
I feel sorry I made you lost your time with my asking so many questions whose answers where in your AVR-USB package in your download page. Actually, I found your USB stack with google which dropped me on the projects page. I've, then, used the HID-Keys to write my own HID-mouse.
I wouldn't even have had to write it if I had run through your site more carefully and had downloaded the AVR-USB package with the mouse application already in it!
Well, at least, this might prevent someone else from doing the same mistake.
Anyway, I know have confirmation (in duplicate) that using feature reports on HID device is usable to send or get additional data for different purpose than the HID device function implemented itself (mouse, keyboard, etc.) and without driver installation still. I will see if Windows still recognize the mouse with the extra features in the report descriptor.
By the way, since my post I have found on the Atmel website that they were using a feature report too, on their AT90USBxxx chips, to enter the bootloader mode of their firmware.
Thanks for your quick and precise answer.
regards,
John D.
A little bit about the project :
It is not a problem if the mouse doesn't work in the BIOS. It is made to work in Windows only.
It's for a college school project for the son of a friend of mine.
It is dedicated to disabled people whose head is nearly the only moving part of their body left.
It uses one 2 axis accelerometer for the X/Y and 2 single axis accelerometers or software homemade capacitive sensors (both are usable at the same time) for the left/right clicks. The mouse works great but I wanted to add sensitivity and custom adjustments for the accelerometers (different from the Windows mouse cursor configuration panel). The sensitive sensors are regularly auto-adjusted by software to counter changes in the environment conditions.
I wouldn't even have had to write it if I had run through your site more carefully and had downloaded the AVR-USB package with the mouse application already in it!
Well, at least, this might prevent someone else from doing the same mistake.
Anyway, I know have confirmation (in duplicate) that using feature reports on HID device is usable to send or get additional data for different purpose than the HID device function implemented itself (mouse, keyboard, etc.) and without driver installation still. I will see if Windows still recognize the mouse with the extra features in the report descriptor.
By the way, since my post I have found on the Atmel website that they were using a feature report too, on their AT90USBxxx chips, to enter the bootloader mode of their firmware.
Thanks for your quick and precise answer.
regards,
John D.
A little bit about the project :
It is not a problem if the mouse doesn't work in the BIOS. It is made to work in Windows only.
It's for a college school project for the son of a friend of mine.
It is dedicated to disabled people whose head is nearly the only moving part of their body left.
It uses one 2 axis accelerometer for the X/Y and 2 single axis accelerometers or software homemade capacitive sensors (both are usable at the same time) for the left/right clicks. The mouse works great but I wanted to add sensitivity and custom adjustments for the accelerometers (different from the Windows mouse cursor configuration panel). The sensitive sensors are regularly auto-adjusted by software to counter changes in the environment conditions.