Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Rapid press of two mousekeys makes mouse cursor stop. #144

Closed
tyetye opened this issue Feb 16, 2016 · 18 comments
Closed

Rapid press of two mousekeys makes mouse cursor stop. #144

tyetye opened this issue Feb 16, 2016 · 18 comments

Comments

@tyetye
Copy link

tyetye commented Feb 16, 2016

Issue: If I press two mousekeys at the same time or almost the same time the mouse cursor stops moving.

Expected Behavior: I expect the mouse cursor to move on screen no matter how quickly I press multiple mousekeys.

Actual Behavior: The mouse cursor stops moving after moving a very short distance in the direction of the first mousekey press.

To Reproduce: Press a key assigned to KS_MS_U and then immediately press KS_MS_R. The mouse cursor should move diagonally to the upper right does instead it stops moving.
@mecanogrh
Copy link

Could not reproduce here (planck), all is working fine and diagonals are working even if I (or so it seems) hit the two mouse keys at same time. Note that I'm using mousekeys on a different layer and have the layer key depressed as well all the time (momentary hold behaviour).

@tyetye
Copy link
Author

tyetye commented Mar 4, 2016

Interesting. I'm on an Ergodox EZ, but otherwise exactly as you described -- momentary hold for a new layer. I just did a new pull/compile and flashed the keyboard but the problem remains. Thanks for checking yours. I actually use the mouse keys a lot so it's kind of frustrating.

@ezuk
Copy link
Contributor

ezuk commented Mar 5, 2016

Hey @tyetye - just tested this on my ErgoDox EZ to see if it's maybe related to the keyboard. Here is what I noticed:

I can press a key mapped to "mouse up" and hold it down. Mouse starts moving up. I quickly add "mouse right" and get a diagonal. It's not hitting both at the same time -- it's a rolling motion, maybe 50msec separating both keydown events. To me, this is acceptable, but I understand if you need to press them both at exactly the same moment.

@jackhumbert - is there a reason for this to be different between the EZ and Planck? On your Planck with default QMK, can you hit both mousekeys at exactly the same time and get a diagonal?

@tyetye
Copy link
Author

tyetye commented Mar 7, 2016

Hi @ezuk.
Yes, that's the behavior I am describing.
It's not so much a matter of needing as much as it's frustrating when it doesn't work as expected. Imagine if the regular mouse worked as expected 90% of the time but 10% it just didn't move because one didn't initiate the move correctly.

@ezuk
Copy link
Contributor

ezuk commented Mar 8, 2016

Yup, understood. @jackhumbert any thoughts?

@ItsHarper
Copy link

It also works properly on my Planck. I'm curious to know what could cause this.

@ezuk
Copy link
Contributor

ezuk commented Apr 12, 2016

@jackhumbert - ping :) Any thoughts on this issue? Pretty interesting.

@eltang
Copy link
Contributor

eltang commented Apr 21, 2016 •
edited
Loading

@ezuk What happens if you put the mouse keys on the right side of the keyboard, the side that's not handled by the I/O expander?

@tyetye
Copy link
Author

tyetye commented Apr 21, 2016

@eltang Interesting thought. My mouse keys are already on the right side with the Teensy. However, the layer modifier key is on the left hand side with the I/O expander.

@eltang
Copy link
Contributor

eltang commented Apr 21, 2016

Uh-oh. I'll have to look into the code and see what might be causing the problem.

@eltang
Copy link
Contributor

eltang commented Apr 28, 2016

@tyetye I'm planning to make some changes to the Ergodox EZ's matrix.c file. Let's see if you still have this problem after I do.

@nrrkeene nrrkeene mentioned this issue May 4, 2016
Merged
@eltang
Copy link
Contributor

eltang commented May 4, 2016

@tyetye While solving #296, I noticed that the ErgoDox EZ has custom parameters for the mouse keys defined in config.h. What happens when you remove them?

@algernon
Copy link
Contributor

FWIW, I have experienced this problem too, on ErgoDox EZ, and it was very annoying, as I have diagonal mouse movement macros, which didn't work. For unrelated reasons, I moved the mouse keys to the right half (the layer key was already there), and now when I found this issue, and wanted to reproduce, I see it works now.

So it looks like @eltang got the right idea. Thanks!

@tyetye
Copy link
Author

tyetye commented May 20, 2016 •
edited
Loading

@eltang @ezuk Thanks, eltang! It looks like that group in config.h is the culprit.
I set MOUSEKEY_DELAY=5 in place of the current value, MOUSEKEY_DELAY=100. This seems to have solved the issue. I haven't heavily tested to see if it interferes with non mouse related functions.

If I set MOUSEKEY_TIME_TO_MAX=25 and MOUSEKEY_DELAY=5, then the issue happens again. So, there is some sort of relationship there. I haven't explored it thoroughly.

ezuk, do you know if there is a reason these particular values were used?

@ezuk
Copy link
Contributor

ezuk commented May 21, 2016

Nope! Just inherited them, no particular reason for these. If you find values that work well, please feel free to submit a PR with them :)

@eltang
Copy link
Contributor

eltang commented May 21, 2016

@tyetye @ezuk Those can be simply taken out. There are default values that will be used if no values are defined in config.h.

@tyetye
Copy link
Author

tyetye commented May 24, 2016

@eltang @ezuk I tried commenting out the values in the EZ's config.h so they use the QMK defaults. The mousekeys still work but become less smooth and less usable -- the movement of the mouse cursor is very jerky. This should probably be tested more thoroughly before completely removing the EZ's config.h values for everyone like in Fix #144.

@eltang
Copy link
Contributor

eltang commented May 24, 2016

@tyetye That's why I didn't create a PR with those changes yet. As @ezuk asked, have you found a set of parameters that you like?

@ezuk ezuk closed this as completed Jul 24, 2016
@noroadsleft noroadsleft mentioned this issue Sep 24, 2018
Closed
BlueTufa pushed a commit to BlueTufa/qmk_firmware that referenced this issue Aug 6, 2021
@noroadsleft @yanfali
Added instructions for gh-pages deployment (qmk#144)
07ab06b 
* Added instructions for gh-pages deployment
* changes per @yanfali
* Fix for CNAME instruction
GerardoNevarez pushed a commit to GerardoNevarez/qmk_firmware that referenced this issue Apr 27, 2022
@trashcatt
Adding the Waffling60 to VIAL (qmk#144)
33a3b2d 
* Create keymap.c

* Add files via upload
chrellrich pushed a commit to chrellrich/qmk_firmware_og that referenced this issue Jul 15, 2023
@lokher
Merge pull request qmk#144 from lalalademaxiya1/keychron_q5_pro
a3b96e1 
Updated q5 pro
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@algernon @ezuk @tyetye @mecanogrh @ItsHarper @eltang