The shellscript migmac.sh was initially used to migrate
existing macros in the config files from 4- to 5-element strings.
Because the algorithm now handles older and newer macro strings as well,
the script is no longer needed.
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.
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
When using long macros with very long delays
(eg delays recorded while you typed very slowly)
and there is parallel a color-update necessary,
you can get an error in usb.c
(device closed as the keyboard resets itself).
Reason for this is misuse of the usb protocol
(sending two commands/request to the KB instead of
alternating request/reply)
because of missing synchronization between the two threads.
So we need a sync mechanism between these threads.
The mechanism is an additional mutex (mmutex).
The disadvantage of that synchronization is that
updating the color information is delayed
until all macros have been processed
(this also applies to type-ahead with several macros).
In the case of rather short macros or those with small delays,
this is not noticeable; in the case of wave motions,
the effect is occasionally recognizable.
And yes, we should rewrite ckb-daemon...
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...
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).
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".
In the past the connection between model of hardware
and the corresponding firmware version line
was made by the features of the hardware.
Because of several new hardware types,
this method did not work anymore for the newer types.
With this version the new FIRMWARE check is free for testing.
It depends on a new format of the FIRMWARE file
where in the last position a vendor number is added.
This vendor number identifies the device the firmware line is dedicated to.
Up to now tested is the correct detection of the line,
corresponding to the hardware model.
So the check, if new firmware version is available, is running.
Additionally tested is the function to upgrade firmware versions
for an M65RGB to 2.04
and an K95RGB to 2.05
How can you test it?
You will find in /dev/input/ckb<X>/fwversion the firmware version
the device show via USB (or similar path for maxOS).
If you patch the number, eg from 0204 to 0200, save the file (as root)
and restart the GUI
(definitly not the daemon, because the daemon will update the file again),
your GUI will show you the firmware-update window.
Update the Firmware and if it runs - fine.
In the past the connection between model of hardware and firmware version line
was made by the features of the hardware. Because of several new hardware
types, this method did not work anymore for the newer types.
With this version the new FIRMWARE check is first time running.
It depends on a new format of the FIRMWARE file
where in the last position a vendor number is added.
This vendor number identifies the device the firmware line is dedicated to.
ATTENTION:
=========
Up to now tested is the correct detection of the line,
corresponding to the hardware model.
So the check, if new firmware version is available, is running.
NOT TESTED at the moment is the function to upgrade firmware versions!
So be carefully with this.
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.
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.
In several cases we have seen error messages in the logfiles like
USBDEVFS_CONTROL failed cmd ckb-daemon rqt 33 rq 9 len 64 ret -110
[W] _start_dev (device.c:24): Unable to load firmware version/poll rate
[E] os_usbsend (via firmware.c:15): Connection timed out
or similar.
This happens if the device is in a status where the communication
between linux and device is corrupted. E.g. with an K95RGB one may
provoke the behavior by moving the poll-rate-switch, eg to BIOS mode.
This fix adds some USB-resets for the device if
either ioctls for getting infos give bad return values
or the device does not provide valuable information about endpoints,
version numbers etc.
Changing the operating modes for the RGB keyboards that provide this feature
(such as the K70RGB or the K95RGB) will result in massive disruptions
to the daemon and the keyboard itself.
A test matrix is stored in the corresponding issue # 48.
The settings here refer to the timeout before sending a USB message.
The timeout was previously 10ms and has been doubled.
Minor corrections and the clipping of the debug output
in a #define DEBUG were also committed here.
When switching K70RGB or K95RGB to BIOS mode, only one usb channel is provided
by the KB driver.
Because in usb_linux.c for all other modes the last channel is not used,
zero channels have to be initialized. this brings the daemon to a SIGSEGV.
While debugging this, sometimes the KB got informations which stopped the KB
completely from working. Only disconnecting + connecting worked,
no software-reset via the switch had been successful in this state.
When connecting a KB in this state to the daemon, 0 channels were detected.
These two special conditions (0 and 1 EP for an RGB device)
got special treatment in the code.
With this fix 4 definitions are implemented
to handle qWarning, qInfo, qCritical and qFatal.
All 4 functions are not know in Qt < 5.5 so comiplation will fail.
The functions are mapped via #defines to qDebug.
When testing that, another error occured with Qt 5.1,
because QCommandLineParser is not know in older versions.
So ckb.pro was updated to demand Qt5.2 at least.
With this fix 4 definitions are implemented
to handle qWarning, qInfo, qCritical and qFatal.
All 4 functions are not know in Qt < 5.5 so comiplation will fail.
The functions are mapped via #defines to qDebug.
When testing that, another error occured with Qt 5.1,
because QCommandLineParser is not know in older versions.
So ckb.pro was updated to demand Qt5.2 at least.
The comments are added in doxygen format.
The Generation of the doxygen output files
is not included in this commit.
This is handled in a separate branch.
The resulting documents are currenty visible
at https://frickler24.github.io/ckb-next/index.html
but maybe matter of change.
In this branch we just want to add comments to the code.
If there is something pure to correct the code
(as setting {}-pairs to clean up, declaring functions or
variables as static...), it will be done in this branch.
Additional debugging info or handling of return codes
is done in a separate branch.
Up to the last commit, these two things were intermixed.
With this commit, all code changes were eliminated.
Some more details for the usb related functions are givenb in doxgen
format.
Additinally a new doxygen config file JustUSBfiles has been added.
A doxygen run with this config prepares only some of the files
in the directory <projectroot>/src/ckb-daemon for a better readability.
Some ckb_warn() statement are included to give debug information, when
something unexpected happens in the usb send and receive procs.
Minor changes to the code comments are integrated in this commit.
If the command is
echo "restart" >/dev/input/ckb1/cmd
or similar, a default comment "No text" is logged.
Otherwise a text containing more than one word is valid as comment:
echo "restart This is an urgent boot" >/dev/input/ckb1/cmd
Because sometimes tho communication between daemon and KB is corrupted
after resuming from Standby or suspend, a restart function is
implemented.
It first calls the quit() funtion, then it calls main() again with the
original parameter list.
There are two ways to restart the daemon:
- send the string "restart some-description-as-one-word" to the cmd-pipe
(normally /dev/input/ckb1/cmd or /dev/input/ckb2/cmd, dependign on
what device gets what usb number
- sending SIGUSR1 to the daemon-process (as root).
Later on, there may be a user interface in the client
for the first method.
This error was caused by not completely copying a mode.
The KeyActions always referenced the original data and were not copied.
The commit fixes this and adds a few comments in the modules
where I passed while debugging.
There miight be an problem with this Firmware definition:
The filename at corsair doenload site is K70RGBRAPIDFIRE.
The standard rule used in ckb for creating the model names is
vendor + model-with-features + (RGB or nothing).
With this the name to look for in the FIRMWARE table should be
Corsair K70RAPIDFIRERGB
The file FIRMWARE in the root directory of ckb-next is signed.
Therefore, updating the obsolete content was not possible by anyone.
A new key has been created, with which only signatures for this development
should be made ([email protected], BAF07C6B).
The key was self-signed and in addition signed with my personal key.
It should also be signed by mattanger and possibly others.
Caution: The key may not be exported as ASCII file, but only as a binary file!
The display of gpg -d FIRMWARE should do something like this:
Gpg: Signature from Sat 04 Feb 2017 11:59:11 CET using RSA key ID BAF07C6B
Gpg: Correct signature of »ckb-next (For signing development artefacts only!)
<[email protected]>«
To test the function, the signed FIRMWARE file was originally uploaded to a branch of mine:
https://raw.githubusercontent.com/frickler24/ckb-next/issues-26-Firmware-Incident/FIRMWARE
(in line 36, kbfirmware.cpp).
In order for the mechanism to go productive,
the FIRMWARE file of the MASTER branch must be updated!
To prepare the mechanism fpr production,
the link ist updated to the MASTER branch FIRMWARE file:
https://raw.githubusercontent.com/mattanger/ckb-next/master/FIRMWARE
**********************
* Therefore this patch must first be used in master branch
* so that the correct file and key can be loaded at runtime.
* Then the patch can be added to the testing branch and others.
**********************
If the file or the key in the master branch is not up-to-date,
an error message is displayed when the ckb client is started
(as an example, here a possible error message):
Gpg: Signature from Thu Jun 30th 2016 09:15:49 CEST using RSA key ID 8DC8D309
Gpg: [do not know]: invalid packet (ctb = 2d)
Gpg: keydb_search failed: Invalid package
Gpg: Can not check signature: Public key not found
.gitignore is updated to ignore a directory containing tmp-files
and a script for signing the FIRMWARE-file.
If it is interesting for others, I can commit it also.
When adressing a command pipe for the mouse
with a macro cmd, the daemon got a null-ptr,
because no macro functions are defined yet.
This fixes that effect.
Using "macro [<modifier>\+]+[<keyname>]+:<def>"
is now usable, when sending the macro definition
"manually" via echo to the command pipe for the keyboard.
For the combination of an K95RGB keyboard and the M65RGB mouse
there was an initialization bug.
The ckb client did send a "Macro clear" command to the driver
for the mouse. Because that is unneccessary, there ist no function
to handle this and the deamon got a SIGSEGV.
This patch fixes that bug.
The change in ckb client prevents issuing the command.
The Patch in ckb-daemon may be activated by setting INIT_ERROR
and only does some debug output.
Extra setting menu has got an additional checkbox.
While using large macro definitions, some opSystems lose characters.
That ist because the call traffic to the virtual keyboard input
seems to be too high.
Whith this checkbox set, you get a time delay in two stages:
- If more than 20 chars are sent, 30 microseconds after the 20th
and each following char
- If more than 200 chars are sent, 100 microseconds after the 200th
and each following char
If you don't have any trouble with lost chars,
let this checkbox in off-state.
This branch sets up the ckb client (and one addition in ckb-daemon)
for self defined macros at nearly each key. With this enhancement
the 18 G-Keys at the K95 can be used.
It adds a new tab "macro" to the bind page as user interface
and includes all changes and additions to run the new tab
or do the communication with the daemon.
This version 0.0.1 handles the key macros in their primary layer,
so shift, alt, alt-Gr or meta keys are ignored.
It it tested with a K95 RGB on linux (mint 17.1 and 17.2) on
different machines.
In this version, the following functions
are implemented and integrations-tested:
- Interface and buttons are stable
- Comment field in the user interface is implemented
- some status line / short instructions to use the panel
are integrated
- a short video tutorial ist created
https://youtu.be/qhrKP03_NrM
This is currently missing:
- More intensive tests
- More systematic documentation of the code
- Commenting on the modifications to the existing code
In this version, the following functions
are implemented and integrations-tested:
- Interface and buttons are stable
- Comment field in the user interface is still ingored
- Separate thread is implemented for reading the macro keys
- The strings read from Keyboard are converted for saving
This is currently missing:
- Status line / short instructions to use the panel,
- The macro comment
- More intensive tests
- Systematic documentation of the code
- Commenting on the modifications to the existing code
In this version, the following functions
are implemented and integrations-tested:
- Interface and buttons are stable
- Comment field in the user interface is still ingored
- Separate thread is implemented for reading the macro keys
- The strings read from Keyboard are converted for saving
This is currently missing:
- Status line / short instructions to use the panel,
- The macro comment
- More intensive tests
- Systematic documentation of the code
- Commenting on the modifications to the existing code
In addition to the Macro Key Definition of panel "Macro Key Actions"
also the readable form of panel "Macro Text" will now be processed.
In this version, the contents of Macro Text is still a sample text.
This is the second development step for treating
the Macro keys G1-18 on the K95 RGB keyboard.
If you type a valid key sequence in the
Macro Tab -> Macro Key Actions,
select at least one G-Key and click Apply,
the macro definiton ist sent
to the keyboard and active.
The Macro definition is saved like all other bindings,
so with restart of ckb the macro definitions
are re-sent to the keyboard,
but you can't see the older definitions
in the ckb-panel yet.
Reset and Unbind are working properly,
Reset to Default is not tested in that commit.
Some debug outputs are still active (qDebug)
and some ToDos are marked in the source.
Lutz Eichler