-
-
Notifications
You must be signed in to change notification settings - Fork 38.9k
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
[Feature Request] USB feature report handling #23243
Comments
Hi @george-norton 👋,
Cool! I see that you have pushed your implementation to https://github.com/george-norton/qmk_firmware/tree/multitouch_experiment. So I'll base my suggestions on that branch.
We can just go with the example certification report - like you already implemented.
Sure, happy to give some feedback. The For the capabilities and certification feature the default When constructing your IN endpoint in Make sure to increase the
The
Sure, you can just add a function pointer (maybe rename the existing At this point I would say that
That would be great - I personally neither use Windows nor MacOS on a daily basis.
Looking forward to it :) |
Hello @KarlK90,
|
I assume there is a good reason the |
@george-norton just a short heads up. I'm currently on vacation for the next two weeks and will reply in detail after that. I've started to implement a more flexible API for the get report functions that allows for dynamically sized reports in https://github.com/KarlK90/qmk_firmware/tree/feature%2Fusb-report-handling branch. It currently crashes with a null pointer dereference and I haven't figured out why yet... |
Thanks for taking a look at this! Have a great holiday, don't read the rest of this until you are back! I have reproduced your crash with a onekey. Seems to run OK until I enable the console - then it crashes after printing the first message. Not quite sure what is going on at this point. Here is what I see:
The typeinfo suggest we are somewhere in
Here is the
So |
One problematic place is |
I have fixed the issue sigprof found, but there is another crash. This appears to have been introduced by commit |
@sigprof Thanks for the catch @george-norton I've had a look at my code an found some more bugs, with these fixed the onekey enumerates and works correctly again. The code now lives in this draft PR: #23388, removing the |
Hope you had a nice vacation. I just ran a quick test and, it seems to be working well. I see the scan rate reported over the console and messages about the led_task when I toggle the caps lock. |
Hello, I have started looking at what would need to change to support SET REPORT requests. I believe that SET and GET report calls are not symmetric? For example, the keyboard endpoint defines an input report that reports modifiers and keycodes and an output report that reports the LED state. So GET/SET requests on a particular endpoint should not be working with the same report? I haven't yet looked into the idle stuff, but I suspect the current usb_report_t structure will either need extending, or we will need two per endpoint. |
I guess SET_REPORT messages don't need to end up in the store as they will.be updating some state in some QMK feature, so they probably all need to be handled individually? |
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. |
This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know. |
Feature Request Type
Description
I have been doing some work to support trackpads within the digitizer feature. To do this I have had to implement support for a few Get/Set Feature reports. In particular:
Microsoft require 2 Get Report features:
The certification report is a pain as its 257 bytes, but Windows 8.1 wont work without a valid response. Later versions of Windows require us to return something, but they don't validate it.
We also need to support the following Set Report features:
I currently have some hacked together report handling code which works, but I would like to make it nicer. I have seen that @KarlK90 has just redesigned all the report handling code, and I was wondering how I can best take advantage of it. The Get Report values are known at compile time, so I was wondering about populating them in the report storage structure as complete reports at compile time, but the buffer (64 bytes) isn't big enough for the certification report. The set report handling doesn't appear to be in place, but perhaps the code could be extended a little?
It may also be nice if the actual content of these descriptors is platform independent, although the certification report will never fit on an AVR, we could at least support multitouch on Linux and fall back to mouse reporting on Mac (Apple do not support 3rd party trackpads) and Windows.
This functionality would also be useful for supporting high resolution scrolling in the pointing device feature.
The text was updated successfully, but these errors were encountered: