Jump to content
Corsair Community

[Feature Reqest]-Individual Keypress counter (Not a keylogger)


abhi8492i

Recommended Posts

THIS ISN'T A REQUEST FOR KEYLOGGER.

 

We often get advertised with slogans like 50 million keystrokes. Or X number of hours/color cycles for LEDs under the keys.

 

Can you guys make an inbuilt official counter of individual key-presses? like how many times a certain key got pressed (de-pressed?) in its lifetime since first boot? Same goes for how many hours an LED has been lit up in a certain color? How many times the color changed?

 

I currently use WhatPulse for this purpose, (Just for keypresses; not colors) but while detailed, it's performance is shaky. It's database often gets corrupted with a power-loss/BSOD. And all the 5 digit keypress records gets tanked.

 

It can be an opt-in/checkbox feature if security is an issue. I don't know. I'm just asking. it should be simple enough.

 

Thanks.

Link to comment
Share on other sites

That would be a ton of data to store and keep track of. Also that data would not carry over from computer to computer.

 

Thanks for the response @Inheritance.

Can you please give some estimate of how much of that data is equating to a 'ton' here? No disrespect intended. I'm just disheartened. I thought the things Corsair (and other big names) are doing with their techs, this should be a walk in the park for them.

 

Is it because of color cycle counts?

what if we leave that out and keep only key-press count records? would that narrow it down, a bit?

 

I never thought about migration anyway. the best case (of hope) was this data somehow getting stamped down in on-board memory of keyboard itself.

Link to comment
Share on other sites

Yes not logging lighting data would cut down on the data stored. And no it wouldnt be hard for a company like Corsair but its down to how many people would want this and how much it would effect performance.

 

It could be dumped to the onboard memory for devices that have hardware profiles, but it wold have to be manual. You cant constantly update the keyboard memory without effecting performance.

Link to comment
Share on other sites

you could easily achieve this with a background process written in a number of languages, but probably easiest in c/cpp/c# or autohotkey.

 

that would not account for the Gkeys unless you used regsiter callback and did the getkeystate magic alongside it or if the G keys were remapped in cue/icue. Couple ways to skin this.

 

Honestly, ahk you could just stack every key like the Pseudo ahk below:

 

global keyCount:=0
readIniFile()
{
;some ini reading code to execute on load
}
writeIniFile()
{
;some ini writing code to execute periodically, but not so often that you hit the harddrive too much, you want to probably save the keyCount variable out every couple minutes perhaps and only if new keys are pressed.
}
*a::
*b::
*c::
*d::
...
*NumPadEnter::
...
;writeIniFile()
return
;or you could do a getKeyState loop like:
;https://autohotkey.com/boards/viewtopic.php?t=17665

 

 

As mentioned, this is actually a fair bit of undue overhead. We all hit millions of keys a year? Why bother recording it? If you are interested in testing the hardware, use a robotic actuator like i assume they do in QC in the factory, they probably have counts. Are you interested in the gamification of who did more? That's always cheated by creeps that have 9^999999.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...