UltimateHackingKeyboard/agent

Feature request: enable Secondary role for mouse-clicks

Closed this issue · 12 comments

For the Mouse input configurator with the Agent, it helps to have an option to specify the Secondary role. This can be a very rare use case, but please read along for my justification for the request.
image


I'd like to use the Trackpoint module in its "traditional" 3-key configuration. The following is my current attempt. The caveat is that I cannot trigger the default scrolling behavior when I hold the "middle-button" down. Physically, this is the key on the right on the Trakpoint module.
(W10Wheel.NET may work as a comprime, but I had trouble getting horizontal scrolling to work with it.)
image
It helps to directly trigger the scrolling behavior when holding down the "middle mouse key" as mapped above (the key on the right on the Trackpoint Module).

I am still training myself to activate the Mod (or Fn) layer when I need to scroll with the trackpoint. This behavior is inline with what the TeX group is doing with their Shinobi keyboard. However, I still cannot get used to it after a full year. (For both UHK and the Shinobi keyboard, I assign the key in the bottom-left corner to act as the trigger for the Fn/Mod layer.)

This is a tricky requirement. Normally, the proposed canonical solution would be to use my fork's macro mechanism, but even that does not work in this case.

Specifically, the trouble is that as far as I remember, currently mouse actions (movement and scroll) do not trigger secondary roles in neither the stock firmware, nor in my firmware fork. This means that simply enabling secondary role for mouse actions won't work, because primary action (middle-click) would still activate even after a successful scroll event.

Furthermore, another trouble is that current postponing-based implementation of secondary roles is not exactly interoperable with mouse events. This means that while I can make basic macro-induced secondary role mechanism of my fork compatible with this feature, I cannot easily amend behaviour of the standard secondary role mechanism to comply.

I guess I will look into the issue at some point, but it is definitely not a high priority atm..

But it might be possible to imitate the behaviour using execution time.

So basically, feel free to try https://github.com/kareltucek/firmware with macro containing following two lines as two separate text actions:

$holdLayer mod
$ifNotPlaytime 300 tapKey mouseBtnMiddle

Edit: in current release, mouse Layer may bee needed instead of mod.

@kareltucek Thanks a lot for your quick response. Please advise what I did wrong, or we get the Windows OS to blame :)
I flashed the Firmware using uhk-firmware-8.10.10.kt.1.tar.gz and assigned the macro as specified below:
image
The macro is specified as below:
image

Other than getting a middle-click button that can also scroll, the button assigned with the macro does nothing when it is fully applied. Initially, well, it did the following temporarily:

  1. After applying the firmware, I created the macro and assigned it to the "right-key" on the Trackpoint Module. Then, pressing the key actively sent the prescribed "text actions". ==> I was suspicious whether the firmware was fully flashed, and went to do it again. I did get a red warning asking whether I want to force-refresh the firmware on the keyboard.
  2. Right after flashing the firmware on it, the "right-button" then acted as a right-click button for real. In UHK Agent, I still see that the macro is assigned to the key. Yet, I was sending right-clicks effectively.
  3. I opted to hit the "Remap key" button on the UHK Agent again, and I reached my current state: the button mapped with the macro does nothing at all.

PS: My go-to spyware for keystrokes is AutoHotKey, and it does not seem to catch anything when I press the key with its assigned macros. Also, I connected the keyboard to a Linux Mint machine, and the button still did nothing with the macro assigned.


@kareltucek Separately, upon flashing the keyboard with your firmware, the regular scroll behaviors are broken. With the Agent's own firmware, activating the Mod or Fn layer will make it possible to scroll with the trackpoint. I cannot scroll with the trackpoint after flashing the keyboard using uhk-firmware-8.10.10.kt.1.tar.gz from this release page.

I agree that this is very tricky, and ironically, even IBM's trackpoint mechanism doesn't work the proposed way. I've just checked my ThinkPad, and the middle trackpoint button works like the UHK Mod layer in respect of the trackpoint. When I click with it over a Chrome tab, the tab doesn't get closed, so it doesn't function as a middle mouse button. I understand the use case regardless.

I don't plan to include this niche feature, although we may include Karel's advanced macro commands eventually which enables it. In any case, I'm closing this issue, but feel free to continue the discussion regardless.

@mondalaci Thanks for closing the issue. Please correct me if any of the following summary is wrong:

  1. The keys on the Trackpoint module are different. It is not possible to trigger Secondary role on them.

  2. This implies that the following attempt will fail. (The idea is to ask AutoHotKey to interpret F24 as a middle-click, and to trigger the scrolling action while the key is pressed down.)
    image

@kareltucek Thanks a lot for your quick response. Please advise what I did wrong

Actually, this is my mistake - I was so concerned about checking that mouseBtnMiddle is correct that I forgotten to include the tapKey command. Should be

$holdLayer mod
$ifNotPlaytime 300 tapKey mouseBtnMiddle

The keys on the Trackpoint module are different. It is not possible to trigger Secondary role on them.

The other way around. Module buttons work just like rest of the keyboard, but mouse actions (scroll/movement) do not trigger secondary roles.

2. This implies that the following attempt will fail. (The idea is to ask AutoHotKey to interpret `F24` as a middle-click, and to trigger the scrolling action while the key is pressed down.)
   ![image](https://user-images.githubusercontent.com/5890407/128769929-7c3200da-7d46-4359-aefb-30b02d34ccae.png)

@mondalaci this is actually a good point. What behaviour would you expect mouse-movement/scroll-wise?

Well, actually this problem is already documented at UltimateHackingKeyboard/firmware#334

@kareltucek Separately, upon flashing the keyboard with your firmware, the regular scroll behaviors are broken. With the Agent's own firmware, activating the Mod or Fn layer will make it possible to scroll with the trackpoint. I cannot scroll with the trackpoint after flashing the keyboard using uhk-firmware-8.10.10.kt.1.tar.gz from this release page.

It seems like the layers are swapped in that build. Not exactly sure why, but since no-one has complained so far, I would rather leave this trouble till next standard release. That is, unless you find some other problem with it.

I.e., please, simply use $holdLayer mouse for this usecase, and keep in mind that you might need to change back to mod layer in the future.

@kareltucek Thanks a lot for pointing me to your fork. As you said, the following two lines helped achieve what I had in mind:

$holdLayer mouse
$ifNotPlaytime 300 tapKey mouseBtnMiddle

Or, graphically, the macro should be set as the following in the Agent:
image

Lastly, the following setting for a specific Keymap gets the job done.
image

@llinfeng The buttons and keys on the modules behave just like any other button or key on the UHK in general and in regards to secondary roles.

When a secondary role is set to a layer, the relevant navigation mode should be active which apparently isn't, and you've just made me aware of this issue. Let me create a new issue for this, @kareltucek.