Mouse Key Control

[haata]

Would be nice to have mouse control like on the tmk firmware.

Requires:

• kll spec enhancements for mouse control
• Mouse capabilties in the USB module
• kll compiler enhancements

[blais]

Killer feature, esp. for pasting instead of using those annoying rolling buttons that never paste where you want them too.

[kaansoral]

This would be pretty cool on the standard layout of the infinity, caps-lock + rightmost-arrow-like-keys could move the mouse and caps-lock + "/?"/the-rightmost-1x1-modifier can act like left and right clicks

The acceleration/speed etc. seems hard to get right, but it would be a pretty cool feature to have around, but I'm guessing the existing/upcoming infinity's aren't capable of mouse capabilities?

[smasher816]

afaik there is no special hardware for mouse keys. Thus once Haata adds support you should be able to use the feature with a firmware update for your infinity. You shouldn't have to wait for a new board for the feature.

[blais]

I was just thinking the same. The device outputs USB... in theory you should be able to generate anything a USB device can generate, no?

On Thu, Mar 26, 2015 at 5:47 PM, Rowan Decker [email protected] wrote:

afaik there is no special hardware for mouse keys. Thus once Haata adds support you should be able to use the feature with a firmware update for your infinity. You shouldn't have to wait for a new board for the feature.

— Reply to this email directly or view it on GitHub https://github.com/kiibohd/controller/issues/4#issuecomment-86730545.

[smasher816]

Correct. The bigger issue is figuring out how the capability will be defined in the KLL files so that a configurator will be able to use the features.

[haata]

Yep, we can output anything USB. Basically, I want to make the Mouse USB descriptor a bit more dynamic (absolute vs. relative positioning for example) so this takes a bit of work on my part to add to the kll first as well as testing out permutation of descriptors. I've already made some initial passes at the KLL spec for this, but it's not ready for review yet.

I'm a bit swamped right now bringing up a new chip (mk20dx256vlh7), but once that's complete I'll start working on KLL enhancements like this.

At some point I also want to add support for other USB devices like Joysticks and Gamepads.

[haata]

I've started work on adding Mouse (and Joystick) USB descriptors.

20b62afb9a05a64b1f15c6329866600913775eea

[kaansoral]

I think even the crudest scroll left/right functionality would be extremely useful, as it doesn't exist on most setups, but sites like github requires you to scroll left and right, and the scrollbar is only available at the bottom, so you usually can't just scroll left/right practically while inspecting a code piece

[boogerlad]

Any updates?

[haata]

Not yet, still deep into State Scheduling/Tap keys and Leds.

If I have some spare moments this weekend I might test out some super basic mouse stuff but I have no idea if it'll work well.

On Sat, Jan 30, 2016 at 1:24 PM boogerlad [email protected] wrote:

Any updates?

— Reply to this email directly or view it on GitHub https://github.com/kiibohd/controller/issues/4#issuecomment-177306686.

[haata]

I haven't added "full" KLL support. However there is now very basic mouse support. Up to 16 mouse buttons and relative x/y movement.

I'll probably add some simple options for the configurator, but for those that compile the firmware themselves here's some examples. https://github.com/kiibohd/kll/blob/master/layouts/mouseTest.kll

[dondelelcaro]

The mouse stuff seems to be working for me; thanks for adding it. However, I'm not sure how to get the mouse movement to repeat when the key is held (IE, holding the key will keep moving the mouse in the desired direction.) Is there a repeat function that can be wrapped around mouseOut() in the kll file? (Or something like that?)

[haata]

Hmm, I thought repeat was working... Can you post your .kll config for the mouse setup?

[dondelelcaro]

Sorry for the delay. Here's my fork which has the relevant kll files: http://git.donarmstrong.com/?p=kiibohd-kll.git;a=blob;f=layouts/da_layer3.kll;h=49971a83ec1fb37c936aae53e187eb4727a9d35d;hb=refs/heads/donlayout

[MarkIvanowich]

Been interested in mouse key control for a while, I'm glad that it's in a working state. Pushed it to my Infinity 60%, and I have it working for mouse control. Noticed how jumpy it was for short taps of a key, so I did some investigation. I opened Wireshark monitoring my Corsair M65 Gaming mouse, to see how it sends it's reports. It too, reports 16 bit relative x/y coordinates. Interesting find; it almost never goes past -/+1, unless violently waving the mouse around, then I've seen at maximum -/+9. Note, for any DPI, effect is the same. This leads me to believe that for any mouse, the hardware acceleration in a mouse is just limiting the number of interrupts it sends out. Relative X/Y is almost always -/+1.

