Closed GrantMTG closed 2 years ago
Curiously the data stage is already handled before
static usbd_respond cdc_control(usbd_device *dev, usbd_ctlreq *req, usbd_rqc_callback *callback)
is even called! I did not expect that. So, my code is much simpler even:
if((req->bmRequestType & (USB_REQ_TYPE|USB_REQ_RECIPIENT)) == (USB_REQ_CLASS|USB_REQ_INTERFACE))
{
switch(req->bRequest)
{
case USB_HID_SETREPORT: // 0x09
ReportType = req->wValue >> 8; // 2=Output report, 3=Feature report
ReportID = req->wValue &0xFF;
// ToDo: check the above two values first...
HidKbLEDs = ((uint8_t *)dev->status.data_ptr)[0];
return usbd_ack;
Let me know if this is indeed correct.
Hi
Yes, that's correct.
This is a standard feature of HID Keyboards, they receive the LED information (Caps Lock, etc) via a SETUP then a one-byte EP0 OUT data packet. The setup looks normally like this:
21 09 00 02 00 00 01 00
I can set the usbd_process_eprx() function to receive the data (1 byte) using the following, but I don't know the correct way to direct that byte to my own buffer. Alternatively I would need notification or a callback to get it out of the default(?) one. This code currently resides in cdc_control() in the demo and is similar to https://github.com/dmitrystu/libusb_stm32/issues/32#issuecomment-453434318.
How can I get the data and/or be notified that is has been received?