-
Notifications
You must be signed in to change notification settings - Fork 74
Macrotime.0.2 #25
Macrotime.0.2 #25
Conversation
… time in microseconds.
While recording a macro, betweenm each two key changes the delay is recorded. The format is +/-KEY=macrotime_in_usec.
While recording a macro, between each two key changes the delay is recorded. The format is +/-KEY=macrotime_in_usec. The correct form ist adjusted when clicking "Stop".
Some corrections and comments for the first steps in the new GUI element for Keystroke-Delays.
…ime.0.1 Conflicts: src/ckb/macroreader.cpp : repaired
When compiling on my linux mint 17.3 with gcc version gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 I got an unknown const UINT_MAX.
This implementation adds some UI Elements to the Binding tab.
When recording a macro, the timing (the time between changes the
Keyboard receives) are noted with the key values.
When saved with the detailled timing information, you may choose between
- running the macro witghout any delay
- running it with the standard delay
- 0ms for the first 20 changes (normally 10 Keys),
- then 30ms for up to 100 keys (200 status-changes)
- and then 200ms for any further change)
- running the key delays, which had been recorded.
After recording (or after saving) you may change the timing values.
This might be useful, if you want to generate slow keystrokes, but you
do not want unneccessary long wait times (e.g. when sending longer macro
content to a virtual machine or a remote desktop tool, the maximum speed
is often too high. So include a short delay and all is fine).
There are some contraints in using the TAB area for configuration. because of too many elements neccessary for the macro GUI, The font size had been set to 12px fix. If you find that is to small, you can change it by installing an own stylesheet file and calling ckb with ckb -stylesheet=<stylesheet-file> The complete TAB area (better the surrounding areas) should be redesigned...
…to macrotime.0.0 Merging functions in deamon to handle Delays while running key-macros. Code is written by stephenhouser.
…o macrotime.0.1 first steps using delays for macro keys replay
After a reboot of the GUI, the indicator keys have only responded to settings in the Performance tab when one of the settings has been changed. The reason for this is in the initialization sequence to the daemon. With the inotify command executed here, the Notifychannel must obviously be preceded. On the occasion a few methods were commented according to doxygen standard. Although they had nothing to do with the error, they were analyzed during debugging.
…s-not-remember-settings Just setting VERSION file to beta0.2.8+testing
…ttings' into testing
|
There seems to be an issue with this. Whenever a macro is being typed with delay, the animations freeze. |
As a user mentioned, the colorization of the keyboard was stopped while a macro with delays is played. This was because the synchronisation block in input.c was over the whole play-loop for the macro. Now we have an unlock / lock sequence around all usleep calling for delay. This has only minimal impact on the timeing behavior. Test was a long running macro inclusive startings "time cat" at the beginning and sending CTRL-D at the end. Colorization was "shimmer" all over the keyboard, so heavy load between GUI and daemon. With this long macro before this commit, time-cmd gives: real 0m40.087s (between 40.080 and 40.087 in different runs) user 0m0.000s sys 0m0.000s after changing the blocking for this critical section we get: real 0m40.116s user 0m0.000s sys 0m0.000s
|
@tatokis Thank you for the issue, I found the critical section. |
|
@tatokis this issue was really hard to fix. Please try again if you have time for it. I messed up the git history for this branch a bit, so the latest commit should contain elements for the new firmware mechanism also. I'll fix it if the function is ok. |
dc60ba0 to
56da87c
Compare
The first implementation for macros with delay management has stopped the colorization while playing the macro content. This Version handles the macro playing different: It starts a single thread for each macro when the appropriate key is pressed. All tasks are self-syncing via a linked list (FIFO). One Todo is left: When playing macros, all other keyboard input except modifyer keys is ignored. A \todo is set as comment where to heal this if anyone finds out... With the new coding some comments for existing code and changes for better readability are made and typos have been fixed.
|
Pressing a macro key no longer types anything. |
|
Ignore the above message, I had the wrong ckb-daemon started. It's working as expected now. I think this should finally be merged. |
Due to a doxygen-related commit, earlier changes in usb.h were replaced and not added back.
This causes the version to show up incorrectly. e.g. ckb: Corsair RGB driver beta-v0.2.8+testig
|
@frickler24 Since both of us have confirmed it working, could you please close this PR and reopen it with only the relevant commits (against testing if you do it before the 20th). |
|
OK |
Hello,
this branch for improving the macro properties involves three things:
For users which have used G-Keys with complex definitions, there is a short shell script to convert existing definitons into the new form (migmac.sh)
It has been tested on linux mint 18/64 with K95RGB and M65