-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Factor out just the mouse key emulation from #778 #1430
Conversation
A squashed version of the original changeset from zmkfirmware#778 rebased on main
I've stripped out everything not strictly required for mouse button HID support. This include dropping the worker thread completely, shaving down the USB HID descriptor. Flattening the mouse/ source directory structure and removing a bunch of event handling. I have kept the mouse event handling separate from the other HID event handling since I figured that was a pretty neat split. If that's a bad idea, do tell. I've also added a test case for mouse button emulation, since that was untested before. The changes have been tested on a corne (split) in usb mode. Bindings on both the left and the right side works (with the left side as master).
I've been looking though the code, and I'm maybe not entirely convinced the mouse_button_state_changed_event does anything for me. It doesn't really seem to fit with the rest of ZMK to raise events on behaviors. Does anyone have any opinions on that? |
I tried this and it doesn't work for me: Windows shows the mouse HID device not loading correctly when attached by USB and I get nothing when connected via BLE. I tested with a nice!nano. The mousepr does work for me. |
@codeandr3w That interesting. Do you get any error message or anything in the Windows EventLog? I'm running an expanded version of this PR on my crkbd and it's working in both windows and linux over USB with no issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor items. Thanks for working on this!
|
||
/* Mouse press behavior */ | ||
/* Left click */ | ||
#define MB1 (0x01) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not alias proper HID usage defines here, like we do for keyboard page?
@@ -0,0 +1,29 @@ | |||
/* | |||
* Copyright (c) 2020 The ZMK Contributors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the copyright dates.
@@ -13,3 +13,4 @@ int zmk_endpoints_toggle(); | |||
enum zmk_endpoint zmk_endpoints_selected(); | |||
|
|||
int zmk_endpoints_send_report(uint16_t usage_page); | |||
int zmk_endpoints_send_mouse_report(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just use the existing API and pass the button page id?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do that. I think it's maybe a little odd since we're not telling the api which device we want to send a report for (in case you also had a button subusage inside the keyboard), but there's no technical problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... Let me ponder that a bit more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having a hard time thinking of why we would have that subusage any time soon. If you can give me a compelling use case, I'm open to changing toward your proposed approach, otherwise I'd say we stick with the existing API/approach.
HID_COLLECTION(HID_COLLECTION_PHYSICAL), | ||
HID_USAGE_PAGE(HID_USAGE_BUTTON), | ||
HID_USAGE_MIN8(0x1), | ||
HID_USAGE_MAX8(0x10), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is 0x10 hard coded here arbitrary, or based on some spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's sorta arbitrary. It's the number of buttons, and 8 was chosen to fill up a word. There's no real rhyme or reason, and i suspect most systems won't even support all 8 buttons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine, can we pull out the number of supported buttons into a define value to name it?
static const struct behavior_driver_api behavior_mouse_key_press_driver_api = { | ||
.binding_pressed = on_keymap_binding_pressed, .binding_released = on_keymap_binding_released}; | ||
|
||
#define KP_INST(n) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#define KP_INST(n) \ | |
#define MKP_INST(n) \ |
Also was unable to get this pr working on windows 11. nice!nano_v2 connected over USB. Haven't tried the original PR yet, that will be next. Here's the details of the error from device manager: Error: Driver: Event: Driver Name: msmouse.inf Update: the same keyboard works just fine on Ubuntu 18. Just has driver errors on Windows. Let me know if you need more data. I'm not super familiar with HID but I'm happy to help where I can. |
Firstly, Thanks for the review. I'm sorry it too so long to get back to this. I've asked some questions I think we should discuss before merging this, but I'll make the rest of the changes soon. As for @aherriott. I'm not super familiar with how to debug this on windows, so I'll have to see if I can replicate. I daily a keyboard running this patch on windows without issue, but that keyboard also has additional unreleased changes. I'll try and revert to just this branch and see if i can replicate your issue. If anyone has any idea of how to debug this, please do share. I'll happily fix it if I know what the issue is. |
@@ -0,0 +1,9 @@ | |||
/ { | |||
behaviors { | |||
/omit-if-no-ref/ mkp: behavior_mouse_key_press { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not name it &mbp - mouse button press or &mbc - mouse button click? I think the mouse button is a more common name than the mouse key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.. I'm more inclined to go with the press version though, since we keep the press/release terminology still.
So, one thing I'm noticing here, is that the HID report/descriptor here includes the buttons, but no X/Y axis report information. I'm wondering if perhaps this trips up Windows' HID driver which expects a collection in this usage page to include those. The original lump sum PR had those items in the report descriptor, so perhaps worth adding that and seeing how the Windows testing goes. |
I've just opened #1991 as a starting point so folks can test the fixes for Windows there, and will be iterating on that to try to address all the review feedback and get this in. Please test there! |
Closing now that #1991 is merged. |
This PR includes ONLY enough mouse emulation to enable mouse keys. It's a trimmed down version of #778.
I've left this as 2 commits, the first one is a squashed version of #778, the second removes everything that is not required for mouse keys.
It has been tested to work on a corne in usb mode. bindings on both the left and the right side work.
I would recommend squashing before merging, as having a commit that adds a bunch of stuff and then one that removes it again is sort odd, but it probably makes the review easier for people familiar with #778 already.