Skip to content
This repository was archived by the owner on Apr 21, 2025. It is now read-only.

Conversation

@frickler24
Copy link
Collaborator

@frickler24 frickler24 commented Jan 15, 2017

Hello,
this branch for improving the macro properties involves three things:

  1. Handling of different delays when playing macros ([Feature request] Specifying pauses in macros #359 ccMSC/ckb#437)
  2. A GUI for recording the time between keystrokes during recording
  3. The branch is based on my last pullrequest "K95 rgb v205 init bug" K95 rgb v205 init bug #24

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

stephenhouser and others added 30 commits August 11, 2016 18:52
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.
@frickler24 frickler24 mentioned this pull request May 24, 2017
@tatokis
Copy link
Collaborator

tatokis commented Jun 3, 2017

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
@frickler24
Copy link
Collaborator Author

@tatokis Thank you for the issue, I found the critical section.
But if I change it so that the lightning is unblocked while macro player is sleeping, we get an error if you press another macro-Key while the playing is still running.
I have to think about it again.

@frickler24
Copy link
Collaborator Author

frickler24 commented Jun 5, 2017

@tatokis this issue was really hard to fix. Please try again if you have time for it.
@stephenhouser, @fleischie and others running macOS, please try the last commit if you like.

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.

@frickler24 frickler24 force-pushed the macrotime.0.2 branch 4 times, most recently from dc60ba0 to 56da87c Compare June 6, 2017 18:42
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.
@tatokis
Copy link
Collaborator

tatokis commented Jun 14, 2017

Pressing a macro key no longer types anything.

@tatokis
Copy link
Collaborator

tatokis commented Jun 15, 2017

Ignore the above message, I had the wrong ckb-daemon started. It's working as expected now. I think this should finally be merged.

tatokis and others added 4 commits June 17, 2017 08:39
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 frickler24 mentioned this pull request Jun 17, 2017
@tatokis
Copy link
Collaborator

tatokis commented Jun 17, 2017

@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).
I want this to be merged ASAP.

@frickler24
Copy link
Collaborator Author

OK

@frickler24 frickler24 closed this Jun 17, 2017
@frickler24 frickler24 deleted the macrotime.0.2 branch June 17, 2017 10:26
@frickler24 frickler24 mentioned this pull request Jun 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants