-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend Usb recv control + some HID definitions #4105
Conversation
7219e3e
to
9b66f5d
Compare
Hyperion patch released and merged: Please consider to merge this PR or give me feedback if you reject it. We can also add it as 2nd function for long control EP reads. However people are not able to test the latest dev again. |
Could anyone please have a look at this? |
I had a look at this PR, looks ok to me. I commented one nitpick about the looping used, but that's not very important. I can't comment on to what degree the first commit actually works with the USB hardware, since I'm not familiar with that part, but it looks reasonable to me (and I expect @NicoHood has tested it). |
Hi Nico, |
I need the Control endpoints, there is no other way. However we could make it a different function like "USB_RecvControlLong()" ore something like that. Then we dont need to add an overhead to the main API. However it adds even more if someone uses my function, so we have a duplication here.
I dont understand your question. You need to add an offset to the array to write to every position. First you write to the first position (len(aka transmit length) - length(aka bytes left) = 0) then to the next position (len - length(x bytes left) = 64). This results in:
Maybe the function can be improved, but the USB API itself is not flexible enough for this. Maybe we should adapt the Lufa core functions and build ontop of this. This makes the usb core more stable, still flexible and it has a good documentation. For now I just need a decision about this. Please merge the first commit and tell me if you want to merge the 2nd or not. If not I can make a different named function or simply add it into my library as special patch (which isnt that ultra nice, but would work for now.) |
Hi Nico, I'm still curious about where you would need to use that patch; if the case is to revive this code (from HID library) if (request == HID_SET_REPORT)
{
//uint8_t reportID = setup.wValueL;
//uint16_t length = setup.wLength;
//uint8_t data[length];
// Make sure to not read more data than USB_EP_SIZE.
// You can read multiple times through a loop.
// The first byte (may!) contain the reportID on a multreport.
//USB_RecvControl(data, length);
} you can perform the loop externally. The only live code which uses that function is CDC and receives 7 bytes so your use-case is too narrow for the overall overhead, sorry. Anyway, I'm merging the first one immediately |
9b66f5d applied |
Thanks! However I could add this as internal function myself to the lib. Or as suggested as different named function. I should rename the variables though. What about adding a 2nd function for long controlRecv calls? What name do you suggest? |
Hi Nico, |
Sure, just let me know. Also I asked cmagile and ffisore via mail if i can get access to trigger the arduino bot. I always have to ask matthijs on irc for it. Also not all arduino members provide a PGP mail key which is really bad. I do not send unencrypted mails. Closing this PR, will add a wrapper to my program. |
In order to implement some fancy feature/out requests/reports I need to read more than 64 bytes from the control pipe. I could work around this to implement this in my own library, but since this was marked as TODO why not add it? There is still no timeout in the function, expecting the user is knowing what he is doing.
The HID definitions are required to differentiate between those 3 types.
FYI:
You can abuse a Keyboard this way under linux, that it works almost like a raw hid device, just passive. Meaning you can send data from the PC and request data. You just cannot active send data. not idea about windows though. With consumer keys in the reserved byte and bios compatibility the Keyboard gets REALLY powerful now. Just different keylayouts are missing yet.
NicoHood/HID@a8c292a
NicoHood/HID@0487754
(Hyperion patch is not published yet, but it doesnt require much. You can use this as quick and reliable ambilight!)
However we should really consider to renew the USB Core API this time. If you really want to use some basic functions, they are a) not visible via .h file, only via .cpp file or b) not useful/unclear. Any chance to see some updates here?
@cmaglie @facchinm