Definitely shift the movement keys over to ESDF rather than WASD (WASD makes sense on a flat keyboard for gamers because the gamers’ “home row” is very different from the typists’). I pushed the mouse keys onto the numlock rather than the function layer as well. I’m not a vi user, and HJKL navigation doesn’t feel right to me, so my function layer has cursor movement and such on the left hand around ESDF and a bunch of common programming symbols on the right hand, pulled down from the shifted numbers (I could just about live with only 3 rows of keys, except for occasional gaming).
4 Likes
I am using the mouse controls only for fine positioning. I’ve added these lines to the bottom of my ‘setup’ function:
MouseKeys.speed = 16;
MouseKeys.speedDelay = 100;
MouseKeys.accelSpeed = 0;
(The “16” comes from looking at the code and finding a division by 16.) When I tried this, I found that when I tapped one of the mouse movement keys and released it quickly (so as to not have it autorepeat), 2/3 of my keypresses caused no movement. I found this on line 86 of Kaleidoscope-MouseKeys.cpp:
endTime = millis() + speedDelay;
I changed it to just
endTime = millis();
That improved matters, but I still lose 1 in 4 keypresses. I don’t know why.
1 Like
imo keyboard mouse controls would be greatly improved if the acceleration/speed stuff was ‘vectorised’ to make x & y axis independent. currently if you want to move a long way sideways, followed by a tiny little bit up & down this requires two separate gestures. (try it!)
Has anyone thought of making it use, like, a physics engine to handle the easing. I think this might have better ‘feel’ & smoother , more predictable acceleration than what’s there.
One more random thought on the subject - I’d suggest releasing fn whilst continuing to hold the direction key should cause ‘friction’ to kick in, slowing down the cursor gradually as it nears the destination. Seems to me the basic problem with mouse keys is you usually slow down a real mouse as you near the destination, whereas there’s no gesture for this.
Also, with current firmware I think the following params are a huge improvement on the stock firmware (at least on my arch linux machine this seems much better):
MouseKeys.speed = 7;
MouseKeys.speedDelay = 3;
MouseKeys.accelSpeed = 1;
MouseKeys.accelDelay = 100;
EDIT:
on the simpler/easier-to-implement side, how about a max speed control?
( and absolute last rumination/question on mouse keys I promise ) - github readme mentions mouse keys require a patch for linux. That info seems out of date & mouse keys mostly work. However scrollwheel does seem broken on my machine. (it scrolls all the way up or down on single press) Is a patch for this available somewhere?
2 Likes
If that would involve floating point, that’s quite a bit of bloat. It’s not something I would do by default…
Can you file an issue on GitHub? Much easier to track requests there, than on the forums. Thanks!
Yeah, that information is out of date. It only applied to the warp keys anyway, the rest worked out of the box on Linux too. Nowadays, warp keys do too.
What OS are you using? Did you use a git clone of Arduino-Boards, or Jesse’s board manager way? If the former, when did you clone, or update the submodules?
There have been changes in MouseKey land recently, which may have affected the scroll wheels (though they shouldn’t have, but it is possible I messed something up despite best efforts).
1 Like
Two ODEs cover the dynamics. It involves a driving force (constant, defined by the keys) and slipping friction. This simple system could be solved with an explicit Euler time integration scheme, even without too much trouble regarding numerical instabilities. The computations could largely be carried out based on integers, thus minimizing the use of floating point math.
The minimal overall costs would be three integer additions and one integer and two float multiplications per cycle. All in all this does not sound too computational expensive.
If I had time (and a M01) I would be tempted to write a Kaleidoscope-Mouse-Dynamics plugin. But if anyone is interested in the howto, feel free to contact me.
3 Likes
heh I’m something of a fixed-point DSP enthusiast & have actually worked on 2D/3D game physics engines before… almost thinking about how to combine those two for keyboard firmware! (though I’m pretty much up to my neck in other open-software/firmware type of projects)
for sure, I posted on here cause I wanted to moot the ideas/concepts a bit before actually writing any code or pestering anyone else to do so… (and btw I’ll file an issue for mousewheel stuff in a bit)
4 Likes
If you ask me, a game, or a demo on keyboard LEDs would be a whole new genre. 
2 Likes
Strain gauges can be extremely sensitive. I’m not worried about capturing a feel for the pressure exerted on a button. Is there a free analog input available in the current hardware ? If so it could be easily hacked ! 
3 Likes
There is. I’ve gotta get the schematics published.
3 Likes
Would you mind sharing the snippet from your sketch that made the mouse speed mod key work? I tried setting up a macro key to change the MouseKey.speed but it stopped the mouse movement every time I pressed it.
I don’t think I have speed setting keys anymore, but I’ll try to reproduce what you describe, and see if I can come up with a way that does not stop mouse movement.
1 Like
Have you had a go with the ErgoDox EZ mouse control? It’s the one and only thing I think is better on that keyboard. No idea how they do it - what sort of algorithm it is, but it’s immediately more usable than the M01 when you first try it. I didn’t find myself wanting to change the speed setting - it just sort of worked quite naturally straight away.
1 Like
Other than the speed feeling “better”, what else do they do more right for mousing than we do? I’d love to improve. @algernon, have you played with QMK’s mousing?
2 Likes
IIRC one of the things they do very differently is acceleration: they don’t do it automatically. It’s been ages I played with QMK though. @nickhandel, can you file a bug on GitHub against Kaleidoscope, by any chance? That’d help me tackle it at some point.
1 Like
Absolutely. I’ll plug the EZ back in tomorrow and have a more diagnostic play with it. I wonder if the lack of acceleration is what I preferred. Based on very brief tries on both board, I found the M01 moved far too little to begin and then got too fast very quickly - choosing something in a drop down felt pretty painful. I didn’t get that with the EZ, but I will concede it did take a little while to make its way across the screen.
2 Likes
OK, I had another play. The Ergodox is better. Immediately usable. It definitely does accelerate, but I think the delay is longer before it starts accelerating. With the M01, tiny differences in length of key press are significant. Not so on the Erogodox. You can basically tap it for fine adjustments - it seems to jump a few pixels at a time.
2 Likes
@algernon did you do something in 1.94.0.beta? I just got around to updating the firmware with Arduino and it definitely seems different from how it was at the factory. It’s better - longer delay before acceleration but I hate to say maybe too much the other way now…
I think it might have been b18465033ebfe9eda2900960490e8c84cfdccc2b I guess, but that’s from April last year.
Interesting. Well with the latest firmware installed, my original comment is reversed. I may have to see if I can have a tinker with it myself. Need to knock out a few things with the day job first…
You might want to play with MouseKeys.setSpeedLimit() and MouseKeys.accelSpeed and MouseKeys.accelDelay if acceleration and speed are your issues.
2 Likes