Virtual modifiers control, output of modifiers' state.

[Hibryda]

I'm likely trying to break through the open door, but here are my attempts/ideas.

I have Orbweaver keyboard as secondary for left hand. I'd love to be able to switch multiple "layers" of settings using virtual keys/modifiers. Yet, in order to have it working, I need to be sure which modifiers are on. And here's the lack of control, as it seems to me that such a syntax: Z >> !Virtual1 !Virtual2 Virtual3 mod_clear[3] is a bit cumbersome.
So, I decided to use the provided keymapperctl in a script that cancels all modifiers and sets the triggered one to ON. And here I got a surprise, as the time needed to clear one modifier is for some reasons very long. At least on my PopOS Linux - it takes ~100ms.
So, here is my first idea - make modifiers, working in the same context optionally cancel all the others in this context. It can be done with, for instance @Virtual1 or alike. This would ensure switching leaving active only this one. It's important, as usually there's no visual clue on the mode.
Another improvement would be to speed up this --release time which is quite large.

But that's not all. I actually built the script I mentioned to provide me with a visual clue on modifiers. It now looks like below, as a prototype it still needs more icons and stuff.

It's an overlay, that stays atop showing active modifiers.

Anyway, development of this little tool shown me some issues with respect to modifiers. I can't easily determine their current state otherwise than either placing calls to some scripts in keymapper.conf or asking repeatedly keymapperctl --is-pressed VirtualX (which is faster, yet slow as well). Then, the idea is that keymapper could expose the current map of Virtual keys as a device of sorts in /dev/xxx or temp to be monitored and read on changes by some other software. Of course, in order to retain safety of this software it could only be created and available on some switch in keymapperd (which requires admin rights to manipulate).

[houmain]

Hi Hibryda,

as it seems to me that such a syntax: Z >> !Virtual1 !Virtual2 Virtual3 mod_clear[3] is a bit cumbersome.

Couldn't you move verbosity into a macro? Maybe you could show some more of your configuration.

Another improvement would be to speed up this --release time which is quite large.

Sorry, I could not reproduce any delay. I tried it with the following configuration and "On" and "Off" notifications appear instantaneously:

Virtual2 >> $(keymapperctl --notify "On") ^ $(keymapperctl --notify "Off")
F1 >> $(keymapperctl --press Virtual2 --release Virtual2)

or asking repeatedly keymapperctl --is-pressed VirtualX (which is faster, yet slow as well)

You should not have to poll the virtual key state. Your script could repeatedly call:

keymapperctl --wait-toggled Virtual1 --is-pressed Virtual1

and read the result code or monitor the output of something like the following:

keymapperctl --wait-toggled Virtual1 --is-pressed Virtual1 --stdout --restart

I have not thought about monitoring multiple keys with a single instance. I will make the parameter of --wait-toggled optional, so the following would work:

keymapperctl --wait-toggled --is-pressed Virtual1 --stdout --is-pressed Virtual2 --stdout --is-pressed Virtual3 --stdout --restart

which would output 0 or 1 for each virtual key whenever one is toggled.

BTW you could give your Virtual keys meaningful names using aliases. e.g. LayerApps = Virtual1.
These also work with keymapperctl: keymapperctl --release LayerApps

[Hibryda]

Thanks for the reply! For the record, I love your keymapper.

I could show my whole config, but it would not make it any clearer (besides it's now an experimental mess). Also, I can move things to macros and have some, but I gave an example for verbosity.

As to the timing issue, in a detached script I have: seq 1 $mod_count | grep -v "^$1$" | keymapperctl --release Virtual$1;. For 5 keys it gives me a bit less than 500ms.

I just did

time keymapperctl --release Virtual1
real	0m0.085s
user	0m0.003s
sys	0m0.006s

Which indicates that while processing time is minimal, there's some blocking. Maybe it's on my side, but already tried to investigate it deep with perf and found nothing. But again, it's likely that it is smth on my side.

I will make the parameter of --wait-toggled optional

This would be great, provided they'd be identified by a label - otherwise it only makes sense to launch multiple keymapperctl --wait-toggled Virtual1 --is-pressed Virtual1 and spy their outputs.

I have another idea - could you please improve verbosity of keymapper -v stdout, so it would include changing modifier states? Actually, I can grab its output in my "monitor" but at the moment, modifier changes are not being reflected there. Temporarily I'm going to run a simple script on modifiers, as execution of external scripts is reflected. And indeed - instantly.

[Hibryda]

Returning again, as I found some spare time to finish things.

So, now I'm using such syntax for virtual keys:

mod_switch_on = $(mod-switch ON $0 $1 $2 $4 $5)
mod_switch_off = $(mod-switch OFF $0)

(...)

Virtual1 >> mod_switch_on[1,2,3] !Virtual2 !Virtual3 ^ mod_switch_off[1]
Virtual2 >> mod_switch_on[2,ALL] !Virtual1 !Virtual3 ^ mod_switch_off[2]
(...)

Macros are calling practically empty locally callable script - in itself it only does some debug reporting only. But is shows in the keymapper -v output as an external script called with specific params. I'm catching the output of keymapper on a permanent basis and extract those calls based on some regexes. Then I parse it and turn it into correct display of active virtual keys.

I still postulate that there could be some built-in facilities enabling doing the same without dirty hacks, like, for example, debug infos when -v option is set informing on changed state of the kirtual key of specific name.

[houmain]

I still postulate that there could be some built-in facilities enabling doing the same without dirty hacks, like, for example, debug infos when -v option is set informing on changed state of the kirtual key of specific name.

Is already implemented and will be in the next release, thanks!