Sooo... A practical use for mouse keys acceleration, will somehow need to increase the number of interrupts sent the longer duration a key is held.

As a test, this is my configuration: I have a main layer with keys mapped to U"RALT" : mouseOut(0,0,-1);, and a second function layer that will send only one interrupt per key press. (KLL0.5 would work better for this) U"RALT" : mouseOut(0,0,0), mouseOut(0,0,-4); Hacky, yes. But I can have very accurate movement with the cursor on any screen size.

Please forgive me, I just hopped on this train. I'm getting used to locations and routine.

[tkaehn]

Hi, I've tried out mouseTest.kll. Is it possible to emulate the scroll wheels? I haven't managed to do so under Mac OS X. Best regards Thomas

[ckaros]

I have an ergodox infinity and am experiencing some interesting mouse behavior. If the mouseOut capability is tied keys on the master node (keyboard half connected to pc), the mouse function works great. However, if the capability is tied to keys on the slave node (the daisy chained half), the mouse will only move one step with every press. Aka, repeat does not work.

Obviously this doesn't matter too much since I'm not always changing which half is master and slave. Just something I observed.

[haata]

Hmm, sounds like a bug in the interconnect api. I haven't tested it yet with the mouse control.

[boogerlad]

Any update on the scroll wheel behavior?

[GuilloOme]

@boogerlad and @tkaehn, the scroll wheels are nothing else than button mapping:

• Button 4 is "Scroll Up": mouseOut( 4, 0, 0);
• Button 5 is "Scroll Down": mouseOut( 5, 0, 0);
• Button 6 is "Scroll Left": mouseOut( 6, 0, 0);
• Button 7 is "Scroll Right": mouseOut( 7, 0, 0);

@haata, but it seems there is a bug. it's not mapped right at the os level:

• mouseOut( 2, 0, 0); produce a button 3
• 3 produce button 2
• 4 produce button 8
• 5 produce button 9
• 6 produce button 10
• …
• 16 produce button 20

[endreszabo]

This OS-level mismatching is a showstopper on my TMK->KLL migration with my new K-Type. :/

I've even tried mouseOut(-1, 0, 0); which seems to be ignored.

[ToyKeeper]

I've run into these issues on my new WhiteFox too. However, the mouse functions do mostly work already, and it might be a good idea to track those issues individually. Thoughts?

The specific issues I encountered are:

• No acceleration.
• Buttons 4 and above are shifted +4, so they come out as 8 and above. This means no scroll wheel events.
• Button 3 (middle button) plus vertical motion somehow produces button 4 and 5 events, repeating, which causes scrolling. So, I can't middle-click-and-drag.
• Buttons 2 and 3 are swapped.
• Up and Down motions are reversed in the configurator. https://github.com/kiibohd/configurator/issues/89

I may take a shot at some of these. I added acceleration to Kaleidoscope (keyboard.io firmware) so I'm hoping I can apply similar methods here.

[jxz12]

Has there been any progress on fixing the Buttons 4 and above shifted +4 issue? I would love to be able to scroll. If not, any pointers on where in the code to start digging into for my own PR would be much appreciated.

[haata]

I haven't had a chance to look at this yet. This code is pretty simple so it should be easy to reason about (unless the OSs are doing strange things...which does happen).

Code that sends the USB packet: https://github.com/kiibohd/controller/blob/master/Output/USB/arm/usb_mouse.c#L71 Structure for the mouse data: https://github.com/kiibohd/controller/blob/master/Output/USB/output_usb.h#L91 Mouse button capability: https://github.com/kiibohd/controller/blob/master/Output/USB/output_usb.c#L637 Mouse wheel capability: https://github.com/kiibohd/controller/blob/master/Output/USB/output_usb.c#L707

[jxz12]

Great, thank you for the pointers! I played around a bit last night (wasn't able to get docker running unfortunately) but from digging around in the code I found that scrolling is perhaps not mapped to mouseOut(4,0,0) as suggested above, but to mouseWheelOut(x,y). At least according to https://github.com/kiibohd/controller/blob/master/Output/USB/capabilities.kll.

However even a value of 1 scrolls waaay too fast on MacOS. On Windows it is workable, but scrolling up is faster than scrolling down for some reason. Is there a simple way to change the speed of scrolling depending on the OS? I speculate that MacOS polls for scrolling much faster (perhaps why their touchpads are so much better).

Hopefully that helps if you decide to look into it! I'll also keep hammering away at docker at some point too.