abhi8492i Posted July 23, 2018 Share Posted July 23, 2018 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 More sharing options...
Inheritance Posted July 25, 2018 Share Posted July 25, 2018 That would be a ton of data to store and keep track of. Also that data would not carry over from computer to computer. Link to comment Share on other sites More sharing options...
abhi8492i Posted July 27, 2018 Author Share Posted July 27, 2018 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 More sharing options...
Inheritance Posted July 27, 2018 Share Posted July 27, 2018 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 More sharing options...
hastegag Posted July 27, 2018 Share Posted July 27, 2018 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